はじめに
こんにちは！ コーポレートIT室（CIT室）の nakao です。
普段はAWSのインフラ構築、いわゆるSRE業務を主に担当しています。
今回は、「新しいAWSサービスを調査した結果、あえて採用しなかった」 という話をしたいと思います。
新機能の発表があると、「使ってみたい！」と飛びつきたくなるのはエンジニアの性ですよね。
でも今回は、じっくり調査した結果、見送るという判断をしました。その調査の過程と判断の理由を、できるだけ丁寧に書いていきます。同じような状況で悩んでいる方の参考になれば幸いです！
なお、実際の調査・リプレイス作業は2025年末〜2026年2月にかけて行ったものです。ブログにまとめるのが少し遅くなってしまいましたが、2026年6月現在も調査時点の制約に変更はないことを確認した上で公開しています。
背景：cronバッチをECSへ移行しようとしていた
まず、今回の話の背景から説明します。
私のチームでは、cronスケジュールで起動するバッチ処理を長らくEC2上で運用していました。
しかし、EC2でバッチを運用するのは何かと手間がかかります。OSのアップデート管理、インスタンスの起動・停止の管理、スケーリングへの対応…。
「もっとサーバーレスに近い形で運用できないか」というのがチームの課題感でした。
そこで、ECS on Fargate（後述）へのリプレイスを検討し始めていた、まさにそのタイミングで、AWSから新しいサービスの発表がありました。
それがAmazon ECS Managed Instancesです。
チームで情報を共有し、メンバーの協力を得ながら調査を進めることになりました。
そもそもECSって何？という方へ
本題に入る前に、登場人物を簡単に整理しておきましょう。ECSに慣れている方はここは読み飛ばしてください！
Amazon ECS（Elastic Container Service） とは、AWSが提供するコンテナ（Dockerなど）を管理・実行するためのサービスです。コンテナを「どこで動かすか」という点で、大きく2つの選択肢がありました（今回の発表前まで）。
① ECS on EC2 自分でEC2インスタンスを用意して、その上でコンテナを動かす方法です。インスタンスの管理は自分でやる必要がありますが、EC2の豊富なオプション（インスタンスタイプ、ネットワークモードなど）をフルに使えるのが強みです。
② ECS on Fargate インスタンスの管理をAWSに完全に任せる、いわゆる「サーバーレス」の選択肢です。「コンテナを動かしたい」という要件だけ伝えれば、インフラの面倒はAWSが見てくれます。その分、EC2に比べるとカスタマイズの自由度は下がります。 そして今回発表されたのが——
③ ECS Managed Instances（2025年9月発表） 「FargateのシンプルさとEC2の柔軟性、両方のいいとこ取り」を目指した新しい選択肢です。EC2インスタンスはあくまで自分のAWSアカウント内に存在しますが、インスタンスのプロビジョニング・スケーリング・セキュリティパッチ適用といったインフラ管理はAWSが担ってくれます。
| ECS on EC2 | ECS Managed Instances | ECS on Fargate | |
|---|---|---|---|
| インフラ管理 | 自分で行う | AWSが担う | AWSが担う |
| EC2の柔軟性 | ◎ フル活用可 | ○ 幅広く対応 | △ 制限あり |
| 運用の手軽さ | △ 手間がかかる | ○ 自動化 | ◎ サーバーレス |
これは確かに魅力的な選択肢に見えます。私たちが特に期待したのは、Fargateよりコストを抑えられる可能性と、EC2のようなインフラ管理の手間がなくなるという2点です。ECS on EC2では自分でインスタンス管理が必要、Fargateはサーバーレスで楽だがコストが高め——その中間を埋める選択肢として、「もしかして、これが今回のバッチ移行にぴったりでは？」と思うのも無理はありませんでした。
調査開始：まずは基本的な仕様を確認
まず、ECS Managed Instancesが私たちのバッチ構成に使えるか、基本的な仕様から確認していきました。
私たちの既存バッチの前提条件として特に重要だったのが、「パブリックサブネットで動かしている」 という点です。バッチタスクはパブリックサブネットに配置して外部APIへアクセスする機能を持ちます。またパブリックIPを持たせた上でECRからイメージをプルしていました。この構成は、コストとシンプルさのバランスが取れており、チームとしてFargate移行後もこの構成を維持したいと考えていました。
調査を進めるうちに、ネットワーク周りにいくつかの制約があることがわかってきました。
壁①：タスクにパブリックIPを付与できない
調査の中で判明した最初の大きな制約が、ECS Managed Instancesではタスクのネットワークインターフェース（ENI）にパブリックIPを付与できないという点です。
公式ドキュメント（Allocate a network interface for tasks on Amazon ECS Managed Instances）を確認したところ、assignPublicIpを使ったタスクENIへのパブリックIP付与は非対応と明記されていました。
補足しますと、ECS Managed Instancesのインスタンス自体はパブリックサブネットに配置でき、インスタンスにパブリックIPを持たせることもできます。この場合、ECRからのイメージプルはインスタンスのプライマリENI経由で行われるため、タスクにパブリックIPがなくてもNAT GatewayなしでECRプルが可能です。
ただし、外部APIへのアクセスはタスクのENI（プライベートIPのみ）を経由するため、インスタンスをパブリックサブネットに置いても解決しません。NAT Gatewayが別途必要になります。なお、VPC内のリソースとのみ通信するワークロードであれば、このパターンで問題なく動作します。
今回の私たちのバッチは処理の中で外部APIへの通信が必要だったため、このパターンでは対応できませんでした。
壁②：プライベートサブネット運用はコストが現実的でない
「ならばNAT Gatewayを用意してプライベートサブネットで動かせばいいのでは？」と思うかもしれません。しかし、これにはコストの問題がありました。
私たちのバッチは起動回数が非常に多く、Fargateはタスク起動のたびにECRからイメージをプルする（EC2と異なりFargateはイメージをキャッシュしない）ため、その分のデータ転送コストがそのままかさんでいきます。加えて、外部API通信のトラフィックもNAT Gatewayを経由することになり、コストはさらに膨らみます。試算の結果、どの選択肢を取っても現実的なコストには収まりませんでした。
また、「外部通信が必要なバッチだけ切り出してNAT Gateway経由の構成にする」という案も検討しましたが、構成変更の手間だけでなく、その後の運用管理も複雑になるため、現実的ではありませんでした。
一方で、ECS on Fargateをパブリックサブネット＋パブリックIPで動かす場合はパブリックIPの料金のみで済みます。この差は非常に大きく、コスト面でもFargateの方が明確に優れていました。
壁③：bridgeモードにも対応していなかった
また、調査の中で、ネットワークモードにも制約があることがわかりました。
ECSには「コンテナのネットワークをどう構成するか」を決めるネットワークモードという概念があります。
bridgeモード：Dockerの仮想ネットワークを使う方式。EC2上での利用実績が長く、動的なポートマッピングが可能。
awsvpcモード：タスクごとに専用のネットワークインターフェース（ENI）を割り当てる方式。よりセキュアで細かな制御が可能。
リプレイス前の私たちのバッチは、EC2上でbridgeモードを使って動いていました。ECS Managed Instancesが「FargateとEC2のいいとこ取り」を謳うなら、同じbridgeモードで動かせるのでは？ という期待もあって確認したのですが、ECS Managed Instancesがサポートするネットワークモードはawsvpcモードのみでした。bridgeモードには対応していません。
これは設計思想から考えると納得できます。ECS Managed Instancesは「FargateとEC2のいいとこ取り」を目指したサービスですが、Fargateはそもそもbridgeモードをサポートしていません。ネットワークモードはアーキテクチャの根幹に関わる部分であるため、今後もbridgeモードが追加される可能性は低いと判断しました。
最終判断：ECS on Fargateへのリプレイスを選んだ
調査結果をまとめてチームで共有し、ECS Managed Instancesの導入は見送り、当初の計画通りECS on Fargateへのリプレイスを進めるという結論を出しました。
決め手はコストの問題です。タスクにパブリックIPを付与できない＝プライベートサブネットで動かすしかない＝NAT GatewayかVPCエンドポイントが必要になる、というコスト増の連鎖が現実的ではありませんでした。
ECS on Fargateであれば、パブリックサブネット＋パブリックIPという構成をそのまま使えます。インスタンス管理から解放されつつ、コスト面でも現実的な運用が可能です。チームが当初求めていたものに、一番素直に答えてくれる選択肢でした。
その後、2026年2月にバッチのリプレイスが完了しました。ECS on Fargateへの移行で、OSメンテナンスやインスタンス管理から解放され、チームの運用負荷は大きく改善されています。
「新しいサービスを試せなかった」という少しの心残りはありますが、目的に対して最適な選択をすることが何より大切だと、改めて実感しました。
おわりに
今回の調査を通じて学んだのは、「新機能が出たからといって、それが常に最適解とは限らない」 ということです。
ECS Managed Instancesは、その後もスポットインスタンスのサポート追加など機能拡張が続いており、EC2の柔軟性（GPUインスタンスやリザーブドインスタンスの活用など）を活かしつつインフラ管理の手間を省きたいチームには非常に強力な選択肢だと思います。ただし、本記事で取り上げたタスクへのパブリックIP付与不可・bridgeモード非対応といった制約は、2026年6月現在も変わらず存在しています。 プライベートサブネットで運用するワークロードや、特定のEC2インスタンスタイプが必要なケースでは、ぜひ検討してみてください。
新しいサービスは積極的にキャッチアップしつつも、自分たちのユースケースにきちんと照らし合わせて判断する。この姿勢を大切にしていきたいと思います。
このブログが、ECS Managed Instancesの導入を検討している方や、バッチ処理のECS移行を考えているエンジニアの方の参考になれば幸いです！
