こんにちは。AWS チームの尾谷です。
2022/12/02 (金) 08 時 30 分 (現地時間) に re:Invent 2022 で開催されたブレイクアウトセッション (NET302) をご紹介させていただきます。 私は、現地で本セッションを受講しませんでしたが、録画された動画が YouTube に公開されていました。
内容は、これまでの VPC サービスの成長と、2022 年のアップデートを紹介するセッションでした。
Level 300 ということで VPC の前提知識を持ち、精通しているエンジニア向けのセッションでした。
60 分弱の動画なので全てを視聴するのが一番勉強になりますが、私のように英語がスッと入ってこない方は本ブログで気になった箇所のみリンクから動画を視聴いただくのが宜しいかと考えます。
- 本ブログの使い方
- YouTube 動画の URL
- VPC の成り立ち
- IPv6 について
- Amazon VPC ENA Express
- Advanced Architectures
- VPC Lattice
- AWS Network Manager
- AWS Verified Access (AVA)
- まとめ
本ブログの使い方
❶ → 動画のタイムコードです。
❷ → 指定位置から再生ができます。
YouTube 動画の URL
視聴される方はこちらからどうぞ。
AWS re:Invent 2022 - Advanced VPC design and new Amazon VPC capabilities (NET302)
VPC の成り立ち
[01:22 - 04:22]
本公演のイントロダクションが手早く終えられたあと、2 分間で VPC の成り立ちが紹介されました。
登壇された Matt さんの意訳を添付しておきます。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=01m22s
Matt
「(AWS が誕生した) いちばん最初は、パブリック IP アドレスがアタッチされた Amazon EC2 インスタンスで、ルーティングやオンプレミスにデプロイされているような制御ができませんでした。」
「それで、AWS は Virtual Private Cloud や VPC と呼ばれる仕組みを作りました。Virtual Private Cloud は原則、サブネットを持ち、複数のアベイラビリティゾーンを展開することが可能です。」
「パブリックサブネットかプライベートサブネットかは、インターネットゲートウェイをデプロイします。パブリックサブネットは、AWS のパブリックサービスがご利用いただけます。」
「ルートテーブルは VPC の重要な要素の 1 つでインスタンスとの間でやり取りされるトラフィックを制御します。」
「NAT Gateway をアタッチしたプライベートサブネットであれば、パブリックインターネットやパブリックサービスを扱うこともできます。ゲートウェイエンドポイントと呼ばれる機能もご用意しています。これは、S3 や DynamoDB といったサービスをプライベートサブネットで扱えます。」
「VPC 内にロードバランシングソリューションや AWS Network Firewall などといったサービスもすべて配備するようにしましたが、それよりも、VPC が本領を発揮するのは、VPC にいろいろなものを接続し始めたときです。例えば、オンプレミスとの接続には、VPN Direct Connect が利用できます。そして、AWS はお客様から求められている大きなもののひとつに、スケールの大きさがある、と気づきました。それで、2018 年に Transit Gateway をリリースしました。Transit Gateway は、5,000 もの VPC との接続を可能にします。Transit Gateway はリージョン内の他の Transit Gateway との接続を提供します。」
「VPC フローログも提供します。」
「プライベートリンクを利用すると、独自のサービスも構築ができます。」
「Gateway ロードバランサーを利用すると、スケーラブルなファイアウォールエッジを持った検査 VPC が利用できます。」
「Client VPN と Outposts を利用すると、VPC がオンプレミスに拡張できます。」
「グローバルでもリージョンを跨いで VPC は接続ができます。」
「今年、もう GA している AWS Cloud WAN を使うことで、Transit Gateway の設定やコントロールを含まれているので、ネットワークセグメントの設定が Cloud WAN を使ってできます。」
「こうした異なる接続メカニズムを使うことで全てのリージョンを相互に接続することができます。」
ちょうど 3 分間でアーキテクチャをアニメーションしながら VPC の全てを網羅されているので、是非ご覧ください。
IPv6 について
[04:23 - 07:16]
過去 12 ヶ月 (2021/12 - 2012/11) に行ったアップデートということで、まず IPv6 が紹介されました。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=04m23s
IPv6 の問題は、2021年から取り組んでいたそうです。
パブリック IPv4 アドレスが過去から枯渇しているのは、既知の事実ですが AWS を利用するお客様のシステムで内部の RFC1918 アドレス (プライベート IPv4 アドレス) が不足する事象が発生していることに驚いたとのこと。
その原因は、上記の 「VPC の成り立ち」 で説明があった通り、オンプレミスを始めとした多くのサービスが内部に接続していて 10.0.0.0/8 といったレンジであっても範囲を使い果たすケースがあるとのこと。だから、IPv6 が必要になった。とのことでした。
プライベートサブネットの枯渇という課題を受けて、2021年に、IPv6専用のサブネットがリリースされました。
aws.amazon.com
すべてのサービスが IPv6 をサポートしているわけではないため、DNS64 をリリースしたそうです。
IPv6 のみ通信設定されたインスタンスが IPv4 アドレスを検索すると、DNS64 が IPv6 を付加します。
また、NAT64 を使用してトラフィックを NAT ゲートウェイにルーティングできるとのこと。
ALB と NLB も IPv6 アドレスでスケーリングできるとのことでした。
IPv6 専用 VPC は、高度なネットワーキングの試験や Solutions Architect - Professional でも出題されそうなテーマです。Egress-Only インターネットゲートウェイを座学で理解している程度のため、別途試してブログにしたいと思います。
IPv6 をサポートする AWS サービスは、2021 年時点で 18 個だったのが、
2022 年に 11 個追加されたと説明されていました。(動画では Matt さんが 15 から 27 に増えたと言っているように聴こえましたが...。)
今後、全てのサービスをネイティブで IPv6 にしていきたい。と意気込みを語っていらっしゃいました。
IPv6 の対応状況に関しては、こちらに掲載されています。
Amazon VPC ENA Express
[07:16 - 09:27]
続いて、Amazon VPC ENA Express が紹介されました。
Monday Night LIVE で、Peter DeSantis 氏が熱弁していた「SRD」 が正直全然理解できていなかったので、スッキリしました。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=07m16s
従来の TCP はフローベースなので特定の経路を通りがちで、分散処理を担う機器に負荷がかかる傾向がありましたが、
負荷の集中をいい感じに分散する仕組みが Scalable Reliable Datagram (SRD) routing で、既に Nitro システムに実装されているそうです。
全く新しい通信規格ではなくイーサネットベースのプロトコルで、ネットワーク全体にトラフィックを分散するため、構成変更も必要なく 25Gbps のスループットがチェックボックスにチェックを入れるだけで利用できるとのこと。
ENA Express がチェックボックスひとつをオンにするだけで気軽に利用できる点については、Jeff Barr 氏もブログで紹介されていました。
ENA Express に関して c6gn を使った ENA Express の記事 を試してみたブログを書きましたので、ご興味あればこちらもご覧ください。
注意事項として、パブリックインターネットでの利用は 5 Gbps のままなので全てが速くなるわけではない。ということでした。
Advanced Architectures
[09:27 - 26:05]
ここまでかなりのボリュームが展開されてきましたが、ここからが本セッション「Advanced VPC design」の本編といった感じでした。
セクションが長いため、なるべく細かく区切ってご覧いただきやすいように解説していこうと思います。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=09m27s
Network Address Usage (NAU)
[09:54 - 12:56]
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=09m54s
Matt
「CloudWatch 2 つのメトリクスが確認できます。1 つはシングル VPC サイズ、もう 1 つはピアリンググループ VPC サイズです。」
VPC で扱える IP アドレスのサイズについて経緯も含めて解説されていました。
VPC のサイズを説明するために、Network Address Usage というキーワードが出てきます。これは VPC で現在利用しているネットワークアドレスの使用状況のことです。
キャッチアップができていませんでしたが、NAU は CloudWatch で確認できるようになっていました。業務上、CloudWatch メトリクスをよく眺めるのに見たことがないな。と思ったらオプトインが必要でした。
NAU に関しても ブログ にしましたので、ご興味ある方はご覧ください。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=09m27s
Matt
「2022 年 10 月より、VPC 内で扱える IP アドレスの最大数が 256,000 も割り当てできます。そして、VPC ピアリングを組んだとき、更に IP が増えますので、512,000 アドレスまでサポートされるようになりました。」
「以前は、VPC 内で扱える IP アドレスの制限は 50,000 IP 程度で、ピアリングを合わせても 50,000 IP に留めていただくようお願いをしてきました。」
IP アドレスのサービスクォータは以下ドキュメントに記載されています。
VPC Sharing
[12:26 - 12:46]
VPC Sharing は Organizations に参加しているアカウント同士であれば RAM (AWS Resource Access Manager) 経由で VPC を共有できる機能です。
AWS 認定試験でもよく出題される印象ですが、Matt さんによると最近人気でよく利用されているとのこと。
VPC Sharing の場合も、VPC の制限である 256,000 IP が制限とのことでした。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=12m26s
スケーリングに関して - Transit Gateway
[12:56 - 19:08]
水平スケーリング (VPC を拡げていくスケール) と 垂直スケーリング (VPC のサイズ自体を大きくするスケール) についての感想があったあと、Alex さん (Alexandra Huides) と交代されて、Transit Gateway と Cloud WAN の説明がありました。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=12m56s
VPC Peering は同じデータセンターならコストが無料と解説されていました。
これは 2021 年に発表されていて、弊社でも提案時によく話します。
Transit Gateway を利用すると、それぞれの VPC が 256,000 IP まで利用できるので、限界なくスケールができるとのことでした。 VPC Sharing を利用した場合も同様の制限になるとのことです。
プロパゲーションするルートテーブルの色を変えて表現されていたのがわかりやすかったです。
Alex
「接続方式ごとにそれぞれルーティングを設定して Transit Gateway を構成する例です。」
「ここでは、3 つのルートテーブル (赤・青・黄) を用意しています。」
「Transit Gateway Attachment を作成すると、各 VPC は独自のアタッチメントを持ち、アタッチメントはルートテーブルに関連付けられます。そして、そのアタッチメントをどこに伝搬させるかを決定します。」
「つまり、ルートテーブルや VPC CIDR 情報の伝搬は独立した構成になります。」
「Transit Gateway を使えば、リージョンをまたいだピアリング接続が可能になります。」
「唯一の欠点は、Transit Gateway のルートテーブルにスタティックルートを追加する必要がある点です。」
「どうすればこれをもっとシンプルにできるのか？どうすればダイナミックなルーティングができるのか、また、2 つのリージョンだけでなく複数のリージョンに拡大する場合、Transit Gateway 間のピアリング接続をすべて管理しないといけないのか？」
「Cloud WAN が解決します。」
スケーリングに関して - Cloud WAN
[19:08 - 23:39]
Transit Gateway が複数のリージョンで接続した際の設定の煩雑さを解消するため Cloud WAN が誕生したとの説明がありました。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=19m08s
Cloud WAN は AWS の基礎を学ぼう第 96 回 で emi さんが作られてハンズオンを体験していたので理解しやすかったです。
Transit Gateway はルートテーブルで管理するが、Cloud WAN はセグメントで管理する。との説明がありました。
まず最初にグローバルネットワーク、コアネットワークを作成します。
Cloud WAN の一番の大枠になりまして、ASN の範囲、エッジロケーション、セグメントを設定したポリシーを作成してアタッチします。
リージョン間の接続は AWS がマネージドで行います。ピアリングの設定は不要で、リージョン間の経路はダイナミックにアドバタイズできます。
Environment タグを使ってポリシー制御ができ、VPC や VPN などの異なる環境から設定されたタグ通りにセグメントが AWS によってマネージドに適切に伝搬されます。
Alex さんは 「エンド・ツー・エンドのセグメンテーションが維持できる。」 という表現をされていましたが、Cloud WAN を利用するとリージョン間の通信設定がかなりシンプルになる印象です。
Transit Gateway と Cloud WAN の統合
[23:39 - 25:13]
Cloud WAN と Transit Gateway の設定方法を説明されていました。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=23m39s
一度 Cloud WAN と Transit Gateway の統合を行うと、Transit Gateway がルートテーブルで知っているルートと、Cloud WAN がルートテーブルで知っているルートが自動的に伝搬されるようになります。
そのため、Transit Gateway 側でスタティックルートを設定する必要もなく、Cloud WAN 側で Transit Gateway のアタッチメント用にスタティックルートを設定する必要もありません。
VPC Lattice
[26:05 - 37:00]
VPC Lattice に関しても Alex さんが解説されました。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=26m05s
VPC Lattice は re:Invent 期間中に発表されたサービスで、現在プレビュー版がリリースされています。
1 時間あたり 0.025 USD かかるということで、1,825 USD/月が最低料金のようです。
料金だけ見るとかなり高額で、プレビュー使用も躊躇するかもしれませんが大規模なサービスをシンプルに接続できるのであれば需要があると思われます。
VPC Lattice は、VPC のアドレス空間ではなく、インスタンスメタデータ (169.254.169.254) や、Amazon Time Sync Service (169.254.169.123) などで利用されているリンクローカル IP アドレスを介して提供されるため、IP アドレス枯渇の問題から解消されるとのことです。
これは新しいアプローチだと感じました。
セキュリティ設定は、IAM で設定するそうです。
モニタリングに関しては、ターゲットグループのメトリクス、サービスのメトリクス、サービスレベルとサービスネットワークレベルのアクセスログが利用できるとのこと。
s3 と Kinesis にエクスポートでき、CloudTrail も対応しているとのことでした。
AWS Network Manager
[37:00 - 38:24]
新しく AWS Network Manager というネットワーク管理とモニタリングのセントラルコンソールがリリースされました。
これまで VPC コンソールからアクセスしていた Reachability Analyzer や、Network Access Analyzer、Network Performance Insight、IP アドレス管理を行うためのサービス VPC IP Address Manager (IPAM)、グローバルネットワークのアタッチメントなどが管理できます。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=37m00s
インフラストラクチャのパフォーマンス
[38:24 - 40:21]
これまでブラックボックスだった、AWS グローバルバックボーンがモニタリングできるようになりました。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=38m24s
CloudWatch のメトリクスに登録すると、同じ AZ 内、AZ 間、リージョン間のレイテンシーを監視できるようになります。
これまでは、AWS Health Dashboard や、AWS Personal Health Dashboard、Twitter などを確認するしかありませんでしたが、観測可能なデータが公開されました。
Amazon CloudWatch Intenet Monitor
[40:21 - 43:46]
Amazon CloudWatch Internet Monitor は、AWS インフラの外側で発生した障害を把握するためのサービスです。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=40m21s
AWS はそのバックボーンの大きさと、グローバルなインフラストラクチャから、インターネットのモニタリングデータを内部的に保持していましたが、このデータを使って、AWS で公開されているエンドポイントのトラブルシューティングを行いたいとの要望があり、公開するに至ったとのことでした。
CloudWatchインターネット・モニタリングでは、VPC、CloudFrontディストリビューション、Amazonワークスペース・ディレクトリのリソースをモニタリングすることができます。
モニタリングしているすべての場所における、全体的なイベントのステータスが表示され、視覚的に確認が可能です。 VPC と CloudFront と関連付けて影響範囲を確認できます。
AWS Verified Access (AVA)
[43:46 - 52:12]
Alex さんから Matt さんに交代し AWS Verified Access を解説されました。
これが最後のリリースアナウンスでした。
https://www.youtube.com/watch?v=cbUNbK8ZdA0#t=37m00s
VPC は強固なセキュリティで覆われていて、それはまさに「壁に囲まれた庭」だという例えから話が始まりました。
この強固な VPC のインスタンスにリモートから接続するには、SSH ポートを開放する、あるいは AWS マネジメントコンソールにアクセスしてセッションマネージャーで接続しますが、ID が漏洩すると不正アクセスされる可能性があります。
Client VPN や Site-to-site を使うと 3 つのポリシーを設定する必要があります。
AWS Verified Access を使うと、VPN や Direct Connect を利用することなくローカル、またはリモートでアプリケーションに接続できるとのことでした。
まだ東京リージョンで利用できませんが、AWS Community Builder で APN AWS Top Engineers である小杉さんが ブログ にまとめて下さっていて、非常に分かりやすかったです。
まとめ
いかがだったでしょうか。
冒頭にも記載しましたが、Level 300 ということで VPC の前提知識を持つエンジニア向けのセッションで、かなり早いスピードで解説が進むため、全部を理解するのは難しいのではないかと感じます。
ただ、中の人が直接解説されているため、サービスの相関や開発の経緯を聴けますので是非視聴ください。
以上です。ありがとうございました。
