AWS Certified CloudOps Engineer - Associate (SOA-C03) #9 Domain 3-3 デプロイ — コンテナ運用 (ECS・EKS・ECR)
#7·#8 でインフラのデプロイとインスタンス運用を整理しました。この記事は SOA-C03 で新しく入ったコンテナ運用 です。旧 SOA-C02 にはコンテナの範囲がほとんどありませんでしたが、CloudOps Engineer に改名されて ECS・EKS・ECR が出題範囲に入りました。試験はコンテナを「どう作るか」ではなく 「どう運用するか」(デプロイ・ロギング・スケーリング・イメージ管理) を問います。
ECS vs EKS: 何を選ぶか #
| 項目 | ECS | EKS |
|---|---|---|
| 性格 | AWS 独自のコンテナオーケストレーター | マネージド Kubernetes |
| 学習曲線 | 低い。AWS に深く統合 | 高い。K8s エコシステム |
| いつ | AWS の中でシンプルに | K8s 標準・マルチクラウド・既存 K8s 資産 |
核心の区別はシンプルです。K8s がどうしても必要な理由 (標準互換・既存資産・マルチクラウド) がなければ ECS、K8s エコシステムを使う必要があれば EKS です。運用負担を最小化する条件ではおおむね ECS が、特に Fargate と組み合わせると さらにその傾向が強まります。
起動タイプ: Fargate vs EC2 #
ECS と EKS のどちらも、コンテナを実際に動かす コンピューティング を選ぶ必要があります。
| タイプ | 誰がサーバーを管理 | いつ |
|---|---|---|
| Fargate | AWS (サーバーレス)。インスタンス管理なし | 運用負担の最小化、可変負荷 |
| EC2 | ユーザーがインスタンスを管理 | きめ細かな制御・特殊なインスタンス・コスト最適化 |
「コンテナを動かすが、インスタンスのパッチ・スケーリングを気にしたくない」という答えが Fargate です。逆に GPU や特定のインスタンスタイプが必要だったり、使用率が高くて EC2 のほうが安い場合は EC2 起動タイプです。
ECR: イメージレジストリ #
ECR はコンテナイメージを保存する プライベートレジストリ です。運用ポイントは次のとおりです。
- イメージスキャン: プッシュ時または常時の 脆弱性 (CVE) スキャン。セキュリティ運用の定番
- ライフサイクルポリシー: 古い・未使用のイメージを自動整理してストレージコストを管理
- 権限: IAM とリポジトリポリシーでアクセスを制御。クロスアカウント共有が可能
- レプリケーション: クロスリージョン・クロスアカウントのレプリケーションでデプロイ遅延の短縮と DR
「コンテナイメージの脆弱性をデプロイ前に捕まえよ」という答えが ECR のイメージスキャンです。「イメージが溜まり続けてコストが増える」はライフサイクルポリシーです。
コンテナのロギングとモニタリング #
#2·#3 の CloudWatch がコンテナにもそのまま続きます。
| 対象 | 運用方法 |
|---|---|
| ログ | ECS は awslogs ログドライバーで CloudWatch Logs に送信。FireLens (FluentBit) で他の対象も可能 |
| メトリクス | Container Insights で CPU・メモリ・タスク数などのコンテナメトリクスを収集 |
| トレース | X-Ray で分散トレーシング |
Container Insights(コンテナインサイト)がコンテナモニタリングの核心となる名前です。「ECS・EKS のコンテナ単位のパフォーマンスを一目で見よ」という答えが Container Insights です。基本の EC2 メトリクスだけではコンテナの中が見えません。
デプロイとスケーリングの運用 #
- ローリングアップデート: タスクを段階的に置き換え。デフォルトのデプロイ方式
- ブルー/グリーン(CodeDeploy 連携): 新バージョンを別に立ち上げて切り替え。高速なロールバック
- Service Auto Scaling: メトリクス (CPU・リクエスト数) に応じてタスク数を自動調整
- タスク定義(Task Definition): コンテナイメージ・CPU・メモリ・環境変数・IAM ロール (タスクロール) を宣言
運用セキュリティのポイントの一つが タスクロール(Task Role)です。コンテナが AWS API を呼び出すときに使う権限で、EC2 インスタンスロールではなく タスク単位で最小権限 を付与するのが定石です。
試験での出題パターン #
- K8s が必須ではなく運用負担の最小化 → ECS + Fargate
- インスタンス管理なしでコンテナ実行 → Fargate
- イメージの脆弱性をデプロイ前に検知 → ECR イメージスキャン
- 未使用イメージでコスト増加 → ECR ライフサイクルポリシー
- コンテナ単位のパフォーマンスモニタリング → Container Insights
- コンテナが AWS API を呼び出す → タスクロール(最小権限)
- 高速なロールバックが必要なデプロイ → ブルー/グリーン(CodeDeploy)
よくある落とし穴 #
1) EC2 メトリクスでコンテナが見えると思う #
基本の EC2 メトリクスはインスタンス全体しか見ません。コンテナ・タスク単位は Container Insights があってこそ見えます。
2) コンテナの権限をインスタンスロールで与える #
複数のタスクが 1 つのインスタンスを共有すると、インスタンスロールは過剰な権限になります。タスクロール でタスクごとの最小権限を与えます。
3) 運用負担の最小化なのに EC2 起動タイプを選ぶ #
特別な理由がなければ運用負担の最小化の答えは Fargate です。
4) ログが自動で CloudWatch に行くと仮定する #
ECS は ログドライバー (awslogs) や FireLens の設定 があってこそ CloudWatch Logs に送ります。
まとめ #
この記事で押さえたこと:
- ECS(AWS ネイティブ・シンプル)vs EKS(マネージド K8s)。特別な理由がなければ ECS
- Fargate(サーバーレス・運用負担最小)vs EC2 起動タイプ(きめ細かな制御・コスト)。運用負担の最小化は Fargate
- ECR: イメージスキャン (脆弱性)・ライフサイクルポリシー (コスト)・クロスリージョンレプリケーション
- Container Insights でコンテナ単位のメトリクス、
awslogs・FireLens でログ - タスクロール でコンテナごとの最小権限。インスタンスロールで与えない
次: Domain 4-1 VPC 運用とトラブルシューティング #
デプロイ・自動化ドメインを終えました。次は 4 番目のドメインである ネットワーキングとコンテンツ配信 です。
#10 Domain 4-1 ネットワーキング: VPC 運用と接続トラブルシューティング では、ルートテーブルとゲートウェイ、セキュリティグループと NACL の違い、VPC ピアリングとエンドポイント、そして接続できないときにどこをどの順序で点検するかを運用の観点で整理します。