個人目標としての学習テーマ

これまで触れてこなかったAWSサービスを 手を動かして 学ぶ

• ECS マネージドなコンテナオーケストレーション
• ECR コンテナイメージのレジストリ
• Fargate サーバーレスでコンテナを動かす基盤
• CloudFormation インフラをコードで管理（IaC）

「Lambda は使える、でもコンテナと IaC は経験が薄い」を解消する

今日のゴール

• 4サービスの 役割 と 関係 が説明できる
• どんなときに使うのか、肌感覚を持てる
• 学習で詰まったポイントと、次にやることを共有

全体像を共有してフィードバックをもらうことが目的

既存の選択肢だけでは足りない場面

コンテナ × マネージド で、Lambda と EC2 のすき間を埋める

IaC を使う理由

手順書とコンソール手作業で構築すると 再現できない

• 環境差分（dev / stg / prod）を 同じ定義 で作りたい
• レビューと履歴管理を Git で 行いたい
• 壊れても 同じ状態に戻せる ようにしたい

インフラも「アプリのコード」と同じように扱う

ECS（Elastic Container Service）

AWS が提供する コンテナオーケストレーター

• 「どのコンテナを、いくつ、どこで動かすか」を宣言的に管理
• ALB との連携、ヘルスチェック、ローリングデプロイが標準装備
• Kubernetes（EKS）に比べて 学習コストが低い AWS 流の選択肢

アプリは Docker イメージ、運用は AWS が面倒を見る

ECS の主要コンポーネント

ECS の起動タイプ

コンテナを どこで動かすか を選ぶ

今回は Fargate 起動タイプ で進める

ECR（Elastic Container Registry）

AWS マネージドの プライベート Docker レジストリ

• IAM で権限管理ができる、AWS 内の Docker Hub
• ECS / EKS / Lambda（コンテナ image）から 直接 pull 可能
• イメージスキャン（脆弱性検査）を標準で実行できる

# build → ECR へ push の典型フロー
aws ecr get-login-password | docker login --username AWS \
  --password-stdin <account>.dkr.ecr.ap-northeast-1.amazonaws.com
docker build -t myapp .
docker tag myapp:latest <account>.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest
docker push <account>.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest

ECR で覚えておきたいこと

• ライフサイクルポリシー で古いイメージを自動削除（容量課金対策）
• イミュータブルタグ を有効化すると同じタグの上書きを防げる
• クロスリージョンレプリケーション でマルチリージョン展開もできる

イメージは「資産」であり「コスト」 タグ運用は最初に決める

Fargate

ECS / EKS のための サーバレスなコンピューティングエンジン

• ホストの OS パッチ・キャパシティ管理が 不要
• vCPU と メモリを宣言するだけで AWS が裏で実行基盤を準備
• 秒単位課金 スパイクに強い

Fargate のメリットとトレードオフ

「運用工数を金で買う」 小〜中規模・運用人数が少ない案件で効く

CloudFormation

AWS リソースを YAML / JSON テンプレート で宣言的に管理する IaC サービス

• AWS 公式 ＝ 追加課金なし、対応リソース範囲が広い
• スタック 単位で作成・更新・削除をまとめて行える
• 変更セット（Change Set）で適用前に差分を確認できる

Terraform と比較されがちだが、AWS 専業なら有力な選択肢

テンプレートのイメージ

ECR リポジトリ を 1 つ作るだけの最小例

AWSTemplateFormatVersion: '2010-09-09'
Description: Minimal ECR repository

Resources:
  AppRepository:
    Type: AWS::ECR::Repository
    Properties:
      RepositoryName: myapp
      ImageScanningConfiguration:
        ScanOnPush: true
      ImageTagMutability: IMMUTABLE

Outputs:
  RepositoryUri:
    Value: !GetAtt AppRepository.RepositoryUri

aws cloudformation deploy で作成、削除も delete-stack 一発

CloudFormation で詰まりやすいポイント

• 更新できないプロパティ がある（例：RDS のエンジン種別）
  • 変更すると 置換（既存リソース削除 + 再作成）が走る
• 削除保護 をかけた DB は delete-stack で消えない
• ネスト・依存 が深いと変更の影響範囲が読みにくい
  • cfn-lint と Change Set を 必ず 通す

「壊して作り直す」が前提のリソース設計を意識する

全体像

• CloudFormation が ECR / ECS / Fargate を一括定義
• ECR に push したイメージを ECS Task が pull
• Fargate がサーバ管理なしで Task を実行
• ALB がリクエストを Task に振り分け

学習の流れ（実際にやったこと）

1. 手で構築 マネジメントコンソールで ECR + ECS + Fargate を一通り作る
2. 理解の整理 「何をしているか」を自分の言葉でメモ
3. CloudFormation 化 同じ構成を YAML で再現
4. 壊して作り直す スタック削除 → デプロイで再現性を確認

触る → 言語化 → コード化 の順で定着した

つまずきポイントと学び

まとめ

1. ECS / ECR / Fargate で Lambda と EC2 のすき間を埋められる
2. CloudFormation でインフラを Git 管理 ＝ 再現性が手に入る
3. 既存の運用知識（IAM・VPC・ALB）が そのまま活きる

「コンテナ × IaC」は SRE の標準装備、ここを起点に広げていく

次にやること

• CI/CD 連携 GitHub Actions から ECR push → ECS デプロイ
• CDK への乗り換え検討 TypeScript で書ける IaC との比較
• App Runner / ECS Anywhere など隣接サービスの位置づけ整理
• 学んだ内容を チームの Wiki に残す（個人目標の +1）