AWSのVPCに大きなアップデートが！
今週10/26、AWSにこんな機能アップデートが発表され大変話題になりました。
簡単に言うと 「EC2インスタンスから複数のVPCに対してENI（NIC）を足出しできるようになった」 という大きなアップデートでした。
みんな戦々恐々？
しかし、Twitterのオンプレミス経験者たちは口を揃えて懸念を漏らしています。
「これ、クラウド初心者がオンプレからの移行で "監視セグメントVPC" みたいなものを作ってしまうんじゃなかろうか…」
今回のアプデを見て「ウッ…😅」と感じた方も、改めて何が問題なの？と聞かれると意外としっかり言語化できないかも知れません。これを機にAWSの代表的なサービスであるマネージド論理ネットワーク「VPC」の基本をおさらいしてみましょう。
オンプレ時代の基本を振り返る
パブリッククラウド普及前のオンプレミス時代では、企業のシステムを構成するサーバーは以下のように複数のネットワークセグメントへ所属させる設計が当たり前でした。
そのために各サーバーはNIC（ネットワークインターフェースカード）を複数持ち、それぞれの用途のセグメントへ "足を出す" 構成をとっていました。
こんな構成をとるのには理由があります。
- サービス系の経路に不正侵入されても管理系サーバーへの影響を隔離できる
- 夜間バッチなど運用系の帯域消費をしてもサービスに影響を与えない
- 逆にアクセス輻輳によって帯域逼迫してもサーバー監視や管理系操作を継続できる
クラウドのVPCは「マネージド論理ネットワーク」
一方でAWSのVPC上に同様のアプリケーションを構成する場合、以下のような形になることが多いと思います。
オンプレミスでは用途別の「セグメント」として2種類のネットワークを用意していましたが、VPCは単一のCIDR体系のみを使う形です。
クラウドだとこうなる理由は、オンプレミスのときと責任分担が異なるためです。
- AWSユーザー（＝システム管理者）はVPCを構成する低レイヤーな基盤領域（帯域など）を意識する必要がない ※
- アクセス制御のために物理セグメントを分離する必要はなく、セキュリティグループやNACLを使って論理的に設定するのが基本思想
- 監視や運用機能のためにVPC内にIaaSリソースを構築しなくとも、専用のマネージドサービスが用意されている
ようは、複数のネットワークセグメントをユーザー側が設計・管理する「必要がない」んですね。
※ENIには一応、帯域幅のクォータ（Gbpsレベルと大きめですが）があることは認識する必要があります。
じゃあ今回のアップデートは一体何のため？
What's Newの本文でも触れられていますが、AWSが想定する "マルチVPC-ENIアタッチ" のユースケースは以下のようです。
- 集中管理型アプライアンスやデータベースのように分離が難しいコンポーネントを複数VPCへENIレベルでアクセスさせたい場合
- 通信事業者のような顧客で「AWS内」と「AWS〜オンプレ間」で異なるタイプの通信を利用する必要があり、論理ネットワークを分離しつつ前述のようなリソースを共有したい場合
つまりオンプレミス設備が絡み、かつ特殊な低レイヤーの要件を持つ場合のニーズに応える機能と位置付けられていることが読み取れます。
まとめ
これまでもクラウド初心者の方がオンプレ→AWS移行を検討する際「現行踏襲で運用監視VPCを作ろう！」と考えてしまう場面は多かったかも知れません。今まではVPCの仕様制約として実現できませんでしたが、今回のアップデートによりそれが可能になってしまいます。
みなさんは是非、周囲でそういった方を見かけたらクラウドにおけるネットワーク設計の根本思想を正しく共有してあげましょう。オンプレミスで頑張っていた方ほど最初は戸惑うかも知れませんが、適切に啓蒙してあげればきっと「クラウドって便利だね！」と思ってくれるでしょう。
おまけ
早速この新機能を触ってアウトプットくださっている方がいます！ 早いですねｗ