コンピューティング選択 — EC2・Lambda・ECS・Fargate・EKS
この章の目次開く
- コンテンツ追加予定
- 代表サービスの使い分け
- EC2を選ぶ場面
- Lambdaを選ぶ場面
- コンテナ: ECS/Fargate/EKS
- ECR — コンテナイメージの保管庫
- GitリポジトリとECRリポジトリの違い
- イメージとは — アプリを丸ごとパックしたもの
- タグとは — 同じリポジトリ内のイメージを区別するラベル
- 全体の流れ
- 実務でのECR運用ポイント
- 試験でのポイント
- ECS・Fargate・タスク定義の全体像
- タスク定義 — コンテナの実行仕様書
- リビジョン — タスク定義のバージョン管理
- ECRのタグと混同しない
- タスクロール vs タスク実行ロール
- 試験でのポイント
- ECSのログ出力設定
- awslogs ログドライバー（最も一般的）
- Fargateで使えるログドライバー
- Fargateとネットワークモード
- ENIの上限に注意
- まとめ
学習者EC2、Lambda、ECS、Fargateは、どれもアプリを動かせますよね。何を基準に選ぶんですか？
コンピューティングサービスは、アプリケーションをどこで動かすかを決める領域です。SAA-C03では、EC2、Lambda、ECS、Fargate、EKS、Elastic Beanstalkの選択が問われます。
代表サービスの使い分け
| サービス | 向いている用途 |
|---|---|
| EC2 | OSやミドルウェアを細かく制御したい |
| Lambda | イベント駆動、短時間処理、サーバーレス |
| ECS | コンテナをAWSネイティブに運用したい |
| Fargate | サーバー管理なしでコンテナを動かしたい |
| EKS | Kubernetesを使いたい |
| Elastic Beanstalk | アプリを簡単にデプロイしたい |
| AWS Batch | 大量のバッチジョブを実行したい |
試験では「運用負荷を下げたい」「イベント発生時だけ処理したい」「コンテナを使いたい」といった要件から候補を絞ります。
EC2を選ぶ場面
EC2は自由度が高い反面、OSパッチ、スケーリング、監視、可用性設計を自分で考える必要があります。
EC2が候補になる要件:
- OSやカーネル設定を制御したい
- 特定のエージェントやミドルウェアが必要
- GPUや特殊なインスタンスタイプを使いたい
- 既存アプリをそのまま移行したい
Auto ScalingとALBを組み合わせることで、可用性と伸縮性を高めます。
Lambdaを選ぶ場面
Lambdaは、サーバー管理なしでコードを実行するサービスです。
向いている処理:
- S3にファイルが置かれたら処理する
- API Gateway経由で軽量APIを実行する
- EventBridgeのスケジュールで定期実行する
- SQSメッセージを処理する
注意点:
- 実行時間の上限がある
- コールドスタートがある
- ステートレスに設計する
- VPC内接続が必要な場合はネットワーク設計も考える
コンテナ: ECS/Fargate/EKS
コンテナを使う場合、SAA-C03ではECSとFargateがよく出ます。
| 要件 | 選択肢 |
|---|---|
| AWSでシンプルにコンテナ運用したい | ECS |
| EC2管理なしでコンテナを動かしたい | ECS on Fargate |
| Kubernetesエコシステムを使いたい | EKS |
実務では、Kubernetesの明確な理由がなければ、ECS on Fargateの方が運用負荷を下げやすいことがあります。
ECR — コンテナイメージの保管庫
学習者「ECRリポジトリにイメージをpushする」と言われたのですが、リポジトリってGitのことじゃないんですか？コードはもうGitHubにあるのに……
ここでつまずく人はとても多いです。「リポジトリ」という同じ名前で、中身がまったく違うものが2つ登場するからです。まずはこの2つを切り分けましょう。
GitリポジトリとECRリポジトリの違い
| Gitリポジトリ | ECRリポジトリ | |
|---|---|---|
| 保管するもの | ソースコード（テキストファイル） | Dockerイメージ（ビルド済みの実行環境一式） |
| たとえるなら | 料理のレシピ帳 | 完成した冷凍食品の倉庫 |
| バージョン管理の単位 | コミット | イメージ＋タグ |
| 代表的なサービス | GitHub、CodeCommit | ECR、Docker Hub |
先生Gitに入っているのは「作り方」、ECRに入っているのは「できあがった実行パッケージ」です。コードをビルドしてイメージを作り、それをECRに置く——役割が直列につながっているだけで、どちらかがどちらかの代わりになるものではありません。
イメージとは — アプリを丸ごとパックしたもの
Dockerイメージは、アプリのコード、ランタイム（Node.jsやPython本体）、ライブラリ、OSレベルの設定までを1つのパッケージに固めたものです。イメージさえあれば、開発者のPCでもFargateでも同じ環境でアプリが動きます。「ECRイメージ」と呼ばれたら「ECRに保管されたDockerイメージ」という意味です。
タグとは — 同じリポジトリ内のイメージを区別するラベル
1つのECRリポジトリには、ビルドのたびに新しいイメージが積み重なっていきます。それを区別するのがタグで、リポジトリ名:タグ の : の後ろの部分を指します。
my-app:latest ← 最新版という意味でよく使われるタグ
my-app:v1.2.3 ← リリースバージョンで識別
my-app:abc123 ← Gitのコミットハッシュで識別
Gitのタグと考え方は同じで、「特定の1つに名前を付けて参照しやすくする」仕組みです。タグを省略すると latest が暗黙的に使われます。
全体の流れ
コードがユーザーに届くまでの流れを図にすると、こうなります。
Gitリポジトリ（ソースコード）
↓ docker build
Dockerイメージ（実行可能なパッケージ）
↓ docker push
ECRリポジトリ（イメージの保管場所）
├── my-app:v1.2.3
└── my-app:latest
↓ docker pull（タスク実行ロールの権限で）
ECSタスクとして起動
タスク定義には、この保管場所を指すイメージURIを書きます。実際のURIは次のような形式です。
123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1.2.3
（アカウントID）.dkr.ecr.（リージョン）.amazonaws.com/（リポジトリ名）:（タグ）
本番でも latest タグを指定しておけば、常に最新版が動いて便利そうですね！
先生それが実務では定番のアンチパターンなんです。latest は「pushのたびに指す先が変わる」ラベルなので、いつどのバージョンが動いていたのか追跡できず、障害時に前のバージョンへ戻すこともできません。本番では v1.2.3 やコミットハッシュのような動かないタグを使うのが鉄則です。
ECS・Fargate・タスク定義の全体像
学習者ECS、Fargate、タスク定義、サービス、クラスター…… 用語がたくさん出てきて関係性がわかりません。
ECSの構造は、次の5つの層で整理すると見通しが良くなります。
| 層 | 役割 | たとえるなら |
|---|---|---|
| タスク定義 | コンテナの設計図（どのイメージ、CPU/メモリ、環境変数、ポート等） | 料理のレシピ |
| タスク | タスク定義から起動された実体（1つ以上のコンテナの集合） | レシピから実際に作った料理 |
| サービス | タスクの望ましい数を維持し、ALB連携やデプロイ戦略を管理する | キッチンのシフト管理（常に3皿出す等） |
| クラスター | サービスやタスクを論理的にまとめる器 | レストランそのもの |
| Fargate | タスクが実際に動くサーバーレスコンピュート基盤 | 厨房設備をリースで用意してくれる業者 |
先生ECSは「何をどう動かすか」を管理するオーケストレーター。Fargateは「どこで動かすか」を担当するコンピュート基盤、という切り分けです。
Fargateと対になるのが EC2起動タイプ です。EC2起動タイプではEC2インスタンスをクラスターに登録して自分で管理します。Fargateを選ぶとインスタンス管理は不要になりますが、料金がやや高く、GPUアクセスや特定カーネルモジュールなどホストレベルの細かい制御はできません。
タスク定義 — コンテナの実行仕様書
タスク定義は、コンテナをどう動かすかをJSON形式でまとめたテンプレートです。タスク定義そのものがコンテナを動かすのではなく、「こう動かせ」という指示書にあたります。
主な設定項目:
| 項目 | 設定内容 |
|---|---|
| コンテナイメージ | ECRやDocker HubのイメージURI |
| CPU / メモリ | タスク全体およびコンテナごとの割り当て |
| 環境変数 | アプリケーションの設定値 |
| ポートマッピング | ホスト↔コンテナのポート対応 |
| ログ設定 | CloudWatch Logs等への出力先 |
| IAMロール | タスクロール、タスク実行ロール |
リビジョン — タスク定義のバージョン管理
学習者タスク定義を変更したいときはどうするんですか？直接編集できますか？
タスク定義は一度登録すると変更不可（イミュータブル）です。設定を変えたければ、新しいリビジョンとして登録します。
my-app:1 ← 最初の登録
my-app:2 ← メモリを増やした版
my-app:3 ← 環境変数を追加した版
サービスは特定のリビジョンを参照して動くので、デプロイ時に新しいリビジョンを指定してローリングアップデートする流れになります。古いリビジョンは deregister できますが、完全削除ではなく INACTIVE 状態になるだけです。
タスクロール vs タスク実行ロール
学習者タスクロールとタスク実行ロール、名前が似すぎてどっちがどっちかわかりません……
この2つは試験でも実務でも混同しやすいですが、明確に別物です。
| タスク実行ロール（executionRoleArn） | タスクロール（taskRoleArn） | |
|---|---|---|
| 誰が使う？ | ECSエージェント（インフラ側） | コンテナ内のアプリケーションコード |
| いつ使う？ | コンテナを起動するまで | コンテナが動いている間 |
| 代表的な権限 | ECRからのイメージプル、CloudWatch Logsへのログ送信、Secrets Manager / SSM Parameter Storeからの秘密値取得 | S3へのファイル保存、DynamoDBの読み書き、SQSへのメッセージ送信 |
先生ざっくり言えば、実行ロールは「インフラ側の権限」、タスクロールは「アプリ側の権限」です。EC2のインスタンスプロファイルに近いのはタスクロールの方ですね。
ECSのログ出力設定
タスク定義内のコンテナ定義で logConfiguration を指定することで、コンテナのログ出力先を設定します。
awslogs ログドライバー（最も一般的）
CloudWatch Logsに直接送る構成で、最もシンプルです。
設定する3つのパラメータ:
| パラメータ | 内容 |
|---|---|
awslogs-group | CloudWatch Logsのロググループ名 |
awslogs-region | ロググループが存在するリージョン |
awslogs-stream-prefix | ログストリーム名のプレフィックス |
Fargateで使えるログドライバー
| ログドライバー | 用途 |
|---|---|
awslogs | CloudWatch Logsへ直接送信（定番） |
splunk | Splunkへ送信 |
awsfirelens | Fluent Bit / Fluentdで柔軟にルーティング |
学習者FireLensって何が嬉しいんですか？awslogsで十分ではないですか？
awslogsはCloudWatch Logsに送るだけですが、FireLensを使うとFluent BitやFluentdコンテナをサイドカーとして同じタスク内に立て、ログをS3、OpenSearch、Datadog等に柔軟にルーティングできます。「ログを複数の宛先に送りたい」「特定条件でフィルタリングしたい」といった要件が出たらFireLensが候補になります。
Fargateとネットワークモード
学習者Fargateを使うと awsvpc が必須と聞きました。これは何ですか？
Fargateでは、ネットワークモードが awsvpc に限定されます。awsvpc モードでは、各タスクにENI（Elastic Network Interface） が割り当てられ、タスクごとに独自のプライベートIPアドレスを持ちます。
これにより:
- タスク単位でセキュリティグループを適用できる
- VPC内の他リソースと同じネットワークでプライベート通信できる
- ALB / NLBのターゲットとして直接登録できる
まとめ
コンピューティング選択では、制御したい範囲と運用負荷のバランスを見ます。
- OSやミドルウェアまで細かく制御したいならEC2を選ぶ
- イベント駆動ならLambda
- コンテナならECS/Fargate
- Kubernetes要件があるならEKS
- 簡単なデプロイならElastic Beanstalk
次の章では、RDS、Aurora、DynamoDB、ElastiCache、Redshiftなどのデータベース選択を扱います。
