Amazon ECS Managed Instancesについて
hiren日本語ドキュメントはまだ反映されていない
マネージドインスタンス、AWS推奨のタイプらしい
Amazon ECS マネージドインスタンス (推奨)
ほとんどのワークロードに最適- AWS は、プロビジョニング、パッチ適用、スケーリングなど、基盤となる Amazon EC2 インスタンスを完全に管理します。このオプションは、パフォーマンス、コスト効率、運用のシンプルさの最適なバランスを実現します。
次の場合に使用します:
- AWSにインフラ管理を任せたい
- 自動最適化によるコスト効率の高いコンピューティングが必要です
- インフラストラクチャではなくアプリケーションに重点を置きたい
- 柔軟なスケーリングと予測可能なパフォーマンスが必要です
hirenわかりやすいブログあった
気になるところを抜き出す
hirenユーザー側はそのOSレイヤーに介入することができません。
- インスタンスへのSSHアクセス
- ルートファイルシステムの変更
- カスタムAMIの利用
hiren起動されたインスタンスのOS・セキュリティの状態を一定に保つため、Bottlerocketをベースとし、定期的なパッチ適用でOSが自動保守されます。 この制約を受け、14日毎にVMインスタンスが再起動されます。そのため、その上で稼働するECSタスクも定期的に入れ替えが必要となります。
hirenBottlerocket とは？
- パッケージマネージャのようなものは含まれておらず、フットプリントを小さくするよう意識されています。
- 攻撃者がコンテナを脱出できたとしても、使用できるツールはかなり制限されます。
- SELinux をデフォルトで enforcing モードで実行しています。
- ルートファイルシステムは読み取り専用となっており、Linux カーネルモジュールの dm-verity を利用して、ファイルシステムの整合性を維持します。
良さそう
hiren詳しくは
hiren可用性・パフォーマンス・コスト最適化の特徴は面白い
スケーリングはAWSが自動で調整
わかりやすいのブログに図解有
リソースが許す限り、同一のEC2インスタンス上に起動しようとする
マルチAZを重視して新規のEC2インスタンスが起動するのではなく、集約（=コスト最適化）の観点が優先されて、起動していく
hirenどのようなインスタンスタイプを用いるかはユーザー側でコントロール可能
デフォルトキャパシティプロバイダー＞AWSにお任せ
カスタムキャパシティプロバイダー＞こちらで指定する必要があるが、GPUも使えるなど自由
複数使える
hiren料金はEC2と同じ
タスクが沢山載るならEC2が良いが、
Fargateが良いかどうかは計算してみないと分からない
hiren制約
ECSマネージドインスタンス上のECSサービスにおいてはService Connectがサポートされていません
そのため、ECSサービス間の接続関しては、ALB / NLB / GWLBによる接続、もしくはCloud Mapを利用したサービスディスカバリによる接続のいずれか
hirenセキュリティ
FargateはFirecrackerと呼ばれるマイクロVMをベースに、ECSタスク毎にコンピューティングリソースが用意されます。 一方、ECSマネージドインスタンス側は、あくまでもEC2のVMをベースに、複数のECSタスクが集約起動される形でコンピューティングリソースが用意されます。 ECSタスクレベルでワークロードを厳密に分離したい要件がある場合、Fargateのほうが適切でしょう。
hiren起動時間
同一のインスタンスで同一のコンテナが起動する際は、キャッシュが利用され、コンテナの起動がより早くなります
コンピューティングリソースが不足した場合、追加のEC2インスタンス起動が必要となるため、その分の起動時間オーバーヘッドが発生
hirenIAMインスタンスプロファイルの権限が少し面倒かもらしい