AWS Serverless Demonstrated 受験レビュー
ひと目で分かる概要
AWS Skill BuilderのMicrocredentialの一つであるAWS Serverless Demonstratedを受験し合格した(完了日2026年7月10日)。選択式の資格ではなく、eコマースの注文処理アプリがすでに構築されており、その中の壊れた(BROKEN)部分をコンソールで直すハンズオンExam Labである。一言で印象をまとめると、Lambda中心の実習型Exam Labで、「サービスを知っている」ことよりも接続・環境変数・ログで問題を直せるかを見る。
シナリオはCloudFront Webアプリから始まり、WAFを経たAPI Gateway(prodステージ)に入り、Cognito Authorizerを通過したリクエストがproducts、cart、place-orderのようなパスごとのLambdaに渡される構造だ。これらのLambdaはDynamoDB(商品/カート/注文テーブル)と接続されており、CognitoのPost confirmationトリガーがSNSでメール購読を処理し、Step Functionsが注文処理ワークフローを担当し失敗時はSQSへ渡される。
形式はコンソールベースの自動採点Exam Labであり、範囲はAPI Gateway、Lambda、Cognito、DynamoDB、SNS、Step Functions、SQS、WAF、CloudWatchである。体感難易度は中〜中上級で、特にStep FunctionsのCatch/Payload設定が手ごわい。合格基準はチャレンジごとの動作要件充足の有無であり、Lambda・API・DynamoDBをそれぞれは知っているが一つのパイプラインとしてつなげたことが少ない人におすすめできる。
体感ではチャレンジ5個前後で構成されていた。前半でAPIを作り、認証・セキュリティ・永続保存を付けた後、最後に注文ワークフロー(Step Functions)を生かす流れである。
この試験は何を見ているのか
試験が繰り返し問う質問はシンプルだ。リソース同士が正しく接続されているか(Authorizer、トリガー、State Machine ARN、テーブル名など)、環境変数・IAM・デプロイを見落としていないか、そしてうまくいかない部分があるときにCloudWatch Logsで失敗箇所を見つけられるかである。一言で言えば「ドキュメントを読み、コンソールで正しいリソースを正しい値で接続できるか」を問う試験だ。理論の暗記よりもコンソールの動線とデバッグの習慣が合否を分ける。
実際に受けてみた感想
良かった点
実務感覚が生きている。Lambdaを一つデプロイするのではなく、API、認証、DB、メッセージング、ワークフローが一つのシナリオの中にすべて入っている。検証が動作ベースなので、CloudFront Webアプリでカート・注文まですぐに体感できる。詰まると、ほとんどの場合CloudWatch Logs → 環境変数 → IAM → 接続設定の順で解決でき、このパターンがつかめれば速度が上がる。
苦労した点
似たように見える選択肢が複数ある。Cognitoトリガーの Pre sign-up と Post confirmation、DynamoDBテーブルの用途(商品/カート/注文)のように、もっともらしい方を選ぶと失敗しやすい。環境変数のキーがあっても値が空だと、Lambdaが即座に500エラーを返す。コードは問題なさそうに見えるのに実行時間だけ2msというケースだ。Step FunctionsはUIが見慣れず、Catch対象の状態を作る前にCatchを先に設定しようとすると迷いやすい。ラボのSCP制限によりpricing:ListPriceListsのような通知が出ることがあるが、これは検証失敗でなければ無視して進めてよい。
総評
体感難易度は中〜中上級である。Agentic AI系の試験ほど概念レイヤーは厚くないが、その代わり設定一箇所の抜け漏れが全体を壊すタイプの問題が多い。あらかじめ落とし穴を知っておけば体感難易度は大きく下がる。
チャレンジ別の経験談
API Gatewayの構成
REST APIにproducts、cart、place-orderリソースを作り、それぞれLambda Proxy Integrationで接続した後CORSをオンにする。最後にprodステージにDeployする。難易度自体は低いが、「作ったのにWebアプリが変わらない」の原因はほぼ常にDeployの抜け漏れだ。Lambda Proxy Integrationのチェックを忘れず、CORSはリソース(メソッド)単位でEnableし、変更後は必ずprod Deployを行う必要がある。
CognitoとSNS(登録後のメール購読)
会員登録が終わった後、ユーザーのメールがSNSトピックに自動購読されない問題を直す。CloudWatchで失敗箇所を見て、CognitoトリガーとLambda、SNSを合わせる。トリガーの種類を間違えると永遠に動作しない。登録が成功(メール確認)した後に戻る必要があるためPost confirmationトリガーが正解であり、Pre sign-upを選ぶと要件と食い違う。SNSトピックにEmailプロトコルを設定し、CognitoのPost confirmationトリガーがsubscribeSNS_functionを呼び出すように接続し、Lambdaの環境変数SNS_TOPIC_ARNを埋める必要がある。SNSのメール購読は確認リンクをクリックして初めて最終的に成功し、Lambdaが一度も実行されていない場合CloudWatchロググループ自体が存在しないことがあるため、その場合はまずトリガーと権限を疑うべきである。
Cognito AuthorizerとAWS WAF
APIをCognitoでロックし、WAF Managed Rulesで悪意あるIPを防ぐ。AuthorizerのToken SourceをAuthorizationに設定するのを忘れると認証が壊れる。OPTIONSメソッドはCORS専用なのでAuthorizerをかけないパターンがよくある。WAFはRegional Web ACLをAPIのprodステージに接続する。WAF生成中にpricing:ListPriceLists関連のエラーが出てもラボの制限であることが多いので、慌てずに進めればよい。Application categoryの選択が必須の画面もある。
カートの永続化(DynamoDB)
ページ再読み込みや再ログイン後にカートが空になる問題を直す。表面的にはコードを大きく直す必要がありそうに見えるが、実際の核心はユーザーごとのカートテーブルと環境変数設定であるケースが多い。ProductTable(商品カタログ)をカート用に使ってはならず、Partition Keyは通常usernameである。Cognito Authorizerのclaimsからcognito:usernameを取り出して使う前提を理解する必要がある。CART_TABLE環境変数の値が空だと即座に500エラーが出て実行時間が極端に短く記録される。コードロジックがすでに正しくても環境変数だけ埋めれば通過するパターンがあるので、商品をカートに入れる → 再読み込み → カートが維持されるかで検証すればよい。
Step Functions注文処理
最も時間を使いやすい区間である。placeOrderがState Machineを開始し、orderUpdateが注文をDynamoDBに残し、失敗はCatchでSQSに渡される。sendNotificationは意図的に失敗するよう構成されており、エラーがSQSに渡されればむしろ通過となる構成があった。前段のORDER_PROCESSING_STATE_MACHINE_ARNが空だと、後にあるLambdaのロググループ自体が生成されないため、依存の順序を意識する必要がある。
よく詰まるポイントをまとめると次の通りである。State Machine ARNが設定されていないという症状は、placeOrderの環境変数の欠落が原因であり、orderUpdateのログがないという症状は、placeOrderが失敗しワークフロー自体が開始されなかったことを意味する。「Missing required field: Payload」エラーは、Lambda Taskに"Payload.$": "$"の設定が抜けているという意味であり、Catchの接続がうまくいかないという症状はSendErrorToSQSの状態を先に作っていないことを意味する。コンソールで迷う場合は大抵SQSコンソールとStep Functionsコンソールを混同したものだ。Step FunctionsはSaveだけを行い、不必要に新しいバージョンをPublishするよう強制しない方が安全な場合があるので、この部分は問題文の指示を優先すべきである。
目指す流れは、orderUpdateが成功すればsendNotificationに移り、再度成功すれば終了することである。各段階で失敗(Catch)が発生した場合は、すべてSendErrorToSQS(SQS)を経て終了する構造だ。
時間がかかった区間
体感で最も迷いやすかった区間はStep FunctionsのCatch、Payload、SQS連携だった。Cognitoトリガーの選択とSNS購読の確認も、トリガーの種類とメール確認リンクのクリックを見落としやすく時間がかかった。Cartの環境変数とテーブルの用途の区別はコードの問題と勘違いしやすい区間で、AuthorizerのToken SourceとWAFの設定は値さえ知っていれば比較的早く終わらせられた。API Gatewayのリソース生成、CORS、Deployは機械的に処理できる区間だった。
戦略は明確だ。前半でDeployと環境変数の確認を習慣化しておき、Step Functionsの区間にバッファを残しておくことである。
受験前に準備しておくと良いこと
この試験のデバッグの基本ループは、CloudWatch Logsを最初に確認し、環境変数のキーではなく実際の値が入っているかを確認した後、IAM Roleの権限を点検し、テーブル・トピック・State Machine・SQSのようなリソースが実際に存在するかを確認し、トリガー・Authorizer・Catchのような接続設定を点検した上で、APIを変更した場合はprod Deployまで済ませる順序で成り立つ。このループを体に染み込ませておくと実戦で大いに役立つ。
ドキュメントだけを読まず、コンソールで一サイクルを手で回してみることも重要だ。API Gatewayのリソース生成、Lambda Proxy、CORS、Stage Deploy、Cognito Lambdaトリガー(Post confirmation)、DynamoDBテーブルの作成とLambda環境変数の接続、SNS Email購読確認の流れ、Step FunctionsのLambda TaskとCatch、SQS SendMessageの連携、WAF Web ACLをAPIステージに接続する作業を一度ずつやってみると、本番での速度が大きく変わる。
アカウントごとに名前とARNは異なるが、値の種類は繰り返される。AuthorizerのToken SourceはAuthorizationに固定され、Cognitoトリガーは登録完了後に動作するPost confirmationを主に使い、環境変数にはテーブル名、Topic ARN、State Machine ARNがよく登場する。DynamoDBのPartition Keyはカートの場合username、注文の場合orderIdに近いことが多く、Step FunctionsではLambdaのPayload.$設定とCatch → SQS接続がよく出てくる。
ラボのSCPや料金API関連のノイズと実際の検証失敗メッセージを混ぜないことも重要だ。問題文で無視するよう明示された通知は文字通り無視すればよい。
設定を変えた後はCloudFront Webアプリでログイン、カート、注文まで一度ずつ実際に押してみるのがよい。自動検証だけを回すと、どのLambdaが実行されなかったのかを見落としやすい。
コンソールUIが複数の言語で表示されても、メニュー名よりAuthorizer、Triggers、Environment variables、State machine definitionのようなタブの位置を覚えておく方が効率的である。
よくあるミスまとめ
経験上よく出るミスは次の通りである。APIを変更してもprod Deployを行わないケース、CognitoのPre sign-upとPost confirmationを混同するケース、AuthorizerのToken SourceにAuthorizationを設定し忘れるケース、ProductTableをカートテーブルとして誤って使うケース、環境変数のキーだけがあり値が空のケース、SNS購読メールの確認リンクを押さないケース、Step FunctionsでCatch対象の状態を作る前にCatchを先に設定するケース、Lambda TaskにPayloadを入れ忘れるケース、placeOrderのARNが空の状態で後の段階から直すケース、そしてWAFやpricing関連の通知に時間を使い切ってしまうケースである。
こんな人におすすめ・非おすすめ
Lambda、API Gateway、DynamoDBをそれぞれは知っているが一つのアーキテクチャとしてつなげたことがない人、CloudWatch Logsで障害を追跡する習慣を作りたい人、Step Functions・SNS・WAFを聞いたことがあるだけの状態から短く手に馴染ませたい人、他のDemonstrated系の試験を受ける前にサーバーレスの接続感覚を先に養いたい人におすすめする。逆にLambdaやIAM、環境変数の概念がまだ馴染みのない人、コンソールよりCLI・IaCばかり使ってきてコンソール探索に時間がかかる人、コードだけ直せばいいと考えログや設定をあまり見ない人であれば、事前準備をもっとする方がよい。
合格後に残るもの
合格するとCompletion CertificateとCredlyバッジなどが発行され、マイクロクレデンシャル系は通常1年間有効である。詳細な更新周期はSkill Builderの案内に従えばよい。
資格の一行よりも実質的に残るのは、サーバーレス環境で「誰が誰を呼ぶのか」を環境変数、トリガー、Authorizer、ワークフローまで一度に設計・修正する感覚である。実務でAPI Gatewayの後ろにLambdaを置き、Cognitoでロックし、DynamoDBに状態を残し、Step Functionsで非同期の注文を処理するパターンをすでに使っているなら、この試験はその感覚を短く検証してくれる装置だ。まだそのパターンを試したことがなければ、準備過程が最も価値ある学びになる。
終わりに
AWS Serverless Demonstratedは難しい理論試験というより実務型トラブルシューティング試験に近い。リソースはすでに作られており、説明に問題の状態がヒントとして書かれており、受験者はコンソールでそれを直す。
合格の核心は才能ではなく順序である。APIを接続しDeployし、CognitoとSNSで登録後の流れを生かし、AuthorizerとWAFでロックし、カートをDynamoDBに紐づけ、Step Functionsで注文・エラー経路を完成させる。
次に受験する方に一つだけ残すとすればこれである。CloudWatch Logsと環境変数(値!)をまず見よ。Step Functionsはその次だ。合格とバッジよりも「なぜ500なのか」「なぜログがないのか」「なぜCatchがつながらないのか」を自分で答えられるようになる方が長く残る。その感覚を持って臨めば、このExam Labは十分に合格できる。