最近、プロジェクトをAWS ECS (Fargate) でデプロイしたのですが、想像以上に多くの試行錯誤（いわゆる「沼」）を経験しました。
単なるデプロイ手順だけでなく、実務で必須となる Secrets Managerとの連携 や セキュリティグループの設定 など、私がハマったポイントが誰かの近道になれば幸いです。
- Dockerイメージ：GHCRからECRへの乗り換え
当初はGitHub Container Registry (GHCR) を利用する予定でしたが、プライベートリポジトリの権限周りで 401 Unauthorized エラーに直面。
悩んだ末、同じAWS環境内にある専用レジストリ、ECR (Elastic Container Registry) にイメージを移すことにしました。
解決までのステップ
ローカル作業： docker pull でイメージを取得し、AWS CLIのインストールと aws configure を完了。
IAM権限： ECRにイメージをプッシュできるよう、IAMユーザーに AmazonEC2ContainerRegistryFullAccess 権限を付与しました。
プッシュ：
aws ecr get-login-password でログイン。
docker tag でイメージにECRのタグを付与。
docker push でイメージのアップロードに成功！
- ECS「Expressモード」の罠とタスク定義
ECSには初心者向けの Express（簡易設定）モード があります。一見便利そうですが、これが意外な落とし穴でした。設定が簡略化されすぎていて、Secrets Managerとの連携 といった詳細な設定を行う場所が見つからないのです。
学んだこと
Expressモードはあくまでクイックテスト用。実際の運用環境（環境変数の注入などが必要な場合）では、「標準（Standard）」設定 が必須です。
すべての設定の肝は 「タスク定義 (Task Definition)」 にあり、設定を変更するたびに新しい リビジョン（改訂版） を作成する必要があります。
- 今回のメイン：Secrets Managerの値を環境変数に注入
ここが一番苦労したポイントです。コード側で process.env.DB_PASSWORD のように値を読み取るには、単に値を入力するだけではなく、「権限」 と 「形式」 を完璧に合わせる必要がありました。
設定のコツ
IAMロールの修正：
ECSが秘密情報を読み取れるよう、ecsTaskExecutionRole に SecretsManagerReadWrite ポリシーを追加しました。これが抜けていると、コンテナは起動できずにすぐ落ちてしまいます。
ARNの形式に注意：
Secret全体ではなく「特定のキー」だけを取得する場合、ARNの末尾に :キー名:: を付ける必要があります。
例：arn:aws:secretsmanager:region:account
name:DB_PASSWORD::
ValueFromの設定：
タスク定義の編集画面で、環境変数のタイプを「Value」ではなく 「ValueFrom」 に設定することで、ARN経由で実際の値が注入されます。
- 最後の壁：セキュリティグループ (Security Group)
デプロイ自体は成功し、ステータスも RUNNING になっている。なのに、ブラウザでアクセスしても無限ロードが続く…。原因はAWSの基本の「き」、セキュリティグループ でした。
解決策
EC2コンソールへ移動： Fargateを使っていても、セキュリティグループの管理はEC2のコンソールで行います。
インバウンドルールの編集： 使用しているセキュリティグループに、アプリのポート（例：3000番）を追加。
ソースを 0.0.0.0/0 に： どこからでもアクセスを許可するように設定した瞬間、無事に画面が表示されました！
- 最終デプロイと確認
すべての設定を終えた後、サービスの更新時に [新しいデプロイの強制 (Force new deployment)] にチェックを入れ、最新の設定が反映されたコンテナを立ち上げました。
振り返り
「コーディングよりインフラが難しい」と感じるのは、ロジックの問題ではなく、「権限 (IAM)」 と 「通信経路 (セキュリティグループ)」 の戦いだからだということがよく分かりました。
同じようにECSのデプロイで「ResourceInitializationError」などのエラーに苦しんでいる方は、ぜひ ARNのタイポ と IAM権限 を真っ先に疑ってみてください！