AWSコンテナサービスの選定ポイントをざっくりまとめてみた

ozawaです。涼しさを求めて近くの中華屋で冷麺を食べてきたのですが、家に帰ってくる頃には汗だくです。何のために汗をかいているのかよくわからなくなってきました。

世はコンテナ戦国時代（←）、AWSにも多様なコンテナサービスがあります。
最近コンテナサービスの選定ガイド的なものの作成に携わることがありまして、改めてAWSコンテナサービスの選定ポイントって何を押さえとけばええのかしらと気になったので、ざっくり調べた結果と、個人的に気にしているポイントについて整理してみましたのでその備忘です。

結論！→公式ドキュメントがあります。

こちらです。下記をかいつまみながらポイントについてまとめていこうと思います。

対象のAWSサービス

そもそも全体感としてどういうサービスがあるのかについては先述のガイドにも記載があります。

• Amazon EC2
• Amazon ECR
• Amazon ECS
• Amazon EKS
• Amazon Lightsail
• AWS App Runner
• AWS Batch
• AWS Fargate
• AWS Lambda
• AWS Outposts
• Red Hat OpenShift Service on AWS (ROSA)

注意点としては、AWS App Runner は 2026 年 4 月 30 日以降新規受付を停止し、メンテナンスモードに移行するため、今後の選択肢からは外しておいた方が良さそうです。既存ユーザーは引き続き利用・新規リソースの作成も可能ですが、AWSはECS Express Modeへの移行を推奨しています。

改めてサービス群を見てみると、いわゆるコンテナ系サービス以外にもLambda、EC2といったコンピューティングサービスとして提供しているけどコンテナもいけるよ！みたいなサービスもあるので、こちらについても考慮しておく必要があります。

また、AWS Outposts、ROSA といったオンプレミスなサービスも対象となります。

ここには載ってないですが、直近だと ECS Express Mode、EKS Auto Mode、AWS Lambda MicroVMs も選択肢としては考慮する必要があるかと思います。

AWSコンテナサービスにおける３つのレイヤー

コンテナサービスと一括りでみても、それぞれが担う役割は実態としては異なります。
ガイドでは下記の３つに分類されるそうです。

• Compute Capacity Layer
  • コンテナが実際に実行される場所
    • EC2
    • Fargate
    • Outposts
• Orchestration layer
  • 環境をスケジュールおよびスケーリングする、いわゆるコンテナオーケストレーションツール
    • ECS
    • EKS
    • ROSA
• Vertical solutions layer
  • アプリケーションのデプロイと管理のプロセスを簡素化する、高レベルかつバンドルされたサービスを提供する一連の垂直統合サービス、と呼ばれるもの
    • App Runner
    • Lightsail
    • AWS Batch
    • ECR

それぞれのレイヤーにおいて最適なものをピックアップして選定していく形になるかと思いますが、ガイドの注記にもある通り、実際にはサーバーレスないしKubernetesを優先すべきで、モダンアーキテクチャな構成が望ましいとされています。

注記
AWS には、コンテナをデプロイして実行するさまざまな方法が用意されています。最初の考慮事項の 1 つは、サーバーレス運用モデルまたは Kubernetes 運用モデルのいずれかを優先することです。実際には、ほとんどのお客様は両方をさまざまな程度で使用します。

運用モデルの選択については、「最新のアプリケーション戦略の選択に関する決定ガイド」で詳しく説明しています。この決定ガイドは、この質問をさらに詳しく調べたい方に役立つリソースです。さらに、「 Containers and Serverless Recommendation Guide」では、運用モデルを選択する際の選択肢について説明しています。

考慮すべき重要な基準

ガイドでは下記の観点で詳細な基準について記載されています。
「AWSとしてどのようなサービスが提供されているか」という話がメインでしたが、ここでは「コンテナサービスを利用する上で何を達成・解決すべきか」という利用者側の観点が記載されています。

• Managed service and operation overhead
  • 運用オーバーヘッド削減のためにマネージドサービスを利用する
