← AWSサービスの内部原理 コース
81. Fargateは1タスク=1つの小さなVMである — Lambdaと同じFirecrackerが境界を引く
ECSの起動タイプを「分離の境界線はどこに引かれているか」という1つの問いで貫きながら、EC2起動タイプの同居からFargateのmicroVMまでを図で追っていきます。
① 問いは1つ:「壁はどこに立っているか」
コンテナを動かす同じゴール
壁の位置が変わる
EC2起動タイプ自分で用意したEC2群にタスクを詰め込む
Fargate起動タイプサーバー用意・パッチ・詰め込み最適化ごとAWSが引き受ける
同じ問いで貫く
コンテナ境界namespaces / cgroups
タスクごとのVM境界microVM
壁はどこか分離の境界線はどこに引かれ、どこまで頑丈か?
- 公式は起動タイプを「どこまで自分で管理するか」の違いとして説明する。EC2では「サーバー種別を選び、いつスケールするか決め、クラスターの詰め込みを最適化する」責任が利用者に残る。
- Fargateは「サーバーやEC2インスタンスのクラスターを管理せずにコンテナを実行する技術」であり、これらの責任を取り除く。
起動タイプの違いは機能の多寡ではなく、分離の壁をどの層に立てるか・誰が保守するかの違い。この1本はその壁の位置だけを見ていく。
② EC2起動タイプ:同じカーネルの上に同居する
タスクAnamespaces + cgroups
タスクBnamespaces + cgroups
タスクCnamespaces + cgroups
境界を破ると
共有カーネル隔離はプロセス視点の"見え方"を分けているだけ
Linuxカーネルは全タスクで1つホストに到達同居タスクの領域まで見えてしまう
IMDSに到達インスタンスプロファイルの認証情報を含む機微データ
169.254.169.254、既定ではコンテナから手が届きうる- 公式ベストプラクティスは「安全でない、作りの粗いイメージは、攻撃者がコンテナの境界を抜けてホストにアクセスすることを許しうる(an attacker to escape the bounds of the container and gain access to the host)」と明言。
- EC2で動かすタスクには「コンテナがEC2インスタンスメタデータサービス(IMDS)にアクセスするのを強くブロック推奨。インスタンスのインスタンスプロファイル認証情報を含む機微なインスタンスレベルのデータに届いてしまうため」と警告。
- 遮断はネットワークモード別に、bridgeモードならiptables、awsvpcモードなら ECS_AWSVPC_BLOCK_IMDS=true と、利用者側の作業として案内されている。
第1レッスンで見たnamespaces/cgroupsは「1つのカーネルを共有したまま見え方を分ける」隔離。だからEC2起動タイプでは、IMDS経由のインスタンス認証情報への到達を利用者が自分で塞ぐ必要が残り、コンテナ境界を抜ければホスト——同居タスクの領域——まで見えてしまう。公式が「イメージはコンテナ境界を抜けさせうる」と釘を刺す層である。
③ Fargate:1タスク=自分専用の分離境界
タスクAmicroVM:専用カーネル・CPU/Mem・ENI
タスクBmicroVM:専用カーネル・CPU/Mem・ENI
タスクCmicroVM:専用カーネル・CPU/Mem・ENI
共有しないカーネル・CPU・メモリ・ENIを他タスクと共有しない
- 公式ドキュメントの核心の一文——「各Fargateタスクは自分自身の分離境界を持ち、基盤のカーネル・CPUリソース・メモリリソース・elastic network interfaceを他のタスクと共有しない(Each Fargate task has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task)」。
- awsvpcネットワークモードもFargateでは既定で、②でEC2側が手作業で足していたタスク単位のネットワーク隔離が最初から入っている。
②で「利用者が自分で塞ぐ」だったものが、Fargateでは壁の位置そのものが1段深くなり不要になる。共有されるカーネルが無いので、「境界を抜けて隣に届く」という前提が成り立たない。
④ その壁の正体:Firecracker microVM
Lambda編関数の実行環境を包んでいたもの
Fargate1タスクを包むもの
軽さと攻撃面の絞り込み
FirecrackerLinuxのKVMを用いる軽量VMM(virtual machine monitor)
結果
< 5 MiBmicroVM1台あたりのメモリオーバーヘッド
125 ms級ユーザーコードの起動
攻撃面縮小不要なデバイス/ゲスト機能を除外
jailer第二の防衛線を追加
もう1枚の壁namespacesの"外側"に、カーネルごと分ける壁を立てる
- Firecracker公式より——「Firecrackerは安全なマルチテナントのコンテナ/関数サービスのために作られたオープンソースの仮想化技術」「LinuxのKVMを用いてmicroVMを作成・管理するVMM」。
- 数値は執筆時に公式で確認:「各microVMのメモリオーバーヘッドは5 MiB未満」「ユーザー空間/アプリケーションコードを最短125 msで起動」。
- 「AWSがAWS LambdaとAWS Fargateの体験改善のために開発した」と明記され、Lambda編で学んだ壁とFargateの壁が同一技術であることが裏取りできる。
Lambda編で「関数を包む小さなVM」として登場したFirecrackerが、ここでは「1タスクを包む小さなVM」として再登場する。仮想化とマルチテナントの信頼境界というCS基礎の、同じ答えが2度出てくる回。
⑤ 隔離の強さは「層」で決まる
プロセス同一カーネル・同一名前空間。ほぼ素通し
壁を1段深く
namespaces+cgroups見え方と資源枠を分けるが、カーネルは共有
EC2起動タイプのコンテナはここ壁を1段深く
microVMカーネルごと分離。CPU/Mem/ENIも専用
Fargateのタスクはここ物理マシン何も共有しない。最も強く、最も高コスト
- この階段は「namespaces/cgroupsは同一カーネル共有」「Fargateタスクはカーネル・CPU・メモリ・ENIを共有しない」という②③の公式記述を、強度の順に並べ直したもの。
- マネージドの度合い(S3編・Lambda編で見た「どこまで自分で管理するか」)とも軸が重なる:壁が深くAWS管理に寄るほど、利用者が塞ぐべき穴は減る。
「コンテナ vs VM、どっちが安全?」は二択ではなく、壁がどの層に立つかという連続した階段。Fargateは、EC2起動タイプより1段深い層(microVM)に既定で壁を立てる選択肢だと読める。
⑥ 壁の保守は宣言的に回る:プラットフォームバージョン
PFバージョンカーネル+コンテナランタイムのバージョンの組を指す名前
脆弱リビジョン上のタスクを計画的に退役
脆弱性発見AWSがパッチ済みの新リビジョンを作成
キャパシティの選択肢
パッチが回る基盤のパッチが利用者の操作なしに更新される
Fargate安定・自分専用のmicroVM
Fargate Spot余剰キャパを割引で使用
回収時は2分前に警告Managed InstancesEC2の柔軟性+AWS管理の"第3の選択肢"
- 公式より——プラットフォームバージョンは「カーネルとコンテナランタイムのバージョンの組み合わせ」。「Fargateで動く新規タスクは常にプラットフォームバージョンの最新リビジョンで起動し、常に安全でパッチ済みの基盤で開始されることを保証する」。
- 「既存プラットフォームバージョンに影響するセキュリティ問題が見つかった場合、AWSはパッチ済みの新リビジョンを作り、脆弱なリビジョン上で動くタスクを退役させる」。
- Fargate Spotは「余剰コンピュートキャパシティ上で割引価格で実行し、AWSがキャパシティを取り戻す必要が生じるとタスクは2分前の警告付きで中断される」。
- Amazon ECS Managed Instancesは製品ページで「インフラ管理のオーバーヘッドを取り除きつつ、幅広いEC2の能力(GPUやネットワーク最適化インスタンス等の選択)へのアクセスを提供する、フルマネージドのコンピュートオプション」とされ、「AWSがインスタンス設定・キャパシティ調達・ワークロード配置・パッチ・スケーリング・保守を担う」(いずれも執筆時に公式で確認)。
Fargateの「サーバーレス」は、壁を立てるだけでなく壁の保守まで宣言的に回すこと——利用者は最新を明示しなくても最新に乗り、脆弱な基盤は計画退役で押し出される。EC2の柔軟性を残しつつ保守だけAWSに寄せたい層のために、ECS Managed Instancesという中間の選択肢も用意されている。