はじめに

デプロイといえば Vercel しか触ったことがありませんでした。git push したら勝手にビルドされて URL が出てくる、あの世界です。ところが仕事のプロジェクトのデプロイ先は AWS。コンソールを開いたら見たことのないサービス名が何百個も並んでいて、「アプリはどこ？URL はどこ？そもそも何がデプロイされてるの？」と、さっぱりわからん状態になりました。Vercel が全部隠してくれていたものが、AWS では全部バラバラに置いてある感じです。

そこで先にコードを触るのをやめて、AWS コンソールで「デプロイの結果」を一周見て回ることにしました。結論、CloudFormation → Lambda → CloudWatch Logs の 3 画面を見られれば、デプロイの成否確認とトラブル調査の入り口には立てると分かったので、後から見返せるように手順をまとめておきます。

対象は自分と同じ「エンジニア初学者で AWS はさっぱり」な人です。題材は Next.js アプリを AWS CDK でデプロイしている dev 環境（東京リージョン）。スクリーンショットのアカウント ID・URL 類は目隠しし、スタック名・関数名は架空のもの（myapp-web-dev など）に差し替えています。

前提: 何がデプロイされているのか

今回の構成はこうなっています。

ブラウザ
  ↓ https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com
API Gateway (HTTP API) ← 玄関。URL の持ち主
  ↓
Lambda (コンテナイメージ = Next.js 一式) ← アプリ本体。ログは CloudWatch へ
  ↑
ECR ← コンテナイメージの置き場（deploy で更新される）

↑ これ全部を設計図から組み立てるのが CloudFormation（CDK が裏で使う）

登場人物の役割分担を家にたとえるとこうです。

サービス	役割	家でいうと	動くタイミング
CloudFormation	設計図どおりに部品を作る・更新する	工務店	デプロイの瞬間だけ
Lambda	プログラムを実行する	キッチン（毎日使う設備）	リクエストが来るたび
API Gateway	アクセスを受けて Lambda に渡す	玄関	リクエストが来るたび
CloudWatch Logs	実行ログの置き場	監視カメラの録画	常時

ポイントは **CloudFormation が「作る側」、Lambda たちは「作られる側」**という上下関係です。並列のサービスだと思っていたので、ここが最初に腹落ちしたところでした。

迷子にならないための 2 つの確認

コンソールにログインしたら、何より先に画面右上を見ます。

リージョンが「アジアパシフィック (東京) ap-northeast-1」になっているか。デフォルトでバージニア北部 (us-east-1) が開くことがあり、そのままだと**何を探しても「見つからない」**状態になります。最初に見事にハマりました
アカウント ID が目的の環境のものか（会社だと dev / 本番でアカウントが分かれていることが多い）

CloudFormation: デプロイの結果が全部見える場所

検索バーに「CloudFormation」と入力してサービスを開くと、スタックの一覧が出ます。スタック = 1 つの設計図から作った部品一式のまとまりです。cdk deploy は「このスタックを設計図の最新版に合わせて更新して」という操作にあたります。

この一覧だけでも「このアカウントで何が動いているか」の地図になります。web・api・database などスタックが役割ごとに分かれていて、CDKToolkit は CDK が使う裏方のスタックです。

出力タブ: アプリの URL はここ

スタックを開いたら、まず「出力」タブ。デプロイ結果として記録された値が並んでいて、WebUrl がアプリの URL です。「あの環境の URL どこだっけ」はここを見れば解決します。

リソースタブ: 作られた部品の一覧

「リソース」タブには、このスタックが作った部品が全部並びます。右上で「フラットビュー」に切り替えると「タイプ」列が見えて分かりやすいです。

見るべきタイプは 3 つだけでした。

タイプ	正体
`AWS::Lambda::Function`	Next.js アプリ本体
`AWS::ApiGatewayV2::Api`	玄関（URL の持ち主）
`AWS::Logs::LogGroup`	ログの置き場

残りの IAM::Role や Lambda::Permission は「付随する権限設定」くらいの理解で先へ進みます。物理 ID のリンクをクリックすると、その部品の実物の画面へ飛べるのが地味に便利です。