• Workload characteristics
  • アーキテクチャ選択のために、ワークロードを理解する
• Application portability
  • オンプレークラウド間でも容易に実行可能とするために、アプリケーションの可搬性を担保する
• Organization size and skills
  • コンテナサービスを運用する上で、必要な組織スキルを整理する
• Ease of deployment
  • 各コンテナサービスにおける最適化のポイントを押さえる
    • AWS App Runner
      • インフラストラクチャを管理またはカスタマイズすることなく、アプリケーションをインターネットにデプロイするための最も簡単なパスを提供
    • Amazon ECS
      • スケールや機能を犠牲にすることなく、ネットワークとセキュリティの設定をより細かく制御する必要がある場合に適している
    • Amazon EKS
      • Kubernetes テクノロジーが提供するアプリケーションのデプロイとオーケストレーションを柔軟に制御

Choose/Use

その後のガイドの記載では、各サービスにおける仕様・制約ごとにどれを選択すべきかを先述の３つのレイヤーごとに整理されています。
かなり細かい情報になるので、ここからは個人的に気にしておきたいポイントにフォーカスして整理しようと思います。

気にしておきたいポイント

前提として、Outposts、ROSA についてはいろいろやりようがありすぎるので今回はあまりフォーカスしません。
今回はクラウドメインを主眼としておきます。

コンピューティング

コンテナを動かす上で、どのコンピューティングリソースを使うのかというのは性能面において非常に重要です。
例えばCPUアーキテクチャをユーザ側で選択したい場合、プラットフォームの選択肢としてはEC2、Managed Instanceになります。EC2でも構成可能ですが、昨今はManaged InstanceによりOSレイヤーの管理はマネージドに移譲しつつ、インスタンススペックについてはユーザ側でより柔軟に指定することが可能になったため、こちらの利用が今後は増えていきそうです。
ちなみに現状のAWS推奨はManaged Instanceだったりします。公式ドキュメントでも「ほとんどの新しいワークロードに推奨される選択肢」と明記されています。

逆にFargateの場合、ユーザ側はCPUアーキテクチャを指定できません。いわゆる「CPUガチャ」です。

• パフォーマンスを求めたい→EC2
• ユーザ側の責任分解点を最小にしたい→Fargate
• 両方をいいとこ取りしたい→Managed Instance

ストレージ

特にマネージドなプラットフォームにおいて、マウントオプションとして何がサポートされているかの選択肢は抑えておいた方が良いかと思います。

EBS、EFSについてはEC2、Fargate、Managed Instanceでサポートされていますが、S3 Files についてEC2はサポートされていません。
また、FSx については EC2 のみサポートされています。

• S3 Files を使いたい→ Fargate、Managed Instance
• FSx を使いたい→ EC2
• EBS、EFS→ どれでもいけるよ

なお、File Cache についてはEC2インスタンス・ECSコンテナインスタンス・EKSノードから利用可能ではありますが、EBS/EFS/S3 Files/FSxのようなECSのネイティブなボリューム統合（volumes定義での指定）ではなく、Lustreクライアントを別途セットアップしてマウントする形になる点は留意しておいた方が良さそうです。

公式の資料はこちら↓

is Kubernetes ?

コンテナサービスを使う上でよく議論にあがりがちなテーマですが、結論からいくと

• 既にKubernetesで動くサービスを使う→ EKS
• それ以外→ ECS、Lambda

が最初の判断指標になると思います。

その上で、Kubernetesを使う意義を本気で検討する場合は、マイクロサービスやモダンアーキテクチャといった括りで、アプリケーション構成について根本的に見直しをするといった取り組みが必要になるかと思います。

ECSとEKSの棲み分けについては以前書いたブログでまとめています。

まとめ

細かいところを掘り下げると考慮点はいくらでもありそうですが、「コンテナ使いたいけど何を選べば良いのかわからない」という方向けにひとまず押さえておくべきポイントを整理してみたので、参考になると幸いです。