検証済みリクエストを受け付け、ブラウザークライアントをサポートし、非公開データにはアプリケーションへのログインを要求する注文 API を構築します。観察できるリクエストと保存結果を通じて、API Gateway、Lambda、DynamoDB、Cognito を結びつけます。
5 つのガイド付きラボで、HTTP API からブラウザーの CORS、Cognito 認証、JWT によるルート保護へ進みます。自主課題では、公開ヘルスエンドポイントを維持しながら、注文を公開してしまうプライベート API を修復します。
学習する内容
- HTTP API を通じて Lambda 関数を公開する
- 注文入力を検証し、DynamoDB に基づく結果を計算する
- ブラウザーのオリジン、メソッド、ヘッダーに関する CORS 動作を設定する
- Cognito でログインし、アプリケーションの認証情報を更新する
- JWT オーソライザーでプライベートルートを保護する
- 拒否されたリクエストが業務データを変更しないことを確認する
- 公開ヘルスリクエストを壊さずに、非公開アクセスを修復する
このコースの対象者
Lambda とデータアクセスの基礎を持ち、アプリケーション API を構築して保護したい学習者が対象です。
前提知識： Lambda のデプロイと設定（FN01/FN02）、IAM ロール、CloudWatch Logs を学習してください。注文 API には Lambda–DynamoDB アクセス（FN03）も必要です。CORS とサインインは注文 API の後に学べます。JWT ルート保護にはサインインが必要です。JWT 保護を終えてからチャレンジに進みます。
学習環境： すべての演習は、ブラウザーから利用できる LabEx の Linux 環境で行います。AWS CLI のコマンドには Terminal を使い、その隣の AWS View で同じリソースとアプリケーションの状態を確認します。ツールと接続は準備済みで、個人の AWS アカウントやアクセスキーは不要です。各ラボは新しい VM で独立して開始します。 CORS ラボでは、AWS View に Browser Client が用意され、実際のブラウザーリクエストを実行できます。アイデンティティ画面は、パスワードや Bearer トークンを含まない安全なメタデータを表示します。
よくある質問
CORS は認証の仕組みですか？
いいえ。CORS はブラウザーのアクセス動作を制御しますが、ユーザーのアイデンティティは確立しません。アプリケーションへのログインと IAM リソース権限は別であり、有効な JWT だけでは注文の所有権を証明できません。
プライベートルートはどのようにテストしますか？
HTTP リクエストが目的の関数を実行し、保存済みアイテムを読み書きする必要があります。認可の拒否は Lambda の前で止まり、業務データを変更してはいけません。ゲートウェイの判断、関数のイベントと応答のログ、レコードを比較します。提供された架空のアイデンティティだけを使い、認証ファイルは非公開にしてください。
どの API とログイン機能を扱いますか？
HTTP API、$default AutoDeploy ステージ、Python の payload 2.0 統合、限定した Cognito のパスワード・更新フローと RS256/JWKS JWT を使います。ルートのスコープには Cognito のユーザーセルフサービススコープを使います。独自の業務スコープ、ユーザーごとの注文分離、ホストされた OAuth/MFA、本番の署名キーのローテーション、デプロイ自動化は範囲外です。
この後にプロジェクトへ進めますか？
はい。Secrets Manager と Parameter Store の前提学習を終えると、これらのスキルをプライベート API プロジェクトに使えます。各ユニットは新しい環境で始まります。自分のリソースを削除する前に機能確認を終え、無関係な参照リソースを保持してください。