イベントタブ: デプロイの履歴と成否

「イベント」タブは時刻つきのデプロイ履歴です。一番上が最新で、UPDATE_COMPLETE なら成功。失敗すると ROLLBACK を含むステータスがここに出るので、デプロイに失敗したら最初に見る場所です。

Lambda: アプリ本体の画面

リソースタブから AWS::Lambda::Function の物理 ID リンクを踏むと、Lambda の画面に飛べます。

「関数の概要」のダイアグラムに API Gateway → Lambda のつながりがそのまま図で出ていて、冒頭の構成図の答え合わせができます。「最終更新日」が最後にデプロイされた時刻なので、「さっきのデプロイ、反映されてる?」の確認にも使えます。

普通の Web サーバーである Next.js が Lambda で動くのは、コンテナイメージに同梱した Lambda Web Adapter が HTTP リクエストとの橋渡しをしてくれているからです（このへんは CDK のコード側の話なので今回は深追いしません）。

CloudWatch Logs: トラブル調査はここから

Lambda の画面の「モニタリング」タブ →「CloudWatch ログを表示」で、この関数のログ置き場（ロググループ）へ飛べます。ロググループの中に「ログストリーム」が実行環境ごとに並ぶので、一番上（最新）を開きます。

開くとログの中身が見えます。ここが一番おもしろかったところで、Lambda の中で Next.js が普通に起動しているのがそのまま見えます。

▲ Next.js 15.5.20
- Local: http://localhost:3000
✓ Ready in 150ms
EXTENSION Name: lambda-adapter State: Ready
START RequestId: 3f993f48-...
END RequestId: 3f993f48-...
REPORT RequestId: 3f993f48-... Duration: 3088.35 ms Billed Duration: 4106 ms Memory Size: 1024 ...

REPORT 行には 1 リクエストぶんの処理時間・課金対象時間・メモリが毎回出ます。アプリが 500 を返したときは、この画面でエラーのスタックトレースを探すのが調査の第一歩になります。

実際にブラウザでアプリを開いてからログ画面を更新すると、自分のアクセスがログ行として増えるのが見えます。「ブラウザで開く → Lambda が動く → ログに残る」の流れを一度体験しておくと、この 3 画面の関係が忘れなくなるのでおすすめです。

で、デプロイはどうやるのか

CDK の場合はこの 2 コマンドです（infra/ が CDK プロジェクトのディレクトリ）。

# 1. 何が変わるかの「予告」を見る（この時点では何も変更されない）
cd infra && AWS_PROFILE=dev npx cdk diff -c env=dev

# 2. 実際に反映する
cd infra && AWS_PROFILE=dev npx cdk deploy -c env=dev

diff → deploy の順に必ず見るのが作法とのこと。コンテナイメージのビルド（npm ci → next build）を伴うので数分かかります。デプロイが走ると、さっきの「イベント」タブに UPDATE_IN_PROGRESS → UPDATE_COMPLETE がリアルタイムで積まれていきます。

※ 事前に aws configure sso --profile dev などでプロファイルの設定が必要です。ここは組織のログイン方式に依存するので割愛。

ハマったところ・覚えておくこと

リージョン違いは「エラーにならない」のがつらい。 何も表示されないだけなので、初心者は壊したのかと焦る。まずリージョンを疑う
CloudFormation のイベントに履歴が数日おきにしか無いのは正常。 工務店（CloudFormation）はデプロイの瞬間しか働かない。毎アクセスで増えるのは CloudWatch のログの方
コンソールは見るだけなら安全。 ただし「スタックを削除」は環境ごと消えるので、削除・編集系のボタンには触らない

まとめ

デプロイの正体は「CloudFormation が設計図どおりに Lambda たちを組み立て直すこと」で、結果は 3 画面で追えます。

CloudFormation のイベントタブ — デプロイの成否
CloudFormation の出力タブ — アプリの URL
CloudWatch Logs — 動いているアプリの中身・エラー調査

デプロイ後に様子がおかしかったら、まずイベントタブで UPDATE_COMPLETE を確認して、次に CloudWatch Logs を開く。この順番だけ覚えて帰ります。

参考