ECSにおけるインスタンスのENI制限が大幅に改善されネットワーク設計が簡単になりました！

「おま、これ、めっちゃECSのネットワーク設計、簡単になるやんけ！」

Amazon ECS Improves ENI Density Limits for awsvpc Networking Mode

従来のホストインスタンスを利用するECSにおいては、インスタンスのENI上限により、コンテナ周辺のネットワーク設計が複雑になるというデメリットがありました。

今回、そのENIの上限数が大幅に緩和されたことにより、ECS（on EC2）において苦労していた動的ポートマッピングなどのネットワーク設計が非常に簡単になる可能性があります。是非、このアップデートを存分に味わって、ステキなECSライフを送っていただければ。

（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     ENIｲﾛｲﾛ ﾏﾂﾘﾀﾞﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

今回のアップデート内容

ECSで利用する際の、EC2インスタンスで利用可能なENIの上限が、3〜8倍に引き上げられています。このアップデートにより、ECS（on EC2）な構成において、ネットワークモードにawsvpcを採用することが容易になります。

awsvpcネットワークモードが持つメリット

awsvpcネットワークモードを利用すると、ECSの各タスクにENIを割り当てることができます。そのため、ロードバランサーに複数タスクを紐付けるときのポート重複を気にする必要がなかったり、ENI毎にセキュリティグループを割り当てることでタスクの種別で適切な通信制御が可能だったり、多くのメリットがあります。

awsvpcネットワークモードが使いにくかった点

ただ、awsvpcネットワークモードでは、ECSのタスク毎に1つのENI（Elastic Network Interface）を割り当てる必要があるため、タスクが増えるとECSインスタンス（EC2）のインスタンスタイプによる、ENIの上限に抵触することが多くありました。

各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数

例えば、m5.largeの場合、ネットワークインターフェイスの最大数は3です。ただ、このうち1つはホストインスタンスのプライマリネットワークインターフェースとしてデフォルトで利用されているため、ECSタスクで利用できるENIは実質2つだけとなります。少ない！！

そのため、大きめのEC2インスタンスタイプを採用しない限りは、ECS（on EC2）において、awsvpcモードを利用することは難しかったです。

それが、今回のアップデートにより、もっと利用しやすくなります。

ENI上限の引き上げ方法

ENIの上限引き上げはこちらのページはこちらを参考に進めていきます。

Account Settings - Amazon Elastic Container Service

上限引き上げ方法

ECSのWebコンソールメニューを開くと、Account Settingsの文言ががあるので、これをクリックします。

すると「AWS VPC Trunking」の設定メニューが画面下に表示されます。ここの「My IAM user or role account settings」にチェックを入れます。

確認画面がでてくるので、内容を確認し、「Confirm」をクリックすれば、設定はOkです。簡単！！

設定内容の確認方法

設定内容は、以下のaws cliコマンドでも確認可能です。

$ aws ecs list-account-settings --effective-settings
{
    "settings": [
        {
            "name": "awsvpcTrunking",
            "value": "enabled",
            "principalArn": "arn:aws:iam::1234XXXX5678:role/cm-hamada.koji"
        }
    ]
}

ENI制限引き上げ後の上限と各種制限

詳細はこちらにまとめられています。

Elastic Network Interface Trunking - Amazon Elastic Container Service

ECSのawsvpcネットワークモードで起動するECSタスクは、ホスト側インスタンスの独自のElastic Nerwork Interface（ENI）を受け取ります。

上記の手順で、awsvpcTrunkingアカウント設定することで、新たに起動したコンテナインスタンスで追加のENIが使用可能です。トランクネットワーク・インターフェースはECSで完全に管理されており、コンテナインスタンスの終了か、クラスタからの登録解除で、全て削除されます。

サポートされているインスタンスの一覧と上限緩和後のENI上限数

下の一覧をご確認ください。この機能は、NITRO世代のインスタンスで利用可能です。

上の例で挙げたm5.largeですが、上限緩和後は10になっているので、ホストインスタンス1つあたり10個のECSタスクを起動することが可能です。m5.largeのスペックが2vCPU、8GB Memoryであることを考えると、ホストインスタンスで展開するコンテナの数としては十分余裕があると言えます。ええ感じ！

ENIトランキングの制限事項

• awsvpcTrunkingの設定後に起動したECSインスタンスのみがENIトランキングの対象です
  • 既存のECSインスタンスには適用されないので注意が必要
• Windowsコンテナは未サポートです
• Amazon ECSに最適化された最新のAMIを利用すれば、この機能を利用できます
  • コンテナエージェントの1.28.1-2以降

ENI制限が引き上げられたコンテナインスタンスの表示方法

aws cliを利用してコンテナインスタンスを表示することができます。下は、東京リージョンでの例です。

aws ecs list-attributes --target-type container-instance --attribute-name ecs.awsvpc-trunk-id --region ap-northeast-1

「これからはawsvpcネットワークモード、ガンガンつかっちゃいなYO！！」

端的に言って、そんな感じです。

今までECSにおいてFargateを利用するメリットとして、ホストインスタンスを気にしなくて良いという事と同じぐらい、awsvpcネットワークモードを採用することでネットワーク設計がシンプルになるというメリットがありました。

ただ、Fargateじゃない場合、どうしてもホストインスタンスのENI上限にすぐひっかかるため、awsvpcネットワークモードの利用は現実的ではなく、bridgeモードによる動的ポートマッピングなどの設定が必須でした。

上限緩和後の各インスタンスタイプのスペックとENIの制限値を見る限り、ほとんどのユースケースでは、ECS（on EC2）においても、awsvpcネットワークモードを使うことができると思われます！

また、サービスディスカバリーを利用した設計も確実にわかりやすくなります（参考：ECSのサービスディスカバリーが東京にやってきて、コンテナ間通信の実装が簡単になりました！ ｜ DevelopersIO）。

もちろん、上限があることを忘れてタスク数増やしすぎて、アジャパーとなるのは本末転倒ですが、今のネットワーク設計上の痛みを解決できる非常に有用なアップデートなので、使えるひとはどんどん、上限緩和と合わせてawsvpcネットワークモードをつかってみてください。

それでは、今日はこのへんで。濱田（@hamako9999）でした。

参考記事

ECSにおける各ネットワークモードの違いは、こちらの記事が非常に詳しいので、合わせて参考にされることをおすすめします。

• ECSでEC2インスタンスを利用する際のネットワークモードについて調べてみた ｜ DevelopersIO