こんにちは、SCSKの木澤です。
先日、VPCにおける大きなアップデートが発表されました。
EC2から複数のVPCに対してENIを接続できるようになったよ、という話です。
オンプレミスのネットワーク設計経験者であれば、この話を聞いて「管理用VPCが作れるようになったな」と感じることでしょう。
実際私自身もAWS初心者の頃は管理用のネットワークが構成できないことが気になっていました。
ですが、AWSにおいては安易に管理用VPCを設置すべきではないと考えています。
その理由を下にまとめたいと思います。
オンプレミスネットワーク設計のセオリー
オンプレミスにおけるネットワーク設計経験が無い方もいらっしゃると思いますので、丁寧に解説したいと思います。
今回は下図のような一般的なWeb3層のシステムのネットワークを設計することにします。
サービスネットワークの設計
Webサーバはインターネットから直接HTTP(S)のアクセスが届き、より外部からの攻撃を受けやすい状況にあります。
アプリケーション層やデータベースはより安全に守りたい、そのためWebサーバはDMZとして別セグメントに置くことが望ましいとされています。
HTTPS TLS復号処理のオフロードや冗長化を考慮するとこのようなネットワーク（論理）構成を採ることが一般的となります。
DBサーバクラスタ間の接続に別セグメントが推奨される場合もあります。
管理用ネットワークの追加
さて、単純にサービスを提供するのであればここまでで良いのですが、実際には運用を考慮する必要があります。
運用を考慮すると、下のような構成にすることが一般的です。
サーバの裏側に管理用ネットワークが追加されました。
以下の観点（背景）のため追加されることが多いかと思います。
監視
対象サーバ等と安定した通信を行う必要があります。
また監視はデータセンター提供ベンダー側が管轄することも多いため、責任分界のため表のサービスネットワークとは分離したいというニーズが出てくることもあります。
バックアップ
データのバックアップ・サーバ全体のシステムバックアップ、両方のニーズがあります。
バックアップのトラフィックは重いため、バックアップ中のサービス影響を避けるためネットワークを分離することが望ましいです。
メンテナンス
サーバへのメンテナンス等のためのログインも考慮する必要がありますが、障害時にも安定してログインできる必要があります。
またセキュリティの考慮のためインターネットから分離し、閉域網経由でアクセスできることが望ましいため、ネットワークを分離します。
（さらに踏み台サーバを設置し、経由しないとメンテナンスできないようにすることが通常と思いますが）
これらの理由のため、管理用ネットワークを設置することが望ましいというわけです。
マルチVPC ネットワークアタッチメントについて
さて、今回のアップデートについて触れたいと思います。
EC2インスタンスに紐付くプライマリVPCとは別のVPCにも足を伸ばし、接続できるようになったというアップデートになります。
今回は下図のように、単純に２つのVPCに接続した構成を作ってみます。
手順
まず、追加ENIを作成します。
EC2インスタンスと同一のAZである必要があります。
追加されたENIのIDを把握しておきます。
続けてEC2インスタンスに追加ENIをアタッチしますが、マネジメントコンソールでは別VPCのENIをアタッチできません。
（2023年11月7日現在。いずれ解決されるものと思いますが）
そこで、CloudShellを用いてAWS CLIでアタッチを実施します。
クラスメソッド大瀧さんの記事を参考にしました。ありがとうございます。
複数VPCに接続されたEC2インスタンスの動作
今回はテストということで以下のVPCに接続されたEC2を起動しました
- デフォルトVPC（172.31.0.0/16、接続サブネット 172.31.0.0/20）
- 追加VPC（10.101.0.0/16、接続サブネット 10.101.2.0/24）※IPv6有効
EC2から見たネットワーク状態は以下の通りで、確かに両VPCに接続されたNICが有効になっています。
ルーティングテーブルはこのような表示になっています。
両VPCのルーティングテーブルが反映され、デフォルトルートが２つ見えてしまっています。
このルーティングテーブルのままでは追加VPC側CIDR宛のルーティングテーブルが定義されておらず適切に通信ができません。
追加VPC側でルーティングができるよう、スタティックルートの設定を追加します。
これで追加VPC側でも他AZのサブネットと通信可能になります。
$ sudo route add -net 10.101.0.0 netmask 255.255.0.0 gw 10.101.2.1
(宛先CIDR) (サブネットマスク) (宛先ゲートウェイ)
同様に、下図のように追加VPC側でVPC Peeringを行った場合でも、OS上のルーティングテーブルを正しく設定すれば構成可能であることを確認しました。
本アップデートに関するAWS発表内容の通り、OS上の設定で複雑な構成を組むことができ柔軟なネットワーク構成を組めそうです。
Tips：本機能でVPC間のEC2インスタンス移行は可能なのか？
さて、本アップデートの情報に触れた際、私はこのように感じました。
追加ENIを付けてから、デフォルトのENIを削除すれば
VPC間の移行が可能では？
VPC間でEC2インスタンスを移行する際は一旦AMI作成した後にインスタンス再作成する必要があります。
これが面倒だなと感じていたので、付け替えが可能になれば楽になるな、という横着ですw
ですが、あいにくこれは不可でした。デフォルトで付与されているENIはデタッチできません。
EC2における管理用VPC設置の是非
さて新機能に触れたところで、話を戻して管理用VPCを設置することについての是非について考えたいと思います。
EC2運用管理手法の振り返り
上記にてオンプレミスネットワークにおいては管理用ネットワークを設置する理由として、主に３つの理由（監視・バックアップ・メンテナンス）があると書きました。
これらについて、EC2においては設置が必要かどうか考えてみます。
監視
EC2においてはCloudWatchによるメトリクス監視・エージェント監視が標準です。
別途サードパーティーの監視サービスを利用し、エージェント経由で監視することもあるでしょう。
これらはインターネットゲートウェイ、あるいはVPCエンドポイント経由でパブリックネットワークにあるマネージャと通信するため、管理用VPCは不要となります。
但し下図のように統合監視用のAWSアカウントを設けて管理用（監視用）VPC経由で監視したいというニーズがあるかもしれません。
この構成は検証の結果から理論上は可能であることを確認しました。
今まで本ニーズに関しては、VPCを分けずに普通にPeeringしていたかと思います。
そのため特にVPCを分ける必要性は感じませんが、監視アカウントが別オーナーである場合など選択の可能性があるのは否定しません。
後述するリスクを踏まえて判断すれば良いものと思います。
バックアップ
EC2のバックアップについては通常、EBSのスナップショットで取得するかと思います。
このトラフィックはサービスネットワークを通りませんので、トラフィック影響を排除するためにネットワークを分離する必要はありません。
データバックアップを行う場合はサービスネットワークを共用しますが、余程のことがない限り帯域を圧迫することは無いはずです。
メンテナンス
サーバへのログインを行う際、Linuxインスタンスへの接続はEC2 Instance Connectあるいはセッションマネージャを利用して接続することが推奨です。（WindowsインスタンスであればAWS Systems Manager – Fleet Manager）
何れにせよ、サービスネットワークを経由せずセキュアに接続できることが特徴です。
VPCを分割する必要はありません。
AWSインフラについて
仮想化技術
なぜこれらの運用管理機能がマネージドで提供できるのか、念のためおさらいします。
クラウドサービスにおいては、そもそも仮想化技術がベースになっていることが歴史的背景としてあります。
クラウドでは各ユーザーの設定は論理的なものとして自由に作成・削除ができますが、それを実現するために物理ハードウェア間ではユーザから見えないところで網の目のようにネットワークが張り巡らされています。
バックアップや監視についても同様で、ユーザーから見えない範囲のネットワークで実現しています。
この背景からも、ユーザ側で別途管理用ネットワークを設ける必要が無いということになるわけです。
出展：AWS Blackbelt Online Seminar(EC2)
マイクロセグメンテーション
AWSに関わらずパブリッククラウドにおいてはネットワーク仮想化(SDN)の機構が採用されています。
最大の特徴として、マイクロセグメンテーションにおける論理分割が可能なことが挙げられます。
AWSにおいては、セキュリティグループを用いて論理分割が可能です。冒頭でオンプレミスネットワークにおいては境界型防御や責任分界の観点でネットワークを分離すると説明しましたが、パブリッククラウドにおいては、そもそもその必要は無い。AWSにおいてはVPC内でセキュリティグループ等で論理分割することがベストプラクティスとなります。
最大の違いはこのネットワーク設計のアプローチにあると言えます。
管理用VPC設置のリスク
上述の検証結果から理論的には管理用ネットワークを設置することが確認できましたので、設置することに関して制約はありません。
但し、以下のリスクを踏まえて判断をすべきと考えます。
- セキュリティのリスク
やはり管理用VPCを経由して各インスタンス間が接続されていることによるセキュリティリスクを考慮すべきと思います。
セキュリティグループを用いて制御は可能ですが、接続しないことに越したことはありません。 - 構成が複雑化することによるトラブル
これはオンプレミスの場合にも同様ですが、複数ネットワークを整備することによりルーティングが複雑化することで想定外の動作をしトラブルの要因になることがあります。
できるだけベストプラクティスに則ってネットワーク構成して行きましょう！
まとめ
新機能であるMulti VPC ENI Attachmentの機能についてご紹介させていただきました。
長くなりましたが、私としての結論は「管理VPCの設置は理論上はできるが避けるべき」です。
オンプレミスとクラウド流のネットワーク設計方針の本質的な違いを振り返る良いきっかけとなりました。
ありがとうございました。