AWS Application Networking Demonstrated 受験レビュー
ひと目で分かる概要
AWS Skill BuilderのMicrocredentialの一つであるAWS Application Networking Demonstratedを受験し合格した(受験日2026年7月13日、有効期限は合格日から1年で、更新のための再受験は約9ヶ月後から可能)。選択式の資格ではなく、実際のコンソールで壊れた(BROKEN)インフラを修正し完成させるハンズオンExam Labである。
シナリオはService Desk Webアプリケーションである。Frontend VPCとBackend VPCが分かれており、ALB、ECS、VPC Lattice、API Gateway、CloudFront、CloudWatch、S3が一本の線でつながっている。核心は「サービスを知っている」ことではなく、クロスVPC環境でトラフィックが実際に流れるようにできるかどうかである。
形式はコンソールベースの自動採点Exam Labであり、範囲はALB、ECS/Fargate、Security Group、VPC Lattice、API Gateway、CloudFront(+WAF)、CloudWatch、S3である。体感難易度は中上級〜上級で、特にSG Prefix List、VPC Lattice、API Gateway CORS/ステージの区間が手ごわい。合格基準はタスクごとの要件充足の有無(Healthy、Deployed、アラーム・ログ設定など)であり、ネットワーキング・コンテナ・エッジをすでにそれぞれ扱ったことがある実務者や受験者におすすめできる。
成績レポートによると、次の7つのタスクすべてが要件を満たしていることが確認された。Application Load Balancerのヘルスチェック修正およびAmazon ECSサービスのスケーリング、マルチティア通信のセキュリティのためのセキュリティグループ構成、サービスディスカバリのためのAmazon VPC Latticeサービスネットワーク構成、Amazon VPC Latticeを通じてトラフィックをルーティングするためのAmazon API Gateway統合の修正、本番環境準備のためのAmazon CloudFront配信構成、アプリケーション状態監視のためのAmazon CloudWatchアラーム作成、Application Load Balancerのアクセスログをトラフィック分析用に有効化するタスクである。
この試験は何を見ているのか
アーキテクチャを大まかに解きほぐすと、ユーザーのリクエストがCloudFrontとWAFを経てALBに到達し、ALBはECS Frontendにトラフィックを転送する。次にAPI GatewayがLambda Proxyを経てVPC Latticeサービスネットワークに接続され、最終的にECS Backend APIに到達する。ここにCloudWatchアラーム(SNS連携)とALBアクセスログ(S3保存)が追加で付く。
試験が繰り返し問う質問はシンプルだ。誰が誰にどのポートでアクセスするのか、その経路にSecurity GroupとPrefix List、Lattice Associationが正しく開いているか、そしてエッジ(CloudFront)、API、ロードバランサー、コンテナの設定値が問題文に書かれた値と一致しているかである。概念の暗記よりも、コンソールで正確なタブを見つけ正確な値を入れるスピードが合否を分ける。
実際に受けてみた感想 — タスク別の体感レビュー
ALBヘルスチェックとECSスケーリング
最初に手をつける区間で、Frontend/API ECSのDesired countを上げ、ALBターゲットグループのヘルスチェック、Stickiness、Deregistration delayを合わせる。難易度自体は高くないが、StickinessとDeregistration delayの設定はDetailsタブではなくAttributesタブの編集画面にある点を見落としやすい。ターゲットがHealthyになるまで少し待ってからALB DNSでHTTP 200応答を確認しておくと、次のタスクの前提条件を満たしたことになる。
マルチティアSecurity Group
体感難易度が大きく上がる区間だ。Lattice用SG、API用SG、ALB用SGだけを正確に手直しし、残り(default、GuardDuty、endpoint SGなど)には触れないことが肝心である。区別すべき項目は次の通りだ。VPC LatticeトラフィックはManaged Prefix Listであるvpc-latticeを使用し、Latticeからタスク側へ向かうトラフィックは169.254.0.0/16のlink-local帯域を使用する。インターネットからALBへ入るトラフィックはCloudFront origin-facing Prefix List(IPv4)を使用しなければならず、ALBに残っている0.0.0.0/0のHTTP/HTTPSルールは削除しなければならない。Prefix Listの一覧にはCloudFront IPv6版も一緒に表示されるが、誤って選ぶと検証を通過できないためcloudfront.origin-facing(IPv4)を選択する必要がある。このタスクを適当に済ませると、後のVPC Latticeタスクでターゲットがずっとunhealthyのままになるため、SGは後回しにせずこの段階で確実に終わらせておく方が早い。
VPC Latticeサービスネットワーク
Frontend/Backend VPCをサービスネットワークに関連付け(associate)し、ticket-apiサービスを付けた後、ECSタスクのPrivate IPをLatticeターゲットグループに登録する。VPC Latticeを初めて扱うなら最も詰まりやすいポイントである。概念自体はVPC Association(どのSGで付けるかを含む)、Service Association、Targetの登録とHealth checkとシンプルだが、Health check pathがALB(/health)とLattice(/api/healthなど)で異なることがあるため、問題文に書かれたpath、port、intervalをそのまま従う必要がある。ECSタスクのPrivate IPを事前にメモして登録すると楽で、unhealthy状態が続くならほぼ常にAPI SGの169.254.0.0/16ルールの欠落が原因だ。
API GatewayとVPC Lattice統合
LambdaプロキシがLattice DNSを見てバックエンドを呼び出すように合わせ、/api/categorizeのPOSTメソッド、CORS、prodステージのキャッシュ/スロットル設定を修正する。POSTメソッドを先に作成しCORSを後から設定するという順序を守らないとCORS設定が失敗する。prodステージのデフォルト値がRate 10000、Cache OFFであることが多く、Edit stage画面で数値まで正確に合わせる必要がある。当時の要求基準でよく間違える値は、CacheはON、容量0.5GB、TTL 300秒、暗号化ONで、ThrottleはRate 1000、Burst 2000、CORSはPOSTとOPTIONSメソッドだった。修正後はprod Deployを忘れてはならない。
CloudFront配信構成
説明に「BROKEN: wrong origin, no cache behaviors」のようなヒントが与えられる場合がある。Originを実際のALBに変え、Cache policyとSPA用Error pages、WAFを合わせる。Origin、Behavior、Error pagesの設定は慣れていれば素早く進められるが、時間を取られる部分はWAFの位置だ。General設定のEdit画面にはWAFオプションがなく、SecurityタブのEdit securityまたはManage protectionsに入る必要がある。新しいコンソールUIでは「セキュリティ保護の有効化」でCore protectionをオンにする流れである。SPAであれば404/403エラーを/index.htmlにマッピングし、response codeは200にするパターンをよく要求される。デプロイ状態がDeployedになるまで数分かかるため、保存だけしてすぐ次に進まずステータスを確認すべきである。
CloudWatchアラーム
ALB遅延、ECS CPU、ECS Memoryアラームの3つを作成し、既存のSNSトピックでIn alarm通知を設定する。難易度は低いが、名前、メトリクス、しきい値、Period、評価期間(例:2/2)などを問題文と文字単位で正確に合わせる必要がある。アラーム状態がデータ不足(Insufficient data)であっても、設定さえ合っていれば採点を通過するケースが多く、メトリクスが見えない場合はALBに一度トラフィックを流せばよい。
ALBアクセスログ → S3
最後のタスクはロギングだ。バケットの存在とBlock Public Accessの有無を確認した後、ELBサービスプリンシパル(logdelivery.elasticloadbalancing.amazonaws.com)にs3:PutObject権限を許可し、ALB Attributesでアクセスログを有効化する。バケットポリシーのARNパス(AWSLogs/アカウントID/*)を間違えやすいので、有効化後にトラフィックを送り、数分後にS3にログオブジェクトが実際に生成されたかまで確認するのが安全である。
時間がかかった区間
体感で最も時間がかかり間違えやすかった区間はSecurity GroupとPrefix Listだった。以降のタスクにも連鎖的に影響するためである。VPC LatticeのAssociationとTargetの登録も、慣れていないと大いに手間取る区間だった。API GatewayのCORSとStage設定は順序と数値を間違えやすく、CloudFrontのWAFの位置はUIさえ知っていれば難しくなかった。ALBとECSのスケーリングは属性タブの位置さえ見つければよいレベルで、CloudWatchアラームは機械的に値を入力すればよい区間、ALBアクセスログはポリシーJSONにさえ気をつければよい区間だった。
受験前に準備しておくと良いこと
最も効果的な準備は「接続」を一度手を動かしてやってみることだ。ALBターゲットグループのヘルスチェック・Stickiness・Deregistration delay設定、Security GroupにManaged Prefix Listでルールを追加する作業、VPC LatticeのService Network-VPC Association-Target接続、API GatewayのLambdaプロキシ・CORS・Stage cache/throttle設定、CloudFrontのOrigin・Cache policy・Custom error・WAF設定、CloudWatch AlarmとSNS連携、ALB Access logsとS3バケットポリシーの設定をコンソールで一サイクルずつ回してみると、Broken状態からHealthy状態へ持っていく感覚が身につく。
Prefix Listの名前は事前に覚えておくと試験本番での検索時間を減らせる。vpc-latticeとcloudfront.origin-facing(IPv4)の二つを覚えておき、IPv6のCloudFront一覧と混同しないよう注意する必要がある。
コンソールUIの落とし穴も事前に知っておくとよい。Stickiness設定はAttributesタブにあり、WAF設定はCloudFrontのSecurityタブにあり、CORSはメソッドを作成した後に設定する必要があり、LatticeターゲットがUnhealthyならまずSecurity Groupを疑うべきだ。コンソールの表示言語が変わってもタブの位置自体は同じである。
問題文に書かれた数値は大まかに合わせるのではなく、そのまま転記しなければならない。Desired count、TTL、Rate/Burst、Threshold、Period、Evaluation periods、cookie durationまで正確に合わせる必要があり、自動採点は寛容ではない。
設定を変更した後は常に確認する習慣が重要だ。Target GroupとLattice TargetがHealthy状態か、ECSのDesiredとRunningの数が一致しているか、CloudFrontがDeployed状態か、APIがprodにDeployされているか、S3にログオブジェクトが生成されたかを毎回確認する必要がある。保存ボタンを押してすぐ次の問題に進むと、後のタスクで原因を見つけるのが難しくなる。
時間配分の面では、前半のSG、Lattice、API Gatewayに時間を十分に取り、アラームとアクセスログは後半に素早く処理する方がよい。CloudFrontがDeployed状態になるまで待つ時間は、他の作業(アラーム作成など)と重ねて進めると効率的である。
こんな人におすすめ・非おすすめ
Solutions ArchitectやNetworking系を準備中でコンソール実習が不足している人、VPC Latticeを聞いたことがあるだけの状態から一度手に馴染ませたい人、ALB・ECS・API Gateway・CloudFrontをそれぞれは知っているが一つのアーキテクチャとしてつなげたことがない人におすすめする。逆にVPCやSecurity Group、ALBの基本概念がまだ馴染みのない人、コンソールよりCLI・IaCばかり使ってきてコンソール探索に時間がかかる人であれば、コンソールの動線を事前に身につけてから受験するのがよい。
合格後に残るもの
合格するとCredlyのデジタルバッジが発行され、マイクロクレデンシャルは1年間有効である。9ヶ月が経過すると更新のためにExam Labを再受験できる。
資格の一行よりも実質的に残るのは、マルチVPC環境で「誰が誰を呼ぶのか」をSecurity Group、Lattice、エッジまで一度に設計・修正する感覚である。実務でFrontendとBackendをVPCで分け、内部はLattice、外部はCloudFrontとALBで開くパターンをすでに使っているなら、この試験はその感覚を短く検証してくれる装置になる。まだそのパターンを試したことがなければ、準備過程自体が最も価値ある学びになる。
終わりに
AWS Application Networking Demonstratedは難しい理論試験というより実務型トラブルシューティング試験に近い。リソースはすでに作られており、説明にBROKENというヒントが書かれており、受験者はコンソールでそれを直す。
合格の核心は才能ではなく順序である。ECSとALBをまず生かし、Security Groupを最小権限で開き、LatticeでVPCを接続し、API GatewayとCloudFrontで外部経路を合わせた後、アラームとログで観測可能な状態を作る。
次に受験する方に一つだけ残すとすればこれである。Prefix ListとSecurity Groupをまず完璧に終わらせよ。残りはその上に積み上がる。合格とバッジよりも「なぜUnhealthyなのか」「なぜCORSが壊れるのか」「なぜCloudFrontにWAFが見えないのか」を自分で答えられるようになる方が長く残る。その感覚を持って臨めば、このExam Labは十分に合格できる。