トップ > Amazon Elastic Container Service > Amazon ECSマネージドインスタンスとは？Fargate・EC2との違いと設定手順

Amazon ECSマネージドインスタンスとは？Fargate・EC2との違いと設定手順

Amazon Elastic Container Service Amazon ECS ECSマネージドインスタンス DevOps
記事タイトルとURLをコピーする

みなさんこんにちは。マネージドサービス課の塩野です。

Amazon ECSでコンテナを動かす方法っていくつか選択肢があり、2025年9月に新しい選択肢が登場して話題になっていたAmazon ECSのマネージドインスタンス。一般的には完全サーバーレスのFargateや、フルコントロールできるEC2起動タイプのイメージが強いと思いますが、どんな感じなのかちょっと気になっていて調べてみました。

マネージドインスタンスは、EC2の柔軟性を保ちながら、インフラ管理の面倒な部分をAWSに委任できる新しいコンピューティングオプションなんです。「GPUインスタンスが必要だけど、パッチ適用とか管理は面倒...」そんな悩みを解決してくれる機能といえます。

今回は、このマネージドインスタンスの基本から実際の設定方法、そして運用時に知っておくべきパッチ適用の仕組みまで、実践的に解説していきます。

マネージドインスタンスの基本を理解しよう

フルマネージド型EC2という新しいアプローチ

マネージドインスタンスは、簡単に言うと「AWSが面倒を見てくれるEC2インスタンス」です。従来のEC2起動タイプでは、インスタンスの選定からスケーリング、セキュリティパッチの適用まで、すべて自分で管理する必要がありました。一方でFargateは完全にサーバーレスですが、EC2の柔軟性は失われます。

マネージドインスタンスは、この2つの中間に位置する選択肢なんです。EC2インスタンスの全機能にアクセスできる柔軟性を持ちながら、プロビジョニング、スケーリング、パッチ適用といった運用タスクはAWSが自動で処理してくれます。

Fargate・EC2との違いを整理する

3つの起動方式の違いを表にまとめてみました。

項目 Fargate EC2 マネージドインスタンス
インフラ管理 AWSが全て管理 自分で管理 AWSが管理
インスタンスアクセス なし 完全アクセス なし（API経由のみ）
インスタンス選択 不要 自由に選択 自動選択 or 属性指定
GPU対応 不可 可能 可能
パッチ適用 AWS管理 自己責任 AWS管理（14日ごと）
運用負荷 最小 最大 低

ポイントは、マネージドインスタンスを使えば「GPUが必要な機械学習ワークロード」や「特定のCPUアーキテクチャが必要なアプリケーション」や「特殊な権限が必要なアプリケーション」でも、サーバー管理の手間なく動かせるということです。

マネージドインスタンスの主な特徴

マネージドインスタンスには、運用を楽にしてくれる機能がいくつも組み込まれています。

自動スケーリング

ワークロードの要件に応じて、EC2インスタンスを動的にスケールしてくれます。タスクが増えればインスタンスが追加され、減れば削除される仕組みです。アイドル状態のインスタンスや活用率の低いインスタンスを自動検出して削除することで、無駄なコストを削減してくれるんです。

インテリジェントなタスク配置

複数の小さなタスクを1つの大きなインスタンスに配置することで、コストを最適化します。例えば、512MBのタスク4つを、個別の小さなインスタンスではなく、1つの2GBインスタンスにまとめて配置するイメージです。

自動パッチ適用

セキュリティパッチは14日ごとに自動適用されます。これは後ほど詳しく説明しますが、運用上最も重要なポイントの1つです。

柔軟なインスタンス選択

デフォルトでは最もコスト効率の良いインスタンスが自動選択されますが、必要に応じてGPUインスタンスやネットワーク最適化インスタンスなど、特定の属性を持つインスタンスタイプを指定することもできます。

実際に設定してみよう

それでは、マネージドインスタンスを実際に設定する手順を見ていきましょう。

前提条件の準備

マネージドインスタンスを使い始める前に、IAMロールとネットワーク環境を準備する必要があります。

必要なIAMロール

マネージドインスタンスを使うには、3種類のIAMロールが必要です。

