【AWS実証ラボ】サーバレスアーキテクチャ構築でハマったリアルな罠と解決策まとめ

はじめに

AWS Skill Builder の「AWS サーバレスの実証」ラボ（Exam Lab）に挑戦しました。
AWS Skill Builder は、実際の AWS コンソールを操作しながら、不具合やセキュリティ設定の不備を解決していく実践的な内容です。

🎯 対象読者

• AWS Skill BuilderのExam Lab（サーバレスの実証）に挑戦したい方
• API Gateway、Cognito、WAF、Step Functionsの連携エラーに頭を悩ませているエンジニア

💡 解決できること

• コンソール操作の「死角」に潜む罠や、環境変数の設定漏れなど、サーバレス構築で誰もが一度は嵌るリアルな不具合の解決アプローチが掴めます

今回は、ラボ内の全5つの課題（タスクA〜E）を通して学んだ「サーバレス構築において非常によくある実践的な罠」とその解決アプローチを、画面キャプチャの解説を交えて記事としてまとめます。

• https://skillbuilder.aws/learn/XV3B4RGA8Q/aws-serverless-demonstrated/BYD5SH8R5C

ラボ自体は誰でも実施可能です。
アカウント登録して、皆さんも体験してみてください。

なお、本ラボ課題は、1時間35分の時間制約があります。
本来ならば計7つの課題を順にこなしていく必要があるのですが、私の場合は調査などで時間が足りず、計5つの課題にチャレンジし、4つのみ完了しています。

全体構成図

サーバレス構成としての全体像はこんな感じ

今回の課題において、構築/修正対象となるシステムは下記のようなサーバレスアーキテクチャです。

• フロントエンド: CloudFront + S3 (Static Web Hosting)
• 認証・セキュリティ: Amazon Cognito + AWS WAF
• API・バックエンド: API Gateway + AWS Lambda + Amazon DynamoDB
• 非同期注文パイプライン: AWS Step Functions + Amazon SQS (DLQ)

それでは、それぞれの課題について振り返っていきます。

🧭課題A：Amazon API Gateway のリソース・メソッド修正

🛑発生していた問題

• 画面からバックエンドへの通信が通らず、以下のエラーが発生
  Required resources (products, cart, place-order) are missing.
  

🔍設定不備箇所

• 「リソースが丸ごと存在しない」ケースだけでなく、「リソース自体はあるように見えるが、特定のメソッド（GET や POST）だけが欠落している」
• Lambda への統合設定が外れている

といった、部分的な不備が仕込まれていました。
また、

• CORSの設定漏れ

も不備対象として含まれています。

💡 解決策

解決方法としては、下記4点でした。
課題Aに関しては、設定/不足項目を追加することで対応可能でした。

1. /products (GET)、/cart (GET/POST)、/place-order (POST) の不足しているメソッドをピンポイントで追加
2. 各メソッドの統合タイプ（Integration Type）を対応する Lambda 関数（getProduct_function 等）へ正しく紐付け
3. 各リソースで必ず「CORS の有効化 (Enable CORS)」を実行
4. 最後に対象の API を prod ステージへデプロイ（Deploy API）

追加するだけなので、そこまで難しくはないかと思います。

検証を押下することで、課題が解決しました。

🧭課題B：Amazon Cognito によるユーザー認証の正常化

🛑発生していた問題

• フロントエンドの画面から新規ユーザー登録（サインアップ）やサインインのテストを行う際、エラーが発生して処理が進まない
  

🔍設定不備箇所①

• Cognito ユーザープール（ecommerce-user-pool）自体の設定不備
• 「以前のテスト時の古いセッションや別ユーザーのキャッシュがブラウザに残っていること」

上記が認証エラーを引き起こす原因になっていました。

💡解決策①

解決策としては、下記1点でした。
本課題はフロントエンドでのアカウント登録操作も含まれるため、目に見えてエラーが確認しやすいです。

