# Amazon ECS マネージドインスタンスの設計
Amazon ECS マネージドインスタンスは、Amazon ECS の完全マネージド型のコンピューティングオプションであり、インフラストラクチャ管理を AWS で負荷軽減しながら、コンテナ化されたワークロードをすべての Amazon EC2 インスタンスタイプで実行できます。Amazon ECS マネージドインスタンスでは、AWS が基盤となるインフラストラクチャの割り当て、スケーリング、パッチ適用、メンテナンスを処理している間に、GPU アクセラレーション、特定の CPU アーキテクチャ、高ネットワークパフォーマンス、および特殊なインスタンスタイプなどの特定のコンピューティング機能にアクセスできます。
Amazon ECS マネージドインスタンスを使用する場合、アプリケーションをコンテナにパッケージ化し、コンピューティング要件を指定します。AWS は、ワークロードの要求を満たす最も低コストの汎用 Amazon EC2 インスタンスタイプを自動的に選択します。または、インスタンスタイプ、CPU メーカー、アクセラレーターなどの必要なインスタンス属性を指定できます。Amazon ECS マネージドインスタンスは、スケーリング、パッチ適用、コスト最適化など、インフラストラクチャのあらゆる側面を完全に管理します。AWS 機能や Amazon EC2 統合へのアクセスは完全に保証されます。
Amazon ECS マネージドインスタンスは、プラットフォーム固有の最適化とセキュリティ設定で Linux コンテナに対応しています。デフォルトでは、Amazon ECS マネージドインスタンスは、複数の小さなタスクを大きなインスタンスに配置することでインフラストラクチャの使用率を最適化し、結果として、コストを削減し、タスクの起動時間を改善します。
このトピックでは、Amazon ECS マネージドインスタンスのタスクおよびサービスのさまざまなコンポーネントについて述べ、Amazon ECS で Amazon ECS マネージドインスタンスを使用する際の特別な考慮事項について説明します。
## 開始方法
Amazon ECS マネージドインスタンスの使用を開始するには、必要な IAM ロールを作成し、AWS アカウントで Amazon ECS マネージドインスタンスを有効にします。その後、キャパシティプロバイダを作成することで、Amazon ECS マネージドインスタンスキャパシティプロバイダを使用してタスクまたはサービスを起動できます。
開始方法についての詳細な説明については、「スタートガイド」の次の項目を参照してください。
+ [Amazon ECS マネージドインスタンスのタスクの作成方法について説明します。](getting-started-managed-instances.md)
+ [AWS CLI を使用した Amazon ECS マネージドインスタンスのタスクの作成方法について説明します。](getting-started-managed-instances-cli.md)
## キャパシティープロバイダー
Amazon ECS マネージドインスタンスは、キャパシティプロバイダを使用してワークロードのコンピューティングキャパシティを管理します。デフォルトのキャパシティプロバイダを使用するか、特定のインスタンス要件を持つカスタムキャパシティプロバイダを作成できます。
次のキャパシティプロバイダが利用できます。
+ **デフォルトのキャパシティプロバイダ** – ワークロード要件に合わせて、最も低コストの汎用インスタンスタイプを自動的に選択します。
+ **カスタムキャパシティプロバイダ** – vCPU 数、メモリ、CPU メーカー、アクセラレータータイプ、特定のインスタンスタイプなど、属性ベースのインスタンスタイプ選択を使用してインスタンス属性を指定できます。
キャパシティプロバイダ戦略には、次のリストからキャパシティプロバイダタイプを 1 つだけ含めることができます。
+ Amazon ECS マネージドインスタンス
+ Auto Scaling グループ
+ Fargate/Fargate\$1SPOT
## インスタンスの選択と最適化
Amazon ECS は、次のいずれかの方法で、Amazon ECS マネージドインスタンスワークロードのインスタンスタイプを選択します。
+ **自動選択** – デフォルトのキャパシティプロバイダを使用する場合、Amazon ECS は、タスク定義で指定された CPU とメモリの要件を満たす、最も低コストの汎用インスタンスタイプを自動的に選択します。
+ **属性ベースの選択** – カスタムキャパシティプロバイダを使用する場合、vCPU 数、メモリサイズ、CPU メーカー、アクセラレータータイプ、特定のインスタンスタイプなどのインスタンス属性を指定できます。Amazon ECS は、指定した属性に一致するすべてのインスタンスタイプから選択します。
Amazon ECS マネージドインスタンスは、インフラストラクチャの使用率とコストを、いくつかのメカニズムを使用して最適化します。
+ マルチタスク配置 – デフォルトでは、Amazon ECS は複数の小さなタスクを大きなインスタンスに配置して、使用率を最大化することによってコストを削減します。
+ アクティブなワークロード統合 – Amazon ECS は、アプリケーションの可用性やデプロイのパフォーマンスに影響を与える可能性のある早期停止を回避しながら、コンテナインスタンスが完全にアイドル状態になるタイミングを特定します。システムは、サービスに設定されたタスクの最小数と最大数、スタートビフォーストップ動作、およびタスク保護動作を尊重します。
+ 適切なサイズ設定 – ワークロード要件が変更されると、Amazon ECS は現時点の要求に合った適切なサイズの代替インスタンスを起動します。
Amazon ECS は Amazon EC2 イベントウィンドウを使用して、都合の良い期間にメンテナンスアクティビティをスケジュールします。イベントウィンドウを使用すると、AWS がインスタンス上でメンテナンスを実施できる定期的な期間を定義できるため、メンテナンスを運用スケジュールに合わせて調整することで、ワークロードの中断を最小限に抑えることができます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスの予定されているイベント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html)」を参照してください。
厳重な分離が必要な場合は、Amazon ECS マネージドインスタンスを、VM レベルのセキュリティ分離境界を持つ個別のインスタンスで各タスクを実行するように設定することができます。
## タスク定義
Amazon ECS マネージドインスタンスを使用するタスクは、ほとんどの Amazon ECS タスク定義パラメータに対応しています。Amazon ECS マネージドインスタンスは、プラットフォームバージョン 1.4.0 を使用している既存の Fargate タスク定義と互換性があるため、移行が簡単になります。
Amazon ECS マネージドインスタンスを使用するには、`requiresCompatibilities` タスク定義パラメータに `MANAGED_INSTANCES` を含めます。タスク定義では、Fargate と Amazon ECS マネージドインスタンス双方の互換性を指定して、デプロイオプションに柔軟性を持たせることができます。
## オペレーティングシステムと CPU アーキテクチャ
以下のオペレーティングシステムがサポートされています。
+ Bottlerocket
Amazon ECS タスク定義には、ARM と X86\$164 の 2 つのアーキテクチャを使用できます。
Amazon ECS マネージドインスタンスで Linux コンテナを実行する場合、ARM ベースのアプリケーションに X86\$164 CPU アーキテクチャ、または ARM64 アーキテクチャを使用できます。
## 主な特徴
Amazon ECS マネージドインスタンスの主な特徴を以下に挙げます。
+ アプリケーションの要件に合わせて特定の EC2 インスタンスタイプを選択することで、GPU アクセラレーテッドコンピューティング、特定の CPU 機能、大きなメモリサイズなどの特殊なハードウェア機能にアクセスできます。
+ 独自の分離された環境で各タスクを実行する Fargate とは異なり、デフォルトで 1 つのインスタンスで複数のタスクを実行してリソースの使用率とコストを最適化します。
+ セキュリティコンプライアンスを確保し、インスタンスパッチ適用を定期的に実行します。ECS マネージドインスタンスは、14 日後にインスタンスドレイニングを開始し、サービスベースのタスクを新しいインスタンスに自動的に置き換えます。
+ CAP\$1NET\$1ADMIN、CAP\$1SYS\$1ADMIN、CAP\$1BPF などの特権 Linux 機能を使用して、コンテナ内での高度なネットワーキングとシステム管理機能を有効にします。
## IAM ロール
Amazon ECS マネージドインスタンスには 2 つの IAM ロールが必要です。
+ *インフラストラクチャロール*: このロールにより、AWS はユーザーに代わって Amazon ECS マネージドインスタンスを管理できます。
+ *インスタンスプロファイル*: インスタンスプロファイルは、IAM ロールを Amazon ECS マネージドインスタンスに渡すために使用します。このプロファイルは、次の目的で使用されます。
+ コンテナワークロードを実行する Amazon ECS マネージドインスタンスの IAM アクセス許可を定義します。
+ AWS がユーザーに代わってこれらのインスタンスを管理できるようにします。
+ プロファイルで定義されたアクセス許可に従って、インスタンスが AWS サービスにアクセスできるようにします。
## セキュリティとコンプライアンス
Amazon ECS マネージドインスタンスは、ワークロードを保護するために複数のセキュリティレイヤーを実装しています。
+ **安全な設定** – Amazon ECS マネージドインスタンスは、SSH アクセス禁止、変更不可能なルートファイルシステム、SELinux 経由のカーネルレベルの必須アクセスコントロールなど、AWS セキュリティのベストプラクティスに従います。
+ **自動パッチ適用** – AWS は、設定したメンテナンスウィンドウを尊重して、最新のセキュリティパッチで Amazon ECS マネージドインスタンスを定期的に更新します。
+ **インスタンス存続期間の制限** – ECS が 14 日後にインスタンスドレイニングを自動的に開始して、最新のセキュリティパッチが適用され、適切に構成されたインスタンスでアプリケーションが実行されることを確実にします。
+ **特権機能** – ネットワークモニタリングやオブザーバビリティソリューションなど、特権 Linux 機能を必要とするワークロードに対して、それらの機能をオプションで有効にできます。
Amazon ECS マネージドインスタンスは、PCI-DSS、HIPAA、FedRAMP など、Amazon ECS と同じコンプライアンスプログラムに対応しています。サポート対象のリージョンでは、Amazon ECS マネージドインスタンスはアカウントレベルの FIPS エンドポイント設定を尊重して、FedRAMP コンプライアンスを実現します。
## ネットワーク
Amazon ECS マネージドインスタンスは、`awsvpc` および `host` ネットワークモードに対応しています。`awsvpc` ネットワークモードは、VPC 内で独自の Elastic Network Interface とプライベート IP アドレスを各タスクに提供します。これにより、タスクレベルでのきめ細かなセキュリティグループとネットワーク ACL 制御が可能になります。`host` ネットワークモードでは、タスクはホストの Amazon ECS マネージドインスタンスネットワーク名前空間を共有します。Amazon ECS マネージドインスタンスでのタスクネットワーキングの詳細については、「[Amazon ECS マネージドインスタンスの Amazon ECS タスクネットワーキング](managed-instance-networking.md)」を参照してください。
## インスタンスストレージ
Amazon ECS マネージドインスタンスは、インスタンスに付加されている Amazon EBS データボリュームのサイズ設定に対応しています。このストレージは、インスタンスで実行されるすべてのタスク間で共有され、バインドマウントに使用できます。このボリュームは、タスク定義内で `volumes`、`mountPoint`、および `volumesFrom` パラメータを使用しているコンテナ間で共有およびマウントが可能です。
ボリュームはインスタンスの作成時に付加されます。`storageConfiguration` パラメータを使用して Amazon ECS マネージドインスタンスのキャパシティプロバイダを作成するときに、ボリュームのサイズを GiB 単位で指定できます。
```
{
...
"managedInstancesProvider": {
"infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
"instanceLaunchTemplate": {
"ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile",
"networkConfiguration": {
"subnets": [
"subnet-abcdef01234567",
"subnet-bcdefa98765432"
],
"securityGroups": [
"sg-0123456789abcdef"
]
},
"storageConfiguration": {
"storageSizeinGiB" : 100
}
}
}
...
}
```
このボリュームの最小サイズは 30 GiB、最大サイズは 16,384 GiB です。デフォルトでは、ボリュームのサイズは 80 GiB です。
タスクで、取り込み、圧縮、および非圧縮されたコンテナイメージは、このボリュームに格納されます。タスクがバインドマウントに使用すべきインスタンスストレージの総量を判断するには、タスクに割り当てられているインスタンスのストレージの総量から、コンテナイメージが使用するストレージの容量を差し引く必要があります。
Amazon ECS マネージドインスタンスに付加された Amazon EBS ボリュームのパフォーマンスは、「*Amazon EC2 ユーザーガイド*」の「[Amazon EBS 最適化インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)」ドキュメントで説明されているように、対応する Amazon EC2 インスタンスのパフォーマンスと一致します。
ボリュームのスナップショットを作成して、セキュリティ問題の法的分析を実行、もしくはアプリケーションのデバッグができます。Amazon EBS ボリュームのスナップショット作成の詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS スナップショット](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html)」を参照してください。Amazon EBS 暗号化がデフォルトで有効になっている場合、ボリュームはデフォルトで暗号化用に指定された AWS KMS キーで暗号化されます。デフォルトでの EBS 暗号化の詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS 暗号化をデフォルトで有効にする](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html)」を参照してください。
インスタンスに付加されたデータボリュームを使用するだけでなく、Amazon ECS マネージドインスタンス上で実行されるタスクごとにデータボリュームを設定することもできます。タスクレベルストレージの詳細については、「[Amazon ECS タスクのストレージオプション](using_data_volumes.md)」を参照してください。
## サービスの負荷分散
Amazon ECS マネージドインスタンスを使用する Amazon ECS サービスは、Elastic Load Balancing を使用してサービス内のタスク全体にトラフィックを均等に分散するよう設定できます。
Amazon ECS マネージドインスタンス上の Amazon ECS サービスは、Application Load Balancer、Network Load Balancer、および Gateway Load Balancer の各ロードバランサータイプに対応しています。Application Load Balancer は HTTP/HTTPS (レイヤー 7) のトラフィックをルーティングし、Network Load Balancer は TCP または UDP (レイヤー 4) のトラフィックをルーティングします。
また、このようなサービスのターゲットグループを作成する場合は、ターゲットタイプとして `instance` ではなく、`ip` を選択する必要があります。これは、`awsvpc` ネットワークモードを使用するタスクは、直接 Amazon EC2 インスタンスではなく、Elastic Network Interface に関連付けられているためです。
## モニタリングとオブザーバビリティ
Amazon ECS マネージドインスタンスは、CloudWatch メトリックおよびオブザーバビリティツールとの統合を通じて包括的なモニタリング機能を提供します。
+ **CloudWatch メトリック** – タスクレベルとインスタンスレベルの両方で CPU、メモリ、ネットワーク、およびストレージの使用率をモニタリングします。
+ **Container Insights** – コンテナ化されたアプリケーションの詳細なパフォーマンスメトリックとログを取得します。
+ **サードパーティーの統合** – 特権機能を有効にすると、高いレベルの Linux アクセス許可を必要とする高度なモニタリングおよびオブザーバビリティソリューションを実行できます。
## 料金とコストの最適化
Amazon ECS マネージドインスタンスでは、タスクを実行している Amazon EC2 インスタンス全体に対して課金されます。料金は、ワークロード用に選択されたインスタンスタイプによって異なります。
Amazon ECS マネージドインスタンスでは、いくつかのコスト最適化機能が提供されています。
+ **マルチタスクの最適化** – 適切なサイズに設定されたインスタンスで複数のタスクを実行することにより、インスタンスの使用率を最大化します。
Compute and Instance Savings Plans は、Amazon ECS マネージドインスタンスワークロードにも適用されます。
## サービスクォータ
Amazon ECS マネージドインスタンスワークロードには、Amazon EC2 オンデマンドインスタンス Service Quotas が適用されます。Amazon ECS マネージドインスタンスを使用する Amazon ECS サービスには、Amazon ECS Service Quotas が適用されます。
Service Quotas の詳細については、次の資料を参照してください。
+ 「*Amazon Web Services 全般のリファレンス*」の「[Amazon EC2 エンドポイントとクオータ](https://docs.aws.amazon.com/general/latest/gr/ec2-service.html)」
+ [Amazon ECS の Service Quotas](service-quotas.md)
## 移行に関する考慮事項
Amazon ECS マネージドインスタンスへの移行は、ほとんどのワークロードで簡単に行えます。
+ **Fargate から** – キャパシティプロバイダの設定変更と再デプロイのみが必要です。プラットフォームバージョン 1.4.0 を使用している既存のタスク定義には完全な互換性があります。
+ **EC2 から** – Fargate への移行と同様ですが、特定のインスタンスタイプなどの Amazon EC2 機能へのアクセスは保持されます。
移行を計画する際には、次の点を考慮してください。
+ アプリケーションは、14 日間のインスタンス存続期間と計画されたメンテナンスウィンドウに対応できる必要があります。
+ 長期間実行されるタスク (14 日以上) は、Amazon ECS マネージドインスタンスには適していません。
+ カスタム AMI はサポートされていません – Amazon ECS マネージドインスタンスは、AWS が管理するセキュリティ最適化 AMI を使用します。
## 制約事項と考慮事項
Amazon ECS マネージドインスタンスには、次の制限が適用されます。
+ カスタム AMI – AMI は AWS によって所有および管理されます
+ インスタンスの存続期間 – セキュリティパッチ適用とコンプライアンスを確実にするため、インスタンスあたりの最大ランタイムは 14 日です。
+ SSH アクセス – セキュリティ上の理由から使用できません。Amazon ECS Exec を使用してデバッグとトラブルシューティングを行います。管理オペレーションは Amazon ECS API 経由のみで可能です。
## 組織コントロール
組織コントロールには、Amazon ECS マネージドインスタンスの正しい動作を妨げる可能性があるものもあります。その場合は、これらのコントロールを更新して、Amazon ECS がユーザーに代わって EC2 インスタンスを管理するために必要な許可を得られるようにする必要があります。
Amazon ECS は、Amazon ECS マネージドインスタンスを支える EC2 インスタンスの起動にインフラストラクチャロールを使用します。このインフラストラクチャロールは、Amazon ECS がユーザーに代わって Amazon ECS マネージドインスタンスを管理できるようにする [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)であり、アカウント内に作成されます。サービスロールで実行されるアクションには、[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) が常に適用されます。このため、SCP は Amazon ECS マネージドインスタンスの運用を阻止できます。最も一般的なケースは、SCP を使用して起動できる Amazon マシンイメージ (AMI) を制限する場合です。Amazon ECS マネージドインスタンスを機能させるには、Amazon ECS マネージドインスタンス AMI アカウントからの AMI の起動を許可するように SCP を変更します。
[EC2 が許可された AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 機能を使用し、他のアカウントで AMI の可視性を制限することもできます。この機能を使用する場合は、イメージ基準の範囲を拡大して、対象リージョン内の Amazon ECS マネージドインスタンス AMI アカウントも範囲に含まれるようにする必要があります。
### Amazon ECS マネージドインスタンス AMI 以外のすべての AMI をブロックする SCP の例
以下の SCP は、AMI が us-west-2 または us-east-1 の Amazon ECS マネージドインスタンス AMI アカウントに属している場合を除き、`ec2:RunInstances` の呼び出しを阻止します。
**注記**
`ec2:Owner` コンテキストキーを使用**しない**ことが重要です。Amazon は Amazon ECS マネージドインスタンス AMI アカウントを所有しており、このキーの値は常に `amazon` になります。`ec2:Owner` が `amazon` の場合に AMI の起動を許可する SCP を構築すると、Amazon ECS マネージドインスタンス用の AMI だけでなく、Amazon が所有する任意の AMI も起動できます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"187296253231",
"260073348889"
]
}
}
}
]
}
```
### Amazon ECS マネージドインスタンス AMI アカウント
リージョンによって異なる AWS アカウントが Amazon ECS マネージドインスタンスのパブリック AMI をホストします。
| AWS リージョン | アカウント |
| --- | --- |
| af-south-1 | 070957084703 |
| ap-east-1 | 587573215167 |
| ap-northeast-1 | 679336465495 |
| ap-northeast-2 | 309903600357 |
| ap-northeast-3 | 384570461223 |
| ap-south-1 | 062344138989 |
| ap-south-2 | 624198668379 |
| ap-southeast-1 | 832199679391 |
| ap-southeast-2 | 552073033681 |
| ap-southeast-3 | 368903466070 |
| ap-southeast-4 | 696793786439 |
| ap-southeast-5 | 003457290689 |
| ap-southeast-6 | 465836752572 |
| ap-southeast-7 | 622515864387 |
| ca-central-1 | 853167153192 |
| ca-west-1 | 899469777611 |
| eu-central-1 | 832570432258 |
| eu-central-2 | 041659148495 |
| eu-north-1 | 851563870067 |
| eu-south-1 | 766433696616 |
| eu-south-2 | 003380494496 |
| eu-west-1 | 986619735082 |
| eu-west-2 | 591706807364 |
| eu-west-3 | 108582616801 |
| il-central-1 | 009537862704 |
| me-central-1 | 540883425316 |
| me-south-1 | 181438624895 |
| mx-central-1 | 210749644920 |
| sa-east-1 | 591338347621 |
| us–east–1 | 260073348889 |
| us-east-2 | 292185169523 |
| us-west-1 | 187296253231 |
| us-west-2 | 491085424538 |
# Amazon ECS マネージドインスタンスのインスタンスタイプ
Amazon ECS マネージドインスタンスでは、コンテナ化されたアプリケーションに特定の EC2 インスタンスタイプが選択可能です。
## Amazon ECS マネージドインスタンスのインスタンスファミリー
以下のインスタンスタイプがサポートされています。
### 汎用
+ m5、m5a、m5ad、m5d、m5dn、m5n、m5zn: バランスの取れたコンピューティング、メモリ、ネットワーキング
+ m6a、m6g、m6gd、m6i、m6id、m6idn、m6in: パフォーマンスが向上した最新世代
+ m7a、m7g、m7gd、m7i、m7i-flex: 次世代汎用インスタンス
+ m8g、m8gd: 最新世代の ARM 汎用インスタンス
+ t3、t3a、t4g: バーストパフォーマンスインスタンス (ナノインスタンスサイズとマイクロインスタンスサイズを除く)
### コンピューティング最適化
+ c5、c5a、c5ad、c5d、c5n: コンピューティング負荷の高いアプリケーション向けの高性能プロセッサ
+ c6a、c6g、c6gd、c6i、c6id、c6in: 最新世代のコンピューティング最適化インスタンス
+ c7a、c7g、c7gd、c7gn、c7i、c7i-flex: 次世代コンピューティング最適化インスタンス
+ c8g、c8gd、c8gn: 最新世代の ARM コンピューティング最適化インスタンス
+ hpc6a、hpc6id、hpc7a: ハイパフォーマンスコンピューティングインスタンス
### メモリを最適化
+ r5、r5a、r5ad、r5b、r5d、r5dn、r5n: メモリ対 vCPU 比率の高いメモリ集中型のアプリケーション
+ r6a、r6g、r6gd、r6i、r6id、r6idn、r6in: 最新世代のメモリ最適化インスタンス
+ r7a、r7g、r7gd、r7i、r7iz: 次世代メモリ最適化インスタンス
+ r8g、r8gd: 最新世代の ARM メモリ最適化インスタンス
+ u-3tb1、u7i-6tb、u7i-8tb、u7i-12tb、u7in-24tb、u7in-32tb: 最大 32 TB RAM の高メモリインスタンス
+ x2gd、x2idn、x2iedn、x2iezn: インメモリデータベースと分析用の極度に大きなメモリ
+ x8g: 最新世代の極度に大きなメモリインスタンス
+ z1d: 高クロック周波数および NVMe SSD ストレージ
### ストレージの最適化
+ d3、d3en: 分散ファイルシステム用の高密度 HDD ストレージ
+ i4g、i4i: 最新世代のストレージ最適化インスタンス
+ i7i、i7ie、i8g: 次世代の高性能ストレージインスタンス
+ im4gn、is4gen: ネットワーク最適化ストレージインスタンス
### 高速コンピューティング
+ g4dn: 機械学習の推論とグラフィックス用の NVIDIA T4 GPU
+ g5、g5g: 高性能グラフィックスと機械学習用の NVIDIA A10G GPU
+ g6、g6e、g6f: 最新世代の GPU インスタンス
+ gr6、gr6f: NVIDIA L4 Tensor Core GPU とグラフィックスワークロード用の 1:8 vCPU:RAM 比率を備えた GPU インスタンス
+ p3dn: 深層学習トレーニングと HPC 用の NVIDIA V100 GPU
+ p4d: 最高パフォーマンスの機械学習トレーニングのための NVIDIA A100 GPU
+ p5: NVIDIA H100 GPU を使用した最新世代
+ p6-b200: NVIDIA B200 GPU を搭載した次世代
## インスタンスの選択方法
Amazon ECS マネージドインスタンスには、インスタンスタイプを選択するための 2 つの方法があります。
+ *特定のインスタンスタイプの選択*: タスクに使用する EC2 インスタンスタイプを明示的に指定します。
+ *属性ベースのインスタンスタイプの選択*: アプリケーションに必要な属性 (vCPU、メモリ、アーキテクチャなど) を指定すると、Amazon ECS マネージドインスタンスが適切なインスタンスタイプを選択します。
## 特定のインスタンスタイプの選択
特定のインスタンスタイプを選択する場合、Amazon ECS マネージドインスタンスのタスクに使用する EC2 インスタンスタイプを明示的に指定します。これは、アプリケーションが特別なハードウェア特性を使用する特定のインスタンスタイプを必要とする場合に便利です。
## 属性ベースのインスタンスタイプの選択
属性ベースのインスタンスタイプを選択する場合、アプリケーションに必要な属性を指定すると、Amazon ECS マネージドインスタンスがそれらの要件を満たす適切なインスタンスタイプを選択します。これにより、柔軟性が向上し、特定のインスタンスタイプが使用できない場合にもタスクが正常に配置されるようになります。
複数の属性を指定すると、指定したすべての属性を満たすインスタンスタイプを取得します。属性に複数の値を指定すると、指定された値のいずれかを満たすインスタンスタイプを取得します。
属性ベースのインスタンスタイプの選択は、次の属性に対応しています。
**cpuArchitecture**
CPU アーキテクチャ。
有効な値: `X86_64` \$1 `ARM64`
**instanceGeneration**
現行世代のインスタンスタイプを含めるのか旧世代のインスタンスタイプを含めるのかを示します。
+ 現行世代のインスタンスタイプの場合は、`current` を指定します。現行世代には、現在使用が推奨されている EC2 インスタンスタイプが含まれます。これには、通常、各インスタンスファミリーの最新の 2～3 世代が含まれます。詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
+ 旧世代のインスタンスタイプの場合は、`previous` を指定します。
+ 現行世代と旧世代両方のインスタンスタイプを含めるには、`all` を指定します。
有効な値: `current` \$1 `previous` \$1 `all`
デフォルト: 任意の現行世代または旧世代。
**burstablePerformance**
バーストパフォーマンスインスタンスタイプを含めるのか、除外するのか、または必須なのかどうかを示します。詳細については、「Amazon EC2 ユーザーガイド」の「[バースト可能パフォーマンスインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)」を参照してください。
有効な値: `included` \$1 `excluded` \$1 `required`
デフォルト: `excluded`
**cpuManufacturer**
含める特定の CPU 製造元をリストします。
+ Intel CPU を使用するインスタンスタイプの場合は、`intel` を指定します。
+ AMD CPU を使用するインスタンスタイプの場合は、`amd` を指定します。
+ AWS CPU (AWS Graviton など) を使用するインスタンスタイプの場合は、`amazon-web-services` を指定します。
CPU ハードウェアの製造元と CPU ハードウェアアーキテクチャを混同しないでください。インスタンスは、ユーザー指定の Amazon マシンイメージ（AMI）に基づき、互換性のある CPU アーキテクチャを使用して起動されます。
有効な値: `intel` \$1 `amd` \$1 `amazon-web-services`
デフォルト: 任意の製造元。
**networkBandwidth**
ネットワーク帯域幅の最小値と最大値 (Gbps 単位)。
デフォルト: 最小値または最大値の制限なし。
**networkInterfaceCount**
ネットワークインターフェースの最小数と最大数。
デフォルト: 最小値または最大値の制限なし。
**localStorage**
インスタンスストアボリュームを持つインスタンスタイプを含めるのか、除外するのか、または必須なのかどうかを示します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)」を参照してください。
有効な値: `included` \$1 `excluded` \$1 `required`
デフォルト: `included`
**localStorageType**
必要なローカルストレージのタイプを示します。
+ ハードディスクドライブ (HDD) ストレージを使用するインスタンスタイプの場合は、`hdd` を指定します。
+ ソリッドステートドライブ (SSD) ストレージを使用するインスタンスタイプの場合は、`ssd` を指定します。
有効な値: `hdd` \$1 `ssd`
デフォルト: 任意のローカルストレージタイプ。
## 請求と購入のオプション
Amazon ECS マネージドインスタンスは、コンテナ化されたワークロードのコストを最適化するのに役立ついくつかの機能に対応しています。
+ *Savings Plans (SP)*: Amazon ECS マネージドインスタンスは、タスクが使用するインスタンスタイプ用に購入された Savings Plans からメリットを得られます。追加の設定は必要ありません。
+ *リザーブドインスタンス (RI)*: Amazon ECS マネージドインスタンスのタスクは、タスクで使用されるインスタンスタイプ用に購入した RI から恩恵を受けることができます。追加の設定は必要ありません。
+ *スポットインスタンス*: `capacityOptionType=Spot` を設定することで、EC2 スポットインスタンスを使用するように Amazon ECS マネージドインスタンスキャパシティプロバイダーを設定できます。
+ *キャパシティ予約*: `capacityOptionType=Reserved` を設定し、[キャパシティ予約グループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-cr-group.html)を指定することで、EC2 キャパシティ予約を使用するように Amazon ECS マネージドインスタンスキャパシティプロバイダーを設定できます。また、最大限の予測可能性を得るために `reservations-only` を使用してリザーブドキャパシティ限定でインスタンスが起動されるようにする、`reservations-first` を使用して予約を優先しながら必要に応じてオンデマンドキャパシティにフォールバックする柔軟性を維持する、または `reservations-excluded` を使用してキャパシティプロバイダーが予約を使用しないようにするという予約設定を指定することもできます。
# Amazon ECS マネージドインスタンスにおけるインスタンス選択のベストプラクティス
Amazon ECS マネージドインスタンスのワークロードに適したインスタンス設定を選択することは、パフォーマンス、コスト、リソース使用率を最適化するために不可欠です。Amazon ECS には、アプリケーション要件とコスト効率のバランスを取るための柔軟なインスタンス選択オプションが用意されています。次のベストプラクティスは、コンテナ化されたワークロードのインスタンス選択の際に、情報に基づいた意思決定を行うのに役立ちます。
1. Amazon ECS マネージドインスタンスのデフォルトのキャパシティプロバイダを使用する
Amazon ECS は、次に示すタスク定義とサービスパラメータ要件を満たす最も費用対効果の高いインスタンスを選択します。
タスク定義
+ operatingSystemFamily
+ cpuArchitecture
+ cpu
+ メモリ
サービスの定義
+ placementConstraints
+ placementStrategy
1. ほとんどのワークロードで属性ベースの選択を使用して柔軟性を提供し、配置の成功率を向上させる
属性ベースのインスタンス選択の場合、Amazon ECS は指定した要件を満たす幅広いインスタンスタイプから選択することができます。このアプローチにより、Amazon ECS が起動時に利用可能な最も費用対効果の高いインスタンスを選択できるようになるため、タスク配置が成功する可能性が高まり、コスト最適性が向上します。
1. アプリケーションに特定のハードウェア要件がある場合にのみ、特定のインスタンスタイプを使用する
GPU アクセラレーション、高クロック周波数プロセッサ、特殊なネットワーク機能など、特定のハードウェア機能を必要とするワークロード用に、特定のインスタンスタイプの選択を予約します。汎用アプリケーションの場合には、属性ベースの選択により、通常、柔軟性とコスト最適性が向上します。
1. 過剰な割り当てや不要なコストを避けるために、バランスの取れたリソースを選択する
アプリケーションの CPU およびメモリ要件に最も近いインスタンス設定を選択します。コストが高くなり、効率が低下するため、リソースの著しく過剰な割り当ては避けてください。モニタリングデータを使用して実際のリソース使用率のパターンを理解し、それに応じてインスタンスの選択を調整します。
1. ワークロードが異なるアプリケーションのインスタンスタイプを混在させて、パフォーマンスとコストのバランスをとる
さまざまなパフォーマンス要件やワークロードパターンを持つアプリケーションの場合は、インスタンス設定が異なる複数のキャパシティプロバイダを使用することを検討してください。このアプローチにより、必要に応じてパフォーマンスを維持しながら、アプリケーションのさまざまなコンポーネントに適切なインスタンスタイプを使用してコストを最適化できます。
1. `capacityOptionType=Reserved` が設定された Amazon ECS マネージドインスタンスキャパシティプロバイダーを使用するときは、ECS サービスが `minimumHealthyPercent=100%` と `maximumPercent=200%` のデフォルトデプロイ設定を使用することに注意してください。これは、ECS デプロイが古いタスクを停止する前に新しいタスクを開始しようと試み、定常状態キャパシティの最大 200% が一時的に必要になることを意味します。サービスが定常状態の EC2 キャパシティ予約にある使用可能なキャパシティのすべてを消費すると、デプロイプロセス中に新しいタスクを起動するための追加のキャパシティがなくなるため、デプロイが失敗します。この状況を回避するため、`minimumHealthyPercent` を 100% 未満 (75% など) に設定するとともに、`maximumPercent` を 100% に設定することを検討して、サービスがタスクを停止してから新しいタスクを開始するようにしてください。そうすることで、代替タスクの起動前にキャパシティが解放され、デプロイを正常に完了できるようになります。また、デプロイに対応し、トラフィックの急増に対処するための余裕を予約内に維持できるように、キャパシティ使用率を定期的に監視することも検討してください。
# Amazon ECS マネージドインスタンスのコンテナイメージの取り込み動作
コンテナーの起動にかかる時間は、基礎となるコンテナイメージによって異なります。たとえば、太いイメージ (Debian、Ubuntu、Amazon 2 のフルバージョン) は、それぞれのスリムバージョン (Debian-Slim、Ubuntu-Slim、Amazon-Slim) や小さいベースイメージ (Alpine) と比較して、コンテナ内で実行されるサービスの数が多いため、起動に時間がかかる場合があります。
Amazon ECS が Amazon ECS マネージドインスタンス上で実行されるタスクを開始するとき、Amazon ECS は、同じコンテナインスタンスで以前のタスクによりイメージが取り込まれていない、もしくは自動クリーンアッププロセスによってキャッシュされたイメージが削除された場合にのみ、イメージをリモートで取り込みます。それ以外の場合は、Amazon ECS マネージドインスタンスにキャッシュされたイメージが使用されます。これにより、不要なイメージのプルがなくなります。
# Amazon ECS マネージドインスタンスでのパッチ適用
Amazon ECS マネージドインスタンスでは、パッチ適用は重要なメンテナンスプロセスで、その中で AWS は制御された設定可能なプロセスを通じてワークロードの可用性を維持しながら、マネージドコンテナインスタンスのソフトウェアを自動的に管理および更新することで、セキュリティとコンプライアンスを確実にします。
## インスタンスのライフサイクル
デフォルトでは、Amazon ECS マネージドコンテナインスタンスは標準化された 14～21 日のライフサイクルで動作します。Amazon ECS は、インスタンスの起動から 14 日目に段階的なワークロードドレイニングを開始し、21 日目までに停止します。Amazon ECS は、特定の状況下での早期ドレイニングに対応します。
+ ソフトウェアのセキュリティ脆弱性の検出
+ ハードウェア状態の劣化
+ 顧客が設定したイベントウィンドウを優先するため
このアプローチは、顧客が定義したメンテナンス要件を尊重しながら、システムのコンプライアンスを維持します。
## イベントウィンドウとメンテナンススケジューリング
AWS は、ノードの作成タイムスタンプとメンテナンススケジュールをモニタリングする自動バックグラウンドプロセスを通じて、マネージドコンテナインスタンスのライフサイクルを管理します。インスタンスの起動時に、AWS はデフォルトの 14 日のドレイニングスケジュールを設定し、顧客が設定したイベントウィンドウを評価します。
イベントウィンドウを設定することで、Amazon ECS マネージドインスタンスのメンテナンスアクティビティをスケジュールできます。インスタンス ID またはインスタンスタグを使用して、1 つ以上の Amazon ECS マネージドインスタンスをイベントウィンドウに関連付けることができます。イベントウィンドウに特定の値がタグ付けされると、Amazon ECS はこれらのタグを該当するクラスターの該当する Amazon ECS マネージドインスタンスにマッピングし、最大限の努力で定義された期間中にインスタンスのメンテナンスをスケジュールします。
イベントウィンドウの詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスに影響のあるスケジュール済のイベントのカスタムイベントウィンドウを作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html)」を参照してください。
イベントウィンドウが存在する場合、AWS はこれらのウィンドウに合わせてドレイニングスケジュールを調整します。これにより、指定されたイベントウィンドウを優先するために、デフォルトの 14 日よりも早いドレイニングが発生する可能性があります。イベントウィンドウの変更は、新しく起動されたマネージドコンテナインスタンスにのみ影響するため、予知保全のスケジューリングが確保されます。
スケジュールされたドレイニング時間まで、Amazon ECS は顧客の設定に従ってマネージドコンテナインスタンス上で通常のタスク配置動作を続行します。
## メンテナンスシーケンス
指定されたメンテナンス時に、Amazon ECS は `UpdateContainerInstancesState` API を呼び出してメンテナンスシーケンスを開始し、段階的なワークロードのドレイニングを起動します。段階的な停止期間中、Amazon ECS はドレイニング対象として印付けされたインスタンスのワークロードを停止しようとします。
Amazon ECS は、サービスタスクにスタートビフォーストップ戦略を採用しているため (または Amazon ECS サービス設定に従って)、既存タスクの停止前に置き換えタスクの起動が確実に行われ、サービスの中断が最小限に抑えられます。このプロセス全体を通して、Amazon ECS サービスは、インスタンスの起動から 21 日目までドレイニング試行を継続しながら、すべてのサービスデプロイ設定を優先します。
ドレイニングが 21 日目までに完了していない場合、Amazon ECS は `DeregisterContainerInstance` API を実行してマネージドコンテナインスタンスとその残りのワークロードを停止することにより、コンプライアンスを維持し、マネージドインスタンスに最新のソフトウェアをパッチ適用します。
# Amazon ECS マネージドインスタンスのセキュリティ上の考慮事項
Amazon ECS マネージドインスタンスは、完全マネージド型のコンテナコンピューティング体験を提供します。これにより、セキュリティ上の責任を AWS で負荷軽減しながら、特定の Amazon EC2 インスタンスタイプでワークロードを実行できます。このトピックでは、Amazon ECS マネージドインスタンスを使用する際のセキュリティモデル、機能、考慮事項について説明します。
## セキュリティモデル
Amazon ECS マネージドインスタンスは、柔軟性と保護のバランスをとる包括的なセキュリティモデルを実装しています。
+ **AWS マネージドインフラストラクチャ** – AWS はマネージドインスタンスのライフサイクルを制御し、セキュリティパッチ適用を処理することで、人為的ミスや改ざんの可能性を排除します。
+ **管理アクセスの禁止** – セキュリティモデルは隔離されて、マネージドインスタンスへの管理アクセスが禁止されます。
+ **マルチタスク配置** – デフォルトでは、Amazon ECS マネージドインスタンスはコストと使用率を最適化するために 1 つのインスタンスに複数のタスクを配置するため、Fargate と比較してワークロード分離の制約が緩和されます。
+ **データ分離** – AWS はインスタンスのライフサイクルとタスクの配置を制御しますが、AWS はマネージドインスタンスにログインしたり、顧客データにアクセスしたりすることはできません。
## セキュリティ機能
Amazon ECS マネージドインスタンスには、ワークロードを保護し、強力なセキュリティ体制を維持するように設計されたいくつかの組み込みセキュリティ機能が含まれています。これらの機能は、自動セキュリティパッチ適用から、必要に応じた特権 Linux 機能への対応まで多岐にわたります。
### セキュリティのベストプラクティス
マネージドインスタンスは、AWS セキュリティのベストプラクティスに従って設定され、それには次の項目を含みます。
+ **SSH アクセス禁止** – 不正アクセスを防ぐために、リモートシェルアクセスは無効化されています。
+ **変更不可能なルートファイルシステム** – ルートファイルシステムは変更できず、システムの整合性が確保されます。
+ **カーネルレベルの必須アクセスコントロール** – SELinux は、カーネルレベルで追加のセキュリティ施行を提供します。
### 自動セキュリティパッチ適用
Amazon ECS マネージドインスタンスは、自動パッチ適用を通じてワークロードのセキュリティ体制の改善を支援します。
+ **定期的なセキュリティ更新** – インスタンスは、AWS によって、設定したメンテナンスウィンドウに従い、最新のセキュリティパッチを用いて定期的に更新されます。
+ **インスタンスの有効期間の制限** – 実行中のインスタンスの最大存続期間は 14 日間に制限され、最新のセキュリティパッチで適切に設定されたインスタンスでアプリケーションが実行されることを確実にします。
+ **メンテナンスウィンドウの制御** – Amazon EC2 イベントウィンドウ機能を使用して、Amazon ECS がインスタンスをパッチ適用済みのインスタンスにいつ置き換えるかを指定できます。
### 特権 Linux 機能
Amazon ECS マネージドインスタンスは、高いレベルの Linux 権限を必要とするソフトウェアに対応することで、高度なモニタリングとセキュリティソリューションを可能にします。
+ **サポート対象の機能** – `CAP_NET_ADMIN`、`CAP_SYS_ADMIN`、`CAP_BPF` など、すべての特権 Linux 機能に対して使用承諾できます。
+ **一般的に普及しているソリューション** – これにより、Wireshark や Datadog などの一般的に普及しているネットワークモニタリングおよびオブザーバビリティソリューションを実行できます。
+ **明示的な設定が必要** – アプリケーションに追加のセキュリティリスクが生じる可能性があるため、特権 Linux 機能を有効にするように Amazon ECS マネージドインスタンスのキャパシティプロバイダを明示的に設定する必要があります。
**重要**
特権 Linux 機能を有効にすると、タスクが追加のセキュリティリスクにさらされる可能性があります。これらの機能は、アプリケーションが必要とする場合にのみ有効にし、セキュリティへの影響に対する理解を確実にしてください。
## コンプライアンスと規制への対応
Amazon ECS マネージドインスタンスは、Amazon ECS と同じコンプライアンス体制を維持します。
+ **コンプライアンスプログラム** – Amazon ECS マネージドインスタンスは、PCI-DSS、HIPAA、FedRAMP など、Amazon ECS と同じ AWS 保証プログラムの対象です。
+ **FIPS エンドポイント** – Amazon ECS マネージドインスタンスは、AWS リージョンで FIPS エンドポイントを使用して FedRAMP コンプライアンスを実現するためのアカウントレベル設定を尊重します。
+ **カスタマーマネージドキー** – 暗号化用のカスタマーマネージドキーなど、コンプライアンスの達成に必要なセキュリティ機能に対応します。
## Amazon ECS マネージドインスタンスにおける FIPS-140 関連の考慮事項
Amazon ECS マネージドインスタンスで FIPS-140 コンプライアンスを使用する場合は、次の点を考慮してください。
+ FIPS-140 準拠のマネージドインスタンス AMI を利用できるのは AWS GovCloud (US) リージョンのみです。
+ Amazon ECS マネージドインスタンスは FIPS-140-3 をサポートします。
+ AWS GovCloud (US) リージョンでは、FIPS-140 コンプライアンスがデフォルトで有効になっています。FIPS コンプライアンスなしでワークロードを実行する必要がある場合は、マネージドインスタンスキャパシティプロバイダーの設定で FIPS コンプライアンスを無効にします。
+ FIPS-140 コンプライアンスのため、タスクの `cpuArchitecture` は `X86_64` にする必要があります。
## Amazon ECS マネージドインスタンスで FIPS を無効にする
デフォルトで、AWS GovCloud (US) リージョン内の Amazon ECS マネージドインスタンスキャパシティプロバイダーは FIPS 準拠の AMI を起動します。FIPS-140 コンプライアンスの無効化は、新しい Amazon ECS マネージドインスタンスキャパシティプロバイダーを作成するときに選択します。FIPS コンプライアンスなしで新しいキャパシティプロバイダーを作成するには、次の手順を実行します。
1. キャパシティプロバイダーの FIPS-140 コンプライアンスを無効にします。
```
aws ecs create-capacity-provider \
--cluster cluster-name \
--name capacity-provider-name \
--managed-instances-provider '{
"infrastructureRoleArn": "infrastructure-role-arn",
"instanceLaunchTemplate": {
"ec2InstanceProfileArn": "instance-profile-arn",
"fipsEnabled": false,
"networkConfiguration": {
"subnets": ["subnet-id"],
"securityGroups": ["security-group-id"]
}
}
}'
```
1. オプションで、ECS Exec を使用して次のコマンドを実行し、キャパシティプロバイダーの FIPS-140 コンプライアンスステータスを検証できます。
*cluster-name* をクラスターの名前に、*task-id* をタスクの ID または ARN に、*container-name* をコマンドを実行するタスク内のコンテナ名に置き換えます。
戻り値「1」は、FIPS が使用されていることを示します。
```
aws ecs execute-command \
--cluster cluster-name \
--task task-id \
--container container-name \
--interactive \
--command "cat /proc/sys/crypto/fips_enabled"
```
## セキュリティに関する考慮事項
Amazon ECS マネージドインスタンスを使用する場合は、いくつかの重要なセキュリティ上の考慮事項を理解して計画する必要があります。これらの考慮事項は、ワークロードアーキテクチャとセキュリティ要件について情報に基づいた意思決定を行うのに役立ちます。
### マルチタスクセキュリティモデル
Amazon ECS マネージドインスタンスでのデフォルトのマルチタスク配置モデルは、Fargate の単一タスク分離とは異なります。
+ **共有インスタンスリソース** – 複数のタスクが同じインスタンス上で実行され、同じインスタンスまたは同じ ECS クラスターで実行されている他のタスクの脆弱性にタスクが晒される可能性があります。
+ **シングルタスクオプション** – VM レベルのセキュリティ分離境界を持つデフォルトの Fargate セキュリティモデルを必要とする顧客のために、シングルタスクモードを使用するように Amazon ECS マネージドインスタンスを設定することができます。
+ **コストとセキュリティのトレードオフ** – マルチタスクモードはコストの最適化とタスクスタートアップ時間の短縮化を実現し、一方で、シングルタスクモードはより強力な分離を提供します。
### インスタンスの中断処理
Amazon ECS マネージドインスタンスを使用する際は、中断を許容するようにアプリケーションを設計することが重要です。
+ **中断耐性** – 基盤となるサービスまたはタスクの中断を許容するアプリケーションで Amazon ECS マネージドインスタンスを使用します。
+ **サービスベースのワークロード** – タスクの自動置き換えに Amazon ECS サービスを使用するか、独立型タスクで 14 日以内の制御および制限された期間でワークロードを実行します。
+ **段階的なシャットダウン** – タスクシャットダウンの猶予期間を設定して、中断の影響を制御します。
### データアクセスとプライバシー
Amazon ECS マネージドインスタンスは、厳格なデータアクセスコントロールを維持します。
+ **顧客データアクセス禁止** – AWS はマネージドインスタンスのライフサイクルとインスタンス上のタスクの配置を制御しますが、AWS はマネージドインスタンスにログインしたり、顧客データにアクセスしたりすることはできません。
+ **メトリックとログに限定** – AWS は、Amazon ECS マネージドインスタンス機能の提供に必要なメトリックと関連ログのみをキャプチャします。
+ **隔離されたセキュリティモデル** – セキュリティモデルでは管理アクセスを禁止することで、人為的ミスや改ざんの可能性を排除します。
## セキュリティのベストプラクティス
Amazon ECS マネージドインスタンスを使用する場合は、次に挙げるベストプラクティスに従います。
+ **セキュリティモデルを評価する** – セキュリティ要件、特にマルチタスク配置モデルに基づいて、Amazon ECS マネージドインスタンスの採用を意識的に決定します。
+ **必要に応じてシングルタスクモードを使用する** – ワークロードでより強力な分離が必要な場合は、Amazon ECS マネージドインスタンスがシングルタスクモードを使用するように設定します。
+ **特権機能を最小限に抑える** – 絶対に必要な場合にのみ特権的 Linux 機能を有効にし、関連するセキュリティリスクを理解します。
+ **中断を計画する** – 特に 14 日間のインスタンス最大存続期間を考慮して、インスタンスの置き換えを段階的に処理するようにアプリケーションを設計します。
+ **メンテナンスウィンドウを設定する** – EC2 イベントウィンドウを使用して、インスタンスの置き換えが発生するタイミングを制御することで、ワークロードへの影響を最小限に抑えます。
+ **モニタリングと監査** – Amazon ECS マネージドインスタンスの設定を定期的に確認し、セキュリティ関連のイベントや変更がないかモニタリングします。
# Amazon ECS マネージドインスタンスの VPC 暗号化コントロールの有効化
Amazon ECS マネージドインスタンスは、VPC 暗号化コントロールをサポートしています。これは、セキュリティとコンプライアンスの機能であり、リージョン内にある VPC 内 および VPC 間における転送時の暗号化を監視して適用するための一元化されたコントロールを提供します。サブネットで VPC 暗号化コントロールが有効化されていると、Amazon ECS マネージドインスタンスのカスタムキャパシティプロバイダーで転送時の暗号化をサポートするインスタンスタイプを指定できるため、Amazon ECS マネージドインスタンスのワークロードが転送時の暗号化を使用して実行されることが保証されます。
## 前提条件
開始するには、以下が必要です。
+ サブネットで転送時の暗号化が有効化されている VPC。詳細については、[VPC 暗号化コントロールに関するドキュメント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html)を参照してください。
+ Amazon ECS マネージドインスタンスのカスタムキャパシティプロバイダー。詳細については、「[Amazon ECS マネージドインスタンスの設計](ManagedInstances.md)」を参照してください。
## 互換性のあるインスタンスタイプを特定する
Amazon EC2 インスタンスタイプは、次の 2 つの要件を満たす必要があります。
1. **転送時の VPC 暗号化をサポートする** - 次の AWS CLI コマンドを使用して、転送時の暗号化をサポートする Amazon EC2 インスタンスタイプを一覧表示します。
```
aws ec2 describe-instance-types \
--filters Name=network-info.encryption-in-transit-supported,Values=true \
--query "InstanceTypes[*].[InstanceType]" \
--output text | sort
```
1. **Amazon ECS マネージドインスタンスでサポートされる** - Amazon ECS マネージドインスタンスでサポートされるすべての Amazon EC2 インスタンスタイプは、「[Amazon ECS マネージドインスタンスのインスタンスタイプ](managed-instances-instance-types.md)」に記載されています。
追加の要件 (特定の CPU、メモリ、アーキテクチャ上のニーズなど) がある場合は、互換性のあるインスタンスタイプをワークロードの要件に基づいてさらにフィルタリングします。
## VPC 暗号化をサポートするクラスターを作成する
転送時の VPC 暗号化向けに Amazon ECS マネージドインスタンスを設定する:
1. 新しいクラスターを作成して、インフラストラクチャに **[Fargate インスタンスとマネージドインスタンス]** を選択します。
1. **[カスタムを使用 – アドバンスト]** を選択し、追加の設定パラメータにアクセスします。
1. **[許可されるインスタンスタイプ]** には、転送時の VPC 暗号化をサポートする特定のインスタンスタイプのみを追加します。
Amazon ECS マネージドインスタンスをこのように設定すると、転送時の VPC 暗号化をサポートする Amazon EC2 インスタンスタイプのみを起動するようになります。
## 考慮事項
+ **バーストパフォーマンスインスタンス** - T3、T3a、および T4g インスタンスタイプは、転送時の VPC 暗号化をサポートしておらず、強制モードで暗号化制御が有効化されているサブネットで使用することはできません。
+ **モードの移行** - 実行中のすべてのインスタンスが転送時の VPC 暗号化をサポートしている場合に限り、VPC サブネットをモニタリングモードから強制モードに移行できます。
+ **タスクの起動失敗** - 強制モードでは、転送時の暗号化をサポートしないインスタンスタイプを指定した場合にタスクの起動が失敗します。
## トラブルシューティング
強制モードでタスクの起動が失敗する
タスクの起動が失敗する場合は、上述の AWS CLI コマンドを使用して、指定されたすべてのインスタンスタイプが転送時の VPC 暗号化をサポートしていることを確認します。
強制モードに移行できない
コンソールまたは `GetVpcResourcesBlockingEncryptionEnforcement` コマンドを使用して、転送時の暗号化を強制していないリソースを特定します。
VPC 暗号化コントロールの詳細については、[VPC 暗号化コントロールに関するドキュメント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html)を参照してください。
# Amazon ECS マネージドインスタンスのインフラストラクチャの最適化
Amazon ECS マネージドインスタンスは、キャパシティプロバイダの設定と現在のワークロード需要に基づいて、適切なサイズの EC2 インスタンスを自動的に割り当てることで、コンテナ化されたアプリケーションが展開された瞬間から適切なコンピューティングリソースを確保します。アプリケーションのトラフィックパターンが進化し、ワークロード要件が時間の経過とともに変化するにつれて、Amazon ECS マネージドインスタンスは、現在のニーズに合わせてインスタンスサイズを自律的に調整し、最適な設定から逸脱したインスタンスを積極的に置き換え、コスト効率、アプリケーションパフォーマンス、システムの信頼性を動的に調整することで、インフラストラクチャを継続的にモニタリングおよび最適化します。このリソース管理システムは手動の介入なしで動作するため、アプリケーションの高可用性を維持しながらインフラストラクチャコストを削減できます。
インフラストラクチャの最適化には次の利点があります。
+ コスト最適化 – リソース使用率を最大化し、余剰能力を排除することで、インフラストラクチャコストを削減します
+ パフォーマンスの改善 – リソース要件とパフォーマンス特性に基づいてワークロード配置を最適化します
+ 運用の簡素化 – 手動の介入を必要とせずに、複雑なリソース管理の決定を自動化します
+ 信頼性の向上 – 自律的なワークロード分散と動作状態のモニタリングを通じて高可用性を維持します
Amazon ECS マネージドインスタンスは、効率を最大化しコストを削減するために、2 種類のインフラストラクチャ最適化を実行します。
## 非稼働インスタンスの検出
実行中のタスクがない EC2 インスタンスを特定して削除することで、未使用の能力から不要なインフラストラクチャコストを排除します。非稼働状態のインスタンスが検出されると、最適化プロセスはコンテナインスタンスを DEREGISTERING として印を付け、基盤となる EC2 インスタンスを安全に終了するクリーンアップシーケンスを開始します。
## 使用率の低いインスタンス検出
インスタンス間にわたるタスク分散を分析し、リソース割り当ての改善機会を特定します。タスクが複数のインスタンス間で最適に実行されていない場合、Amazon ECS マネージドインスタンスはワークロードをより少なく、より効率的に使用されているインスタンスに統合し、パフォーマンスを維持しながら全体的なコストを削減します。最適化プロセスでは、使用率の低いコンテナインスタンスを DRAINING として印を付けます。これにより、タスクの置き換えが開始され、ワークロードが既存または新しい、より効率的なインスタンスに移行されます。すべてのタスクが安全に移行されると、インスタンスは DEREGISTERING 状態に移行し、クリーンアップされます。この最適化は、サービスタスクを実行しているインスタンスに適用され、サービスの最小タスク制限と最大タスク制限を尊重し、スタートビフォーストップのデプロイ動作を優先し、ドレイニングプロセス全体を通してタスク保護設定を維持することで、安全な統合を実現します。ECS マネージドインスタンスは独立型タスクを置き換えないため、独立型タスクを実行しているインスタンスは最適化対象とはみなされません。
これらの最適化は連携して、アプリケーションの可用性に影響を与えることなく、自動的に無駄を排除し、リソース使用率を改善することで、インフラストラクチャが実際のワークロードの需要に継続的に適応することを確実にします。どちらのメカニズムも、タスクとインスタンスのライフサイクルイベントに応答するイベント駆動型モニタリングを使用して、最適化の機会をリアルタイムで特定します。Amazon ECS マネージドインスタンスは、コンテナインスタンス上で最後のタスクが停止したときに検出し、コスト最適化のため、非稼働状態になる見込みを提示します。使用率の低いインスタンスの場合、タスクの停止または新しいインスタンスの起動によって分析が開始され、ワークロード統合とリソース効率改善の機会を特定します。
## ScaleInAfter
どちらのインフラストラクチャの最適化も、実行中のインスタンスを終了して使用率を向上し、コストを削減する機会を探します。Amazon ECS マネージドインスタンスのキャパシティプロバイダ設定の ScaleInAfter 設定を使用して、これらのアクションのタイミングを制御できます。これは、非稼働状態のインスタンスと使用率の低いインスタンスの両方に適用されます。ScaleInAfter では、インスタンスが非稼働状態または使用率の低い状態になるときから、Amazon ECS マネージドインスタンスがインフラストラクチャの最適化を開始するときまでの遅延を秒単位で指定できます。遅延は 0～3600 秒の間で設定できます。-1 を指定してインフラストラクチャの最適化を無効にすることもできます。
**非稼働状態のインスタンス**
+ ECS は、最後のタスクが停止した後、インスタンスの登録を解除する前に、指定された期間待機します。
+ 待機期間中に新しいタスクが開始された場合、インスタンスは非稼働状態とみなされなくなり、停止はキャンセルされます。
**使用率の低いインスタンス**
+ ECS は、インスタンスが十分に活用されない結果となるタスク停止イベントの後、インスタンスをドレイニングする前に、指定された期間待機します。
+ 待機期間中に新しいタスクが起動、または既存のタスクが特定のインスタンスで停止された場合、タイマーは最新のタスク停止時間または新しいタスク作成時間からリセットされ、Amazon ECS マネージドインスタンスは非効率について再評価し、新しい待機期間が終了した後に必要に応じてアクションを実行します。
この設定はオプションです。指定しない場合、ECS マネージドインスタンスは ECS マネージドインスタンスのデフォルト設定に基づいて最適なタイミングを自動的に決定します。
# AWS Fargate から Amazon ECS マネージドインスタンスへの移行
既存のワークロードを Fargate から Amazon ECS マネージドインスタンスに移行できます。この移行により、AWS マネージドインフラストラクチャを維持しながら、Amazon EC2 インスタンスタイプ、キャパシティ予約、および高度な機能のすべてにアクセスできます。
## 移行に関する考慮事項
Fargate から Amazon ECS マネージドインスタンスに移行するときは、次の考慮事項に注意してください。
タスク互換性
Fargate 用に設定された既存のタスク定義は、ほとんどが Amazon ECS マネージドインスタンスと互換性があります。タスク定義の違いについては、「[Amazon ECS マネージドインスタンスの Amazon ECS タスク定義の違い](managed-instances-tasks-services.md)」を参照してください。
セキュリティモデルの変更
Amazon ECS マネージドインスタンスでは、デフォルトでインスタンスごとに複数のタスクが許可されます。ワークロードで、より強力な分離が必要な場合は、シングルタスクモードを有効にすることを検討してください。
インスタンスのライフサイクル
Amazon ECS マネージドインスタンスの最大存続期間は 14 日間です。タスクの置き換えを計画し、Amazon ECS サービスを使用して自動タスク管理を行います。
料金の変更
Amazon ECS マネージドインスタンスでは、Fargate のようにタスクごとのリソースではなく、インスタンス全体の料金および管理費が発生します。
メンテナンスウィンドウ
Amazon EC2 イベントウィンドウを使用してメンテナンスウィンドウを設定し、Amazon ECS マネージドインスタンスをパッチ適用のために置き換えるタイミングを制御します。
## 前提条件
Amazon ECS マネージドインスタンスに移行する前に、次の条件を確認してください。
+ プラットフォームバージョン 1.4.0 以降を使用した既存の Fargate タスク
+ Amazon ECS マネージドインスタンスに必要な IAM ロールがあること。これには、以下が含まれます。
+ **インフラストラクチャロール** – Amazon ECS がユーザーに代わって AWS サービスを呼び出し、Amazon ECS マネージドインスタンスインフラストラクチャを管理できるようにします。
詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。
+ **インスタンスプロファイル** – マネージドインスタンスで実行されている Amazon ECS コンテナエージェントと Docker デーモンへのアクセス許可を提供します。
詳細については、「[Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md)」を参照してください。
+ Fargate と Amazon ECS マネージドインスタンスのセキュリティモデルの違いを理解していること
**重要**
Amazon ECS マネージドインスタンスは、Fargate とは異なるセキュリティモデルを使用しています。デフォルトでは、複数のタスクを同じインスタンスで実行できます。これにより、タスクが他のタスクの脆弱性にさらされる可能性があります。移行前にセキュリティ要件を確認してください。
## ステップ 1: Amazon ECS マネージドインスタンスを使用するようにクラスターを更新する
キャパシティプロバイダを作成します。Amazon ECS マネージドインスタンスでキャパシティプロバイダを作成すると、指定されたクラスター内だけで使用可能になります。
詳細については、「[Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成する](create-capacity-provider-managed-instances.md)」を参照してください。
## ステップ 2: Amazon ECS マネージドインスタンス機能に合わせてタスク定義を更新する
Amazon ECS マネージドインスタンス用に requiresCapabilities を追加してタスク定義を更新します。
詳細については、「[コンソールを使用した Amazon ECS タスク定義の更新](update-task-definition-console-v2.md)」を参照してください。
## ステップ 3: Amazon ECS マネージドインスタンスのキャパシティプロバイダを使用するようにサービスを更新する
Amazon ECS マネージドインスタンスのキャパシティプロバイダを使用するように既存の Amazon ECS サービスを更新します。
詳細については、「[キャパシティプロバイダーを使用するように Amazon ECS サービスを更新する](update-service-managed-instances.md)」を参照してください。
## ステップ 4: 独立型タスクを移行する
独立型タスクの場合は、タスク実行時に Amazon ECS マネージドインスタンスのキャパシティプロバイダを指定します。
詳細については、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」を参照してください。
# Amazon EC2 から Amazon ECS マネージドインスタンスへの移行
既存のワークロードを Amazon EC2 から Amazon ECS マネージドインスタンスに移行します。この移行により、AWS マネージドインフラストラクチャを維持しながら、Amazon EC2 インスタンスタイプ、キャパシティ予約、および高度な機能のすべてにアクセスできます。
## 移行に関する考慮事項
Amazon EC2 から Amazon ECS マネージドインスタンスに移行するときは、次の考慮事項に注意してください。
タスク互換性
Amazon EC2 用に設定された既存のタスク定義は、ほとんどが Amazon ECS マネージドインスタンスと互換性があります。タスク定義の違いのリストについては、「[Amazon ECS マネージドインスタンスの Amazon ECS タスク定義の違い](managed-instances-tasks-services.md)」を参照してください。
セキュリティモデルの変更
Amazon ECS マネージドインスタンスでは、デフォルトでインスタンスごとに複数のタスクが許可されます。ワークロードで、より強力な分離が必要な場合は、シングルタスクモードを有効にすることを検討してください。
インスタンスのライフサイクル
Amazon ECS マネージドインスタンスの最大存続期間は 14 日間です。タスクの置き換えを計画し、Amazon ECS サービスを使用して自動タスク管理を行います。
料金の変更
Amazon ECS マネージドインスタンスでは、インスタンス全体の料金と、AWS がインフラストラクチャ管理のオーバーヘッドを処理するための管理費が発生します。
メンテナンスウィンドウ
Amazon EC2 イベントウィンドウを使用してメンテナンスウィンドウを設定し、Amazon ECS マネージドインスタンスをパッチ適用のために置き換えるタイミングを制御します。
## 前提条件
Amazon ECS マネージドインスタンスに移行する前に、次の条件を確認してください。
+ Amazon ECS マネージドインスタンスに必要な IAM ロールがあること。これには、以下が含まれます。
+ **インフラストラクチャロール** – Amazon ECS がユーザーに代わって AWS サービスを呼び出し、Amazon ECS マネージドインスタンスインフラストラクチャを管理できるようにします。
詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。
+ **インスタンスプロファイル** – マネージドインスタンスで実行されている Amazon ECS コンテナエージェントと Docker デーモンへのアクセス許可を提供します。
詳細については、「[Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md)」を参照してください。
+ Amazon EC2 と Amazon ECS マネージドインスタンスのセキュリティモデルの違いを理解していること
## ステップ 1: Amazon ECS マネージドインスタンスを使用するようにクラスターを更新する
キャパシティプロバイダを作成します。Amazon ECS マネージドインスタンスでキャパシティプロバイダを作成すると、指定されたクラスター内だけで使用可能になります。
詳細については、「[Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成する](create-capacity-provider-managed-instances.md)」を参照してください。
## ステップ 2: Amazon ECS マネージドインスタンス機能に合わせてタスク定義を更新する
Amazon ECS マネージドインスタンス用に requiresCapabilities を追加してタスク定義を更新します。
詳細については、「[コンソールを使用した Amazon ECS タスク定義の更新](update-task-definition-console-v2.md)」を参照してください。
## ステップ 3: Amazon ECS マネージドインスタンスのキャパシティプロバイダを使用するようにサービスを更新する
Amazon ECS マネージドインスタンスのキャパシティプロバイダを使用するように既存の Amazon ECS サービスを更新します。
詳細については、「[キャパシティプロバイダーを使用するように Amazon ECS サービスを更新する](update-service-managed-instances.md)」を参照してください。
## ステップ 4: 独立型タスクを移行する
独立型タスクの場合は、タスク実行時に Amazon ECS マネージドインスタンスのキャパシティプロバイダを指定します。
詳細については、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」を参照してください。