More than 3 years have passed since last update.

ECSのNetwork Mode awsvpcとbridgeとHostの比較

Posted at 2021-09-26

内容

https://ecsworkshop.com/ecs_networking/ にのっているNAT以外を日本語にしてまとめた -> https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/networking-networkmode.html あとで、ここにどのネットワークモードを選択するかの公式ページがあったが、こちらがわかりやすい。

ENIを各タスクに割り振り、動的プライベートIPアドレスと内部DNS名を提供する <- コンテナネットワーク管理と操作を簡易化し、タスクがAWSのネットワーク機能を全て使うことができる
タスクのENIの管理は全てECSでされるので、コンソールから誤って消してしまうことを防いでいる
ECSは awsvpc ネットワークモードを推奨している

利点:

Considerations:

タスクのホストとなるEC2インスタンス内のDockerのbuilt-in仮想ネットワークを使う
タスクは、bridge network IPレンジからIPアドレスを取得する
コンテナは、docker0の仮想ブリッジインターフェイスを使って、インスタンス外のエンドポイントと通信する。そのインスタンスのENIを使って。
bridge networkのポートマッピングは、複数のコンテナが同じホストで同じポートを使うことが出来ない
- nginxのコンテナを2つ立てて８０番ポートをホストの80番ポートにマップしたければEC2インスタンスが２つ必要になる Static port mapping
- ホストのポートをランダムに割り振ることで同じホストでも複数のコンテナを動かすことを可能とする Dynamic port mapping <- containerDefinitions.portMappings.hostPortを0とセットすることで指定できる

Dynamic port mappingのダイアグラム:

Static port mappingのダイアグラム:

Considerations:

Additional network hop and decreased performance by using docker0 仮想ブリッジインターフェイスを使うことで、さらにネットワークホップによるパフォーマンスの劣化がある
コンテナは、Dockerから割り振られたIPアドレスでは連想可能ではない
ホストポートマッピングは、追加の操作と考慮が必要となる
一つのEC2 ENIが複数のコンテナに共有される
細かい粒度でのSecurity Groupｓによるコンテナへのネットワークポリシーの適用ができない
AWS ネットワーク監視との連携ができない

HOST MODEは、パフォーマンスを最適化するためには役立つ。コンテナが広いポートレンジを必要とする状況では、ネットワークアドレス変換を必要としないためと "userland-proxy"をそれぞれのポートに作成しないため

Considerations:
単純なアプローチだが大きなデメリットがある:

ネットワークスタックを使用しない。コンテナ内では、ループバックデバイスのみが作成される。タスクが外部ネットワーク接続を持たない場合はこちらを使える。

AWSが奨励してる通り、特に理由がなければ、ENIの上限考慮しつつawsvpcを使えばいいなと思った → その場合ENI trunking と規模によってIPアドレスの数を考慮する