1つ目は「インフラストラクチャロール」で、AWSがマネージドインスタンスのライフサイクルを管理するために使用します。このロールには、EC2インスタンスの起動・終了、ネットワークインターフェースの管理などの権限が必要です。

2つ目は「インスタンスプロファイル」で、ECSコンテナエージェントとDockerデーモンに権限を付与します。重要なのは、このロール名には必ずecsInstanceRoleというプレフィックスを付ける必要があるということです。これがないと正常に動作しません。

3つ目は「タスク実行ロール」で、ECSがECRからコンテナイメージをプルしたり、CloudWatch Logsにログを送信するために使用します。

それぞれのロールの作り方を見ていきましょう。

インフラストラクチャロールの作成（AWSコンソール）

IAMコンソールを開いて「ロール」を選択し、「ロールを作成」をクリックします。

ステップ1: 信頼されたエンティティを選択

  • 「AWSのサービス」を選択
  • ユースケースで「Elastic Container Service」を選択
  • さらに「Infrastructure for ECS Managed Instances」を選択

  • 「次へ」をクリック

ステップ2: 許可を追加

  • 自動的にAmazonECSInfrastructureRolePolicyForManagedInstancesポリシーが選択されています

  • そのまま「次へ」をクリック

ステップ3: 名前、確認、および作成

  • ロール名: ecsInfrastructureRole
  • 説明: 任意（例: ECSマネージドインスタンス用のインフラストラクチャロール）

  • 「ロールを作成」をクリック

インスタンスプロファイルの作成（AWSコンソール）

再びIAMコンソールで「ロールを作成」をクリックします。

ステップ1: 信頼されたエンティティを選択

  • 「AWSのサービス」を選択
  • ユースケースで「EC2」を選択

  • 「次へ」をクリック

ステップ2: 許可を追加

  • 検索ボックスに「AmazonECSInstanceRolePolicyForManagedInstances」と入力
  • 該当するポリシーにチェックを入れる

  • 「次へ」をクリック

ステップ3: 名前、確認、および作成

  • ロール名: ecsInstanceRole（必ずこのプレフィックスで始まる名前にする）
  • 説明: 任意（例: ECSマネージドインスタンス用のインスタンスロール）

  • 「ロールを作成」をクリック

このロールを作成すると、同名のインスタンスプロファイルが自動的に作成され、ロールが関連付けられます。

タスク実行ロールの作成（AWSコンソール）

もう一度「ロールを作成」をクリックします。

ステップ1: 信頼されたエンティティを選択

  • 「AWSのサービス」を選択
  • ユースケースで「Elastic Container Service」を選択
  • さらに「Elastic Container Service Task」を選択

  • 「次へ」をクリック

ステップ2: 許可を追加

  • 自動的にAmazonECSTaskExecutionRolePolicyポリシーが選択されています

  • そのまま「次へ」をクリック

ステップ3: 名前、確認、および作成

  • ロール名: ecsTaskExecutionRole
  • 説明: 任意（例: ECSタスク実行用ロール）

  • 「ロールを作成」をクリック

これで3つのIAMロールの準備が完了しました。AWS CLIで作成したい場合は、後述の補足セクションを参照してください。

ネットワーク環境

VPCとサブネット、セキュリティグループを準備しておきましょう。マネージドインスタンスはインターネットアクセスが必要なので、パブリックサブネットを使うか、プライベートサブネットの場合はNATゲートウェイを設定してください。

クラスターの作成手順

それではECSクラスターを作成していきましょう。

ステップ1: クラスター設定

  • クラスター名: わかりやすい名前を入力します（例: my-managed-cluster）

ステップ2: インフラストラクチャ (- 高度)

  • コンピューティングキャパシティの取得方法を選択: ここが最重要ポイントです。「Fargate インスタンスとマネージドインスタンス」にチェックを入れます
  • インスタンスプロファイル: ドロップダウンからecsInstanceRoleを選択
    • このロール名は必ずecsInstanceRoleで始まる必要があります
  • インフラストラクチャロール: ドロップダウンからecsInfrastructureRoleを選択
    • AWSがマネージドインスタンスのリソースを管理するために使用されます
  • インスタンス選択: 要件に応じて下記のどちらかを選択
    • ECS のデフォルトを使用（推奨）: このラジオボタンを選択
      • AWSが自動的に最もコスト効率の良いインスタンスを選んでくれます
        基本的にはこれを選んでおけば問題ありません
    • カスタムを使用 - アドバンスト: GPU、特定のCPUアーキテクチャ、ネットワーク最適化インスタンスなどが必要な場合に使用
    • ネットワーク設定
      • VPC: ドロップダウンから使用するVPCを選択
      • サブネット: 「サブネットの選択」ドロップダウンをクリック
      • セキュリティグループ: 要件に応じて下記のどちらかを選択
        • 既存のセキュリティグループを使用: このラジオボタンを選択（推奨）
        • 新しいセキュリティグループの作成: 新規作成する場合に選択

すべての設定を確認し、問題がなければ画面下部の「作成」ボタンをクリックします。

タスク定義の作り方

マネージドインスタンスでタスクを動かすには、タスク定義に少し工夫が必要です。nginxを例に見ていきましょう。

タスク定義の基本構造

タスク定義はJSON形式で記述します。マネージドインスタンスでnginxを動かすためのシンプルなタスク定義の例を見てみましょう。

{
  "family": "nginx-managed-instances",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["MANAGED_INSTANCES"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "nginx",
      "image": "public.ecr.aws/nginx/nginx:latest",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/nginx-managed-instances",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "nginx",
          "awslogs-create-group": "true"
        }
      },
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost/ || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 60
      }
    }
  ]
}

重要なパラメータの解説

最も重要なポイントはrequiresCompatibilitiesの部分です。ここにMANAGED_INSTANCESを指定することで、このタスク定義がマネージドインスタンスで動作するようになります。

executionRoleArnには、先ほど作成したタスク実行ロールのARNを指定します。123456789012の部分は、実際のAWSアカウントIDに置き換えてください。

ネットワークモードはawsvpcを指定しています。これにより、各タスクに専用のENI（Elastic Network Interface）が割り当てられ、ネットワークの分離が強化されます。マネージドインスタンスを利用することでhostモードを使用することもできるようになりますが、基本的にはawsvpcをおすすめします。

cpuとmemoryはタスクに割り当てるリソースです。この例では512 CPU ユニット（0.5 vCPU）と1024 MB（1 GB）のメモリを指定しています。

ログ設定のポイント

logConfigurationセクションでCloudWatch Logsへのログ送信を設定しています。

awslogs-create-groupをtrueにしておくと、ロググループが存在しない場合に自動作成してくれるので便利です。リージョンは実際にデプロイするリージョンに合わせて変更してください。

ヘルスチェックの設定

healthCheckセクションでコンテナの健全性をチェックする設定を行っています。

この例では、30秒ごとにcurlコマンドでnginxのルートパスにアクセスし、正常に応答があるかチェックしています。起動直後の60秒間（startPeriod）はヘルスチェックの失敗を無視し、3回連続で失敗したらコンテナを異常と判定します。

タスク定義の登録

ECSコンソールを開き、左メニューから「タスク定義」を選択します。

「新しいタスク定義の作成」をクリックし、「JSON を使用した新しいタスク定義の作成」を選択します。

上記のJSONをコピーして貼り付け、executionRoleArnのアカウントIDとawslogs-regionを実際の値に変更します。

「作成」をクリックすれば、タスク定義の登録が完了します。

サービスの起動方法

タスク定義ができたら、サービスとして起動しましょう。

クラスターを選択して「サービス」タブに移動し、「作成」をクリックします。

ステップ1: サービスの詳細タスク定義ファミリー

  • タスク定義ファミリー: 先ほど作成したタスク定義ファミリーを選択します

  • サービス名: 任意のサービス名を入力します

ステップ2: 環境

  • コンピューティングオプション: 「キャパシティプロバイダー戦略」を選択します
    これにより、マネージドインスタンスのキャパシティプロバイダーが使用されます

  • キャパシティープロバイダー戦略: デフォルトのクラスターを使用を選択します