1. Cognito ユーザープール側の属性要求や検証メールの送信設定を整合
   

上記をもとに、動作確認として、フロントエンド側でアカウント登録操作を行います。

登録ができたようで、ポップアップにて、認証コードを入力するように促されます。

実際にメールに通知された認証コードを入力します。

※アカウントIDと認証コードが上記キャプチャと異なることは気にしないでください()

さて、アカウントの確認ができたかと思いましたが、エラーが発生しており、次の画面に進めません。
さすがに理由がわからなかったのでAIに聞いてみたところ、下記返答が返ってきました。

これは Amazon Cognito のユーザー登録が完了した直後に走る 「サインアップ後の確認トリガー（PostConfirmation Lambda関数）」のプログラム内で、Amazon SNS の Topic ARN（トピックの識別子）が正しく読み込めていないことが原因です。

上記を踏まえると、

• 認証は行えていそうだから、Cognito の問題ではなさそう
• 大体こういう時は、該当の Lambda の設定がおかしいケースも多いよ

と理解できたので、このメールを送信している Lambda の設定について確認してみます。

すぐには気づきませんでしたが、該当の環境変数を確認してみると、ブランクであることがわかりました。

このため、SNS_TOPIC_ARN について、該当の SNS の ARN を確認して設定してみます。
SNS に遷移すると、下記赤枠部分に ARN が設定されています。

これを SNS_TOPIC_ARN に設定します。

再度アカウントを作成し、認証コードを入力したところ、下記表示がされ、登録が完了しました。

該当の画面にも遷移できました。

検証も成功してそうです。

ここまでを踏まえ、下記についても対応が必要でした。

🔍設定不備箇所②

• Cognito の PostConfirmation トリガーに紐づいている Lambda関数 において、環境変数が未設定

上記が認証エラーを引き起こす原因になっていました。

💡解決策②

解決策としては、下記1点でした。

• SNS ARN を Lambda の環境変数に指定する

🧭課題C：AWS WAF による API Gateway の保護設定

🛑発生していた問題

• API Gateway のエンドポイントが外部からの攻撃に対して無防備な状態
  

🔍設定不備箇所

• 罠①：スコープ（Scope）の間違い
  • WAFの作成時にスコープを「CloudFront（グローバル）」で作成してしまい、API Gateway ではなく Cognito に関連付けられてしまう（API Gateway を守るには Regional スコープが必要）
• 罠②：無関係なエラーのノイズ
  • ログに pricing:ListPriceLists に対する権限エラーが表示されるが、これはラボ環境の制限によるもので、合否には無関係の「無視して良いエラー」だった

💡解決策

この部分についても、ラボの内容をそのまま実施すれば問題なくクリアできました。
下記決策としては下記3点です。

1. Web ACL を作成する際、Scope を必ず 「Regional resources（リージョン）」 に指定
2. 指定された2つの AWS マネージドルール（AWSManagedRulesAmazonIpReputationList、AWSManagedRulesKnownBadInputsRuleSet）を追加
3. 「Associated AWS resources」から、対象の API Gateway の prod ステージ を保護対象として関連付け

上述の通り、この課題自体はそこまで難しくはないです。

🧭課題D：カート機能の修正と DynamoDB への永続化

🛑発生していた問題

• カートに商品を追加しても、ブラウザを更新したりサインアウトして再サインインすると中身が消えてしまう（データが永続化されない）
  

🔍設定不備箇所

• 上記のように ProductTable（パーティションキーが productId）だけを見て設定を進めようとすると、カート機能で使いたいキー構造と一致せず、保存時にエラーとなります

💡解決策

解決策としては、まずはテーブルを作成し、Lambda 側と紐づけを行います。
その後、Cognito セッション属性からユーザー名が取得されるよう修正します。

1. カート専用の CartTable を確認（または新規作成）し、パーティションキーをコードと一致する username（文字列型: S） に構成
2. Lambda 関数（manageCart）側で、Cognito セッション属性（event['requestContext']['authorizer']['claims']['cognito:username']）から安全にユーザー名を取得するようコードを修正
3. Lambda 関数（manageCart）側で、関数が DynamoDB で作成したテーブルを環境変数として指定
4. データの読み書き時、Decimal 型への相互変換（convert_to_decimal ルーチン等）を組み込み、環境変数 CART_TABLE を設定してデプロイ
   

🧭課題E：AWS Step Functions を用いた注文処理パイプラインのエラーハンドリング

本課題では、すべての課題をクリアできませんでした。
何を実施し、どういう結果になったのか、原因の分析を行ってみます。

🛑発生していた問題

• 注文処理システムは、非同期処理がAWS Step Functionsを通じて適切に設定されていないため失敗
  

🏃‍♂️この課題で実施したこと

1. 注文受付Lambdaの改修（placeOrder_function）

   • Lambdaコンソールを開き、注文データを受け取ってStep Functions（ステートマシン）を非同期で開始（start_execution）させるためのPythonコードを実装・デプロイ
     
     

2. DynamoDBテーブル（OrderTable）の作成と確認

   • DynamoDBコンソールを開き、注文管理に必要な OrderTable が正しく存在しているか、あるいはプライマリキーの設定が適切かを確認
     

3. エラー受け皿となる Amazon SQS の新規作成

   • SQSコンソールを開き、失敗した注文メッセージ（デッドレター）をキャッチするための新しい標準キューを構成・作成
     

4. Step Functions でのエラーハンドリング定義（最終局面）

   • Step Functionsのビジュアルエディタを開き、問題の sendNotification を含む各Lambdaタスクから、新しく作ったSQSへエラーをルーティング（Catch）する設定を追加
     
     ※この場面でタイムアップとなりました。

🛑どう実施した結果、タイムアップとなったのか（原因の分析）

結論から言うと、「AWSのビジュアルエディタが自動生成した『余計な空の設定』が引き起こした構文エラーの解消に、貴重な残り時間をすべて吸い取られてしまった」 ことがタイムアップの直接的な原因でした。

• ① 設定の自動生成による罠
  • Step Functions のビジュアルエディタでエラーハンドリング（Catchルート）を追加した際、右側の詳細パネルで設定を調整しました
  • その際、エディタの仕様で中身が空っぽの「再試行（Retry）」や、不要な2つ目の「キャッチャー（Catch）」の入力枠が自動的に作成されてしまいました
• ② 画面の「死角」によるタイムロス
  • 課題C（WAF）の時は、エラーの原因が「スコープ違い」という明確な概念のズレだったため、比較的すぐに気付けました
  • しかし、今回の Step Functions のエラーは 「画面を下にスクロールしないと見えない位置にある、中身が空の設定枠（Nextが未指定）」 が原因の構文エラーでした
  • これがバリデーションエラーとして保存をロックし、原因探しの泥沼に嵌ってしまいました

まとめ

最後の注文処理システムの改修（課題E）の途中で、無情にもタイムアップのポップアップが表示され、「AWS サーバレスの実証」は終了しました。

残り3課題、課題Eに至っては途中終了であり、残念な結果になりましたが、コンソールを往復しながら「Lambdaのコードを直し、SQSを構え、Step FunctionsのCatchルートを繋ぐ」という一連のリアルな分散アーキテクチャの構築は、ドキュメントを読む以上に良い経験となるかと思います。

また、私のようなタイプでも、ボタン一つで自動的に検証環境を構築してもらい、実務に近いトラブルシューティングの学習ができる点は、AWS Skill Builder を活用する大きなメリットだと感じています。
私も、今後も引き続き、Skill Builder を用いて AWS の学習を進めていきます。

みなさんもぜひ、この「サーバレスの実証」で泥臭く手を動かす楽しさを体験してみてはいかがでしょうか。
インフラのトラブルシューティング力を鍛えたい方には、とても良い経験になるかと思います。