はじめに
AWSにおけるコンテナ運用は、Amazon ECS（Elastic Container Service）とAmazon EKS（Elastic Kubernetes Service）を中心に、FargateやEC2 Launch Typeを選択肢として持つことで、柔軟かつスケーラブルなインフラ設計が可能です。
本章では、以下のポイントに沿って、コンテナ環境の選定・構築・運用のベストプラクティスを解説します。
- FargateとEC2 Launch Typeの使い分け
- ECSのAuto ScalingとTask定義最適化
- EKSクラスタ設計とIAMロール連携
- クラスタメトリクスと可観測性の強化
Fargate vs EC2 Launch Type
Fargateとは？
Fargateは、コンテナを実行するためのサーバーレスな実行基盤です。EC2インスタンスを管理せずに、リソース単位（vCPU/メモリ）でコンテナを定義できます。
メリット
- インフラ管理不要（OSパッチ、容量計算なし）
- 起動ごとの秒単位課金（細かいリソース単位で最適化）
- セキュリティ（VMレベルでのアイソレーション）
EC2 Launch Typeとは？
EC2タイプは、自己管理のインスタンス上でコンテナを実行する構成です。自由度は高い反面、運用管理の手間が増えます。
メリット
- 既存の運用ノウハウ（sshアクセスや監視）が活かせる
- 1台のEC2上で複数タスクを密に配置できる
- スポットインスタンスと組み合わせてコスト最適化が可能
選定の目安
| ユースケース | 推奨タイプ |
|---|---|
| 短期バッチ処理、イベント駆動 | Fargate |
| 高頻度なスケーリング | Fargate |
| 常駐型ワーカー、コスト重視 | EC2（+スポット） |
| 独自AMIsや特殊ミドルウェア | EC2 |
AutoScaling・Task定義の最適化
Service Auto Scaling（ECS）
ECSでは、タスク数を自動的に増減できる Service Auto Scaling が用意されています。以下の指標をもとにスケーリングが可能です：
- CPU使用率 / メモリ使用率
- カスタムメトリクス（SQSキュー長など）
# CloudWatch Alarmをトリガーにスケーリング設定（例） aws application-autoscaling put-scaling-policy \ --service-namespace ecs \ --resource-id service/default/web-app \ --scalable-dimension ecs:service:DesiredCount \ --policy-name cpu-scaleout \ --policy-type TargetTrackingScaling \ --target-tracking-scaling-policy-configuration file://tracking-config.json Task定義最適化のポイント
- vCPUとメモリを正確に見積もることでFargate課金を最小化
- ログ出力はCloudWatch Logsを活用（構造化ログ推奨）
- 環境変数のセキュア管理にはSecrets Manager連携を活用
EKSクラスタ設計とIAMロール連携
EKSの概要と特徴
EKSは、マネージドなKubernetesクラスタサービスで、標準K8s API互換 + AWSサービス連携という強みがあります。
クラスタ設計の観点
- ノードグループ（マネージド or 自前で構築）
- Fargateプロファイルを使ってPod単位の実行基盤を選択
- クラスターアドオン（CoreDNS, kube-proxyなど）を事前に確認
IAM Roles for Service Accounts（IRSA）
EKSでは、KubernetesのServiceAccountとIAMロールを紐づけることで、Podごとに最小権限IAMロールを適用できます。
# OIDCとIAMロール連携の設定例 eksctl utils associate-iam-oidc-provider \ --region ap-northeast-1 \ --cluster my-eks-cluster \ --approve eksctl create iamserviceaccount \ --name s3-reader \ --namespace default \ --cluster my-eks-cluster \ --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \ --approve IRSAを使うことで、EKSにおけるIAMロールの粒度をPodレベルで制御でき、セキュリティと運用性の両立が可能です。
クラスタメトリクスと可観測性
可観測性とは？
可観測性（Observability）は、システムの状態を外部から正確に把握できる仕組みを意味します。コンテナ環境では、メトリクス、ログ、トレースの3要素が重要です。
ECSにおける監視
- CloudWatch Container InsightsでCPU/メモリ/ネットワークなどを可視化
- カスタムメトリクスやログ出力の活用
- Taskレベル、Serviceレベルのアラーム設定
EKSにおける監視
- Prometheus + Grafana でK8sメトリクス可視化
- AWS Managed Prometheus & Grafanaの導入で運用負荷軽減
- X-Ray + CloudWatch Logsによるトレーシングとログ分析
# PodにX-Ray Daemon Sidecarを追加してトレーシング収集 containers: - name: my-app image: my-app-image - name: xray-daemon image: amazon/aws-xray-daemon ports: - containerPort: 2000 ECSでもEKSでも、CloudWatch Logs + メトリクス + X-Rayの三位一体で監視とトラブル対応が可能になります。
まとめ
ECS、EKS、Fargateを使い分けながら、要件に応じたコンテナ基盤を構築・運用することが、AWSにおけるモダンアプリケーション設計の基礎です。
- Fargateは運用負荷の少ない選択肢、EC2は柔軟性重視
- ECSではAuto ScalingとTask定義を最適化してコスト削減
- EKSではIRSAでセキュアなIAM連携を実現
- クラスタの可観測性を高めることで安定運用と迅速な障害対応が可能に
次章では、これらコンテナ基盤のCI/CD統合やInfrastructure as Code（IaC）による自動化運用に取り組んでいきます。