その他必要に応じて設定を行い、「作成」をクリックすると、マネージドインスタンス上でタスクが起動します。初回起動時はインスタンスのプロビジョニングに数分かかりますが、一度インスタンスが立ち上がれば、その後のタスク起動は高速になります。

マネージドインスタンスでの起動

マネージドインスタンスでクラスタを作成すると、クラスタ名の横に「マネージドインスタンス」と表示されます。基本的にはクラスタ単位で管理されるべきものですので、このタスクはマネージドインスタンスなんだっけ？というのが分からなくなったときはこれらの情報を参考に確認してみてください。

自動パッチ適用の仕組みを知る

マネージドインスタンスの大きな特徴の1つが、自動パッチ適用です。基本的な仕組みを理解しておきましょう。

14日間のライフサイクル

マネージドインスタンスには、セキュリティを維持するための独特なライフサイクルがあります。

インスタンスは起動してから最大14日間運用され、14日目になるとAWSが自動的にワークロードのドレイニング（排出）を開始します。既存のタスクを新しいインスタンスに移行させ、古いインスタンスは終了します。

この仕組みにより、セキュリティパッチが定期的に適用され、常に最新の状態を保てます。古いインスタンスが長期間稼働し続けることを防ぎ、既知の脆弱性を抱えたインスタンスが残らないようにしているんです。

メンテナンス時間の制御

「14日ごとにドレイニングが始まるのはわかったけど、営業時間中に起きたら困る...」という心配もありますよね。

そんな時は「イベントウィンドウ」という機能を使うことで、メンテナンス活動を実施する時間帯を指定できます。例えば、深夜や週末の時間帯を指定しておけば、ビジネスへの影響を最小限に抑えられます。

イベントウィンドウは、EC2コンソールまたはAWS CLIから設定可能です。詳細はAWS公式ドキュメントを参照してください。

運用上のポイント

重要なのは、アプリケーションが中断を許容できる設計になっているかどうかです。

14日間のライフサイクルがあるということは、少なくとも2週間に1回はタスクの置き換えが発生します。ECSサービスとして動かしていれば、タスクは自動的に新しいインスタンスに移行されますが、ステートフルなデータを扱う場合は外部のデータストア（RDSやDynamoDB、S3など）を使うようにしましょう。

また、14日以上継続して実行されるバッチ処理やワークロードには向いていません。

運用時の注意点とトラブルシューティング

マネージドインスタンスを使う上で、いくつか気をつけるべきポイントがあります。

アプリケーション設計で気をつけること

最も重要なのは、アプリケーションが中断を許容できる設計になっているかどうかです。

14日間のライフサイクルがあるということは、少なくとも2週間に1回はタスクの置き換えが発生するということです。ステートフルなデータを扱う場合は、外部のデータストア（RDSやDynamoDB、S3など）を使うようにしましょう。

また、14日以上継続して実行されるバッチ処理やワークロードには向いていません。そういった用途には、EC2起動タイプを検討してください。

セキュリティモデルの理解

マネージドインスタンスでは、デフォルトで1つのインスタンスに複数のタスクが配置されます。これは「マルチタスク配置」と呼ばれ、コスト最適化のための仕組みです。

ただし、Fargateのような完全な分離はありません。同じインスタンス上の他のタスクから影響を受ける可能性がゼロではないんです。

もし強い分離が必要な場合は、マネージドインスタンスのキャパシティプロバイダーを「シングルタスクモード」に設定できます。この場合、1インスタンスに1タスクのみが配置されるため、Fargateと同等の分離レベルが得られます。ただし、コスト効率は下がります。

まとめ

ECSマネージドインスタンスは、EC2の柔軟性とサーバーレスの運用のしやすさを組み合わせた、新しいコンピューティングオプションです。基本的にはEC2起動タイプのようなパッチあての運用から解放されるものの、セキュリティパッチ適用に伴うメンテナンスが許容できるような運用に適しています。また、14日以上継続して実行されるワークロードや、完全な分離が必要な高セキュリティ要件のアプリケーションには向いていないので、要件などを確認しながら用途に応じて選択することをオススメいたします。

この記事がどなたかのお役に立てれば幸いです。

◆　塩野　正人
◆　マネージドサービス部　所属
◆　X（Twitter）：@shioccii
◆　過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。