re:Invent 2024: AWSのネットワーク設計 - VPCからCloud WANまで
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Design well-architected networks on AWS (NET202)
この動画では、AWSのネットワーク設計のベストプラクティスについて、AWS Principal Solutions ArchitectのAndrew Grayらが解説しています。VPCやSubnetの基本から、Transit Gateway、AWS Cloud WAN、VPC Latticeなどの高度な接続オプション、そしてSecurity GroupsやNetwork Access Lists、AWS Network Firewallなどのセキュリティ機能まで、幅広いトピックをカバーしています。特に注目すべきは、Armの事例で示された大規模なマルチリージョン環境でのIPv4/IPv6アドレス計画や、集中型・分散型それぞれのトラフィックインスペクションパターンの比較など、実践的な知見が豊富に共有されている点です。また、Route 53 ProfilesやDNS Firewallなど、最新のネットワーク管理機能の活用方法についても詳しく説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSネットワーキングセッションの概要と注意点
みなさん、こんにちは。NET 202「Designing Well-Architected Networks on AWS」にご参加いただき、ありがとうございます。私はPrincipal Solutions ArchitectのAndrew Grayです。本日は同僚と共に登壇させていただきます。AWS Professional ServicesのSenior Cloud Infrastructure ArchitectのDmitry Figolです。ArmのDirector of Engineering Platform ArchitectureのRadek Podedwornyです。
まず、いくつか注意点をお伝えしたいと思います。これは200レベルのコースですので、VPCやSubnetの基本的な概念はご理解いただいているものとして進めさせていただきます。基礎的な内容は割愛し、Well-Architectedな実装方法やベストプラクティスに焦点を当てていきます。 プレゼンテーション中、様々なQRコードが表示されますので、お手持ちのカメラで自由に撮影してください。セッション後にスライドのコピーをダウンロードしてアクセスすることも可能です。また、Well-Architectedキャットが登場し、Well-Architectedなネットワーク実装に関する数々のヒントやコツを紹介してくれますので、お楽しみに。
AWSのグローバルインフラとVPCの基本構造
それでは、AWSのネットワーキングの基本から始めていきましょう。 AWSのグローバルインフラストラクチャは、RegionとAvailability Zoneで構成されています。高スループットのバックボーンで相互接続された30以上のRegionがあり、各Regionには少なくとも3つのAvailability Zoneが存在します。各Availability Zoneは、1つ以上のデータセンターで構成されています。AZは、低レイテンシーで同期データレプリケーションをサポートできる程度に近接していますが、停電や自然災害による同時障害を防ぐために十分な距離を保って配置されています。
Amazon Virtual Private Cloud（VPC）は、AWSの主要なネットワーキング構成要素です。これはRegionレベルで存在する独立したネットワークセグメントで、 VPC内には1つまたは複数のIPv4やIPv6のCIDRブロックを割り当てることができます。 VPC内にはSubnetがあり、これはAZレベルの構成要素です。Dual-stack Subnet、IPv4専用Subnet、IPv6専用Subnetを設定できます。
ここで、Well-Architectedキャットが重要なヒントを持ってやってきました。 私たちは、Dual-stackアプローチを採用し、可能な限りクロスAZ通信を最小限に抑えることをお勧めしています。これにより、レイテンシーの低減、コストの削減、リスクの軽減が実現できます。 また、マルチアカウント環境では、AZ名の代わりにuse1-az1、use1-az2、use1-az3などのAZ IDを使用することをお勧めします。これは、AZ名がアカウント間で異なる可能性があるためです。
それでは、VPCのインターネットアクセスについて説明していきましょう。 IPv4またはIPv6でインターネットとの通信を行うには、Internet Gateway（IGW）と呼ばれる構成要素を使用します。 Internet Gatewayへのデフォルトルートが設定されているSubnetを、パブリックSubnetと呼びます。IPv6の場合は追加の設定は必要なく、IPv6アドレスを持つインスタンスはInternet Gatewayを通じて通信できます。 一方、IPv4の場合は、パブリックIPアドレスであるElastic IPアドレスという追加の構成要素が必要です。トラフィックがInternet Gatewayを通過する際、プライベートIPv4アドレスからElastic IPアドレスへのSource Network Address Translation（送信元ネットワークアドレス変換）が実行されます。
パブリックSubnetでは、リソースからインターネット上のホストへの通信と、インターネット上のホストからリソースへの通信の両方が可能です。 インバウンド接続を許可したくない場合は、プライベートSubnetを使用します。IPv4の場合、アウトバウンドのインターネット接続を可能にするために、パブリックSubnetにNAT Gatewayを配置します。IPv6の場合、 Egress-only IGWと呼ばれる別の構成要素を作成します。 IPv4とIPv6それぞれに対応するデフォルトルートを設定することで、アウトバウンド接続は開始できるものの、インターネットからのインバウンド接続は開始できないプライベートSubnetの機能を実現できます。
最近、インターネットとの間の接続性をコントロールする新しいデータプレーン制御機能として、VPC Block Public Accessをリリースしました。これにはいくつかのモードがあり、除外設定も可能です。例えば、VPC Block Public AccessにIngress-onlyモードを設定した場合、インターネットから左上のインスタンスへの接続は許可されませんが、そのGatewayを通じたアウトバウンド接続は引き続き許可されます。
NAT Gatewayは各Availability Zoneに作成することをお勧めします。 また、プライベートSubnetを優先的に使用し、ほとんどのリソースをプライベートSubnetに配置し、Internet-facing Load BalancerやNAT Gatewayなど、必要なリソースのみをパブリックSubnetに配置することをお勧めします。最後に、追加のコンプライアンス対策としてVPC Block Public Accessを使用することをお勧めします。
VPCの接続性とApplication Recovery Controller
次に、IPv6 SubnetとIPv6専用ホストがあり、IPv4のみを使用するインターネット上のホストと通信したい場合について説明します。この場合、DNS64とNAT64を使用できます。まず、 Subnet levelでDNS64を有効にします。これにより、Route 53 ResolverからのDNS解決で、IPv4アドレスをエンコードした特別な DNS64 IPv6アドレスが返されます。この特定の DNS64プレフィックスに対して、NAT Gatewayへの追加ルートを設定します。このGatewayがトラフィックを受信すると、このIPアドレスをIPv4に変換します。これにより、VPC内のIPv6専用ホストとインターネット上のIPv4専用ホスト間の接続が可能になります。
Load Balancerのヘルスチェックについてお話ししましょう。Load Balancerはターゲットのヘルスチェックを行いますので、アプリケーションの健全性を適切にテストする、きちんとしたヘルスチェックを設定することが非常に重要です。 さらに、Route 53はLoad Balancerノード自体のヘルスチェックも行います。そのため、Load Balancerや特定のLoad Balancerノードの背後にあるすべてのターゲットに問題が発生した場合、Route 53はそのLoad BalancerノードをDNS解決から除外することができます。
Amazon Application Recovery Controller（ARC）についてお話ししましょう。これは私が最も気に入っているAWSのネットワーク機能です。Load Balancerの背後にアプリケーションを配置してモニタリングを設定すると、特定のAvailability Zoneのレイテンシーが高くなっていたり、エラー率が上昇していることに気付くかもしれません。 そのような場合、APIコールを使ってApplication Recovery Controllerにzonal shiftの開始を要求することができます。 Load Balancerのノードがから除外され、そのAZからのサービスを停止することができます。
これを実装する際のヒントをご紹介します：まず、事前に十分なキャパシティを確保しておく必要があります。 つまり、特定のAZからトラフィックを除外した場合でも、他のすべてのAZがトラフィックの急増に対応できるようにしておく必要があります。 実際の障害が発生した際に確実に機能するよう、定期的にテストを行うべきです。 また、最近では、AWSが自動的にzonal shiftを実行できるzonal autoshiftという機能もリリースしました。 さらに最近では、cross-zone load balancingが有効な状態でも、Application Load BalancerとNetwork Load Balancerの両方でARC zonal shiftをサポートすることを発表しました。
VPC間接続の多様な方法とベストプラクティス
複数のVPCがある場合、それらをどのように接続できるのでしょうか？AWSにはVPCを接続するための方法が数多く用意されています。その大部分について説明し、それぞれをいつ、どのように使用すべきかについてのヒントをお伝えしていきます。最初に取り上げるのは、VPCのサブネット共有です。サブネット共有については、お客様の間で興味深い経緯があります。
これが何であり、どのように機能するのかについて、多くの混乱がありました。この簡単な例では、VPCとサブネットを持つ3つのアカウントがあります。これが異なるアカウント間で共有しているものです。一般的なユースケースとしては、集中管理されたネットワーキングチームがinterface endpointsやRoute 53 Resolver、その他の機能など、すべてのサブネットの側面を設定・制御したい場合です。彼らは実質的に、他のアカウントにそれらのサブネットにリソースをデプロイする権限を付与します。
Subnet共有に関して注意すべき点が2、3あります。この方法を採用すると、VPCの分離機能の一部が失われますが、先ほど説明した機能が得られます。また、共有Subnetにデプロイしたいものすべてが実際にサポートされているかどうかを確認してください。というのも、一部のAWSサービスではサポートされていないためです。次はVPC peeringについてです。VPC peeringは、2つのVPC間に接続を確立し、効果的にそれらを結びつけるものです。この相互作用は、2つのVPCをほぼ1つのように機能させるもので、限られたシナリオにおいて優れたオプションとなります。
主な注意点は、接続するVPCの数が少ない場合に適しているということです。1つのVPC内で持てるPeering接続は125個までで、相互接続されたVPCグループの規模にも制限があります。これは、VPC間通信のための巨大なグローバルソリューションとして意図されているわけではありません。ただし、特定の状況、特にクロスリージョンの作業を行う場合には有用です。最大限の帯域幅や可能な限り低いレイテンシーが必要な場合は、VPC peeringを使用できます。先ほど述べたように、これは2つのVPCを実質的に統合するようなものなので、他のAWSネットワークサービスで見られる多くのクォータは適用されません。ただし、この構成では、インスペクションを簡単に行ったり、集中管理された通信やファイアウォールを通じて処理を行ったりする機能など、いくつかの機能が失われることに注意してください。
次はAWS Transit Gatewayです。Transit Gatewayについて詳しくは説明しませんが、これはAWSのクラウドネイティブで、高い冗長性とスケーラビリティを持つクラウドルーターです。ここでは、Transit Gatewayの様々な使用方法についてお話ししたいと思います。Transit Gatewayとそれに接続するVPCは、様々な組み合わせで設定でき、多様なトポロジーを形成することができます。フルメッシュが最も一般的ですが、個別のサイロを作成したり、集中型のインスペクションを実装したりすることもできます。通常のルーター制御で可能なことは、ほとんどTransit Gatewayでも実現できます。
Transit Gatewayをデプロイする際には、いくつか注意点があります。まず、AWSは、各VPCにデプロイする必要があるTransit Gateway attachmentを、専用のSubnetに配置することを強く推奨しています。多くのお客様は、これを他のリソースと同じSubnetに配置しようとしますが、より具体的なルーティングを追加したい場合に問題が発生します。個別のSubnet、特に個別のRoute tableを持つことは非常に有用で、将来の高度なネットワーキングの選択肢を残すことができます。次に、実際に使用しているAvailability Zone全てにTransit Gateway attachmentを配置するようにしてください。多くのお客様が1つのAvailability Zoneにのみデプロイして十分だと考えていたケースで問題が発生しています。インスタンスは、Availability Zoneを越えてTransit Gateway attachmentと通信することはできず、ローカルのAvailability Zoneに必ずattachmentが必要です。
次に上位の構成として、比較的新しいAWS Cloud WANがあります。これは過去数年の間に登場したものです。Cloud WANもクロスリージョン通信を可能にするものですが、個別のattachmentではなく、Segmentという概念に焦点を当てています。これは、Core Network Policyという比較的わかりやすいポリシーでSegment間の相互作用を定義する必要がある場合に非常に便利な機能です。特定のRoute tableを気にする必要がなくなります。これは、開発環境が特定の状況でのみ本番環境と通信できるようにするセキュリティグループと連携する場合や、US本番環境とEU本番環境が特定の状況でのみ相互に通信できるようにする場合に役立ちます。これらすべてをCloud WANのポリシードキュメント内でJSONとして定義でき、ルートの設定はすべて自動的に処理されます。
また、Cloud WANを使用して、インターネットへのNorth-South通信や、Cloud WAN内の異なるVPC間のEast-West通信のための検査セグメントを実装することもできます。さらにマルチリージョンでもすべてを処理してくれます。 加えて、AWSは最近、Direct ConnectがCloud WANに直接接続できるようになったことを正式に発表しました。以前は、Direct Connect接続を終端するためにTransit Gatewayが必要でした。
私たちの経験から、いくつかのヒントをお伝えします：セグメントを増やすことを恐れないでください - 1つや2つ、3つのセグメントに無理に詰め込もうとしないことです。多くのお客様は、異なる研究グループが分離状態を保ちたいという理由だけで、10〜15のセグメントを使用しています。 そして先ほど述べたように、Cloud WANは実装する意思さえあれば、検査を簡単に行うことができます。Cloud WANをぜひしっかりと検討してみてください。
VPC LatticeとVPC Endpointsの活用
次のオプションはAmazon VPC Latticeです。AWSは過去1年間、VPC Latticeについて広く説明してきましたが、 ネットワーキングの専門家でさえ、まだその正体について確信が持てないでいる傾向にあります。概要として、2つのVPC - クライアントとサーバー - があり、 その中にある各インスタンスが通信する必要があるとします。両方のVPCをVPC Latticeサービスネットワークの一部として設定できます。これはコントロールプレーンの構成要素であり、 この時点では物理的なインフラはまだありません。その後、これらのVPCそれぞれにVPC Latticeエンドポイントをデプロイします。
そして、Transit Gatewayやその他のネットワーキング構成要素を必要とせずに、サーバーはVPC Latticeに対して、ロギング、認証、その他提供したいサービスを提供していることを登録します。また、VPC Latticeが強制する認証要件も指定します。 クライアントは認証情報を提供してサービスアクセスをリクエストし、VPC Latticeはそのリクエストを受け入れてトラフィックの流れを許可します。 これを実現するために他のネットワーキング構成要素は必要なく、サーバーをクライアントから完全に分離できます - これがVPC Latticeの力です。サーバーは同じVPC内、異なるVPC、または複数のVPCにまたがって配置することができます。
VPC LatticeはHTTP、HTTPS、gRPCタイプのアプリケーションに適しています。昨日発表されたばかりですが、現在はサービスネットワークエンドポイントを追加できるようになり、オンプレミスからVPC Latticeネットワークに接続できるエンドポイントを持つことができます。これは 構築したこれらの構成要素にアクセスする際に非常に便利です。
次はVPC Endpointsについてです。Endpointについて話す際、AWS PrivateLinkについて触れることになりますが、これによってVPCにInterface Endpointをデプロイすることができます。 これらのEndpointは150以上のAWSサービスへの直接的なルートとなります。また、別のVPCへの接続も可能です。 これは、Software as a Serviceやあなたの社内サービスでよく見かけるパターンです。Network Load Balancerを背後に配置するだけで済み、そのVPCは別のアカウントに存在していても、元のVPCとアドレスが重複していても問題ありません。 さらに、最近発表されたCross-region PrivateLinkのサポートにより、別のリージョンにあるVPCとも接続できるようになりました。
また、Amazon S3やAmazon DynamoDBと通信するためのGateway Endpointもあります。ここで2つの重要なポイントがあります：可能な限りGateway Endpointを使用してください。Interface Endpointとは異なり無料だからです。Interface Endpointを使用すると、Transit GatewayやNAT Gatewayで発生する可能性のある中間データ処理コストを心配することなく、直接接続が可能です。
AWSは最近、Resource Endpointsという概念を発表しました。これは PrivateLinkとVPC Latticeを融合させたようなものです。Resource Endpointsを使用すると、Load Balancerを前段に配置することなく、IP、DNS名、または RDSインスタンスをターゲットにすることができます。これらすべてをVPCに拡張可能なリソースとして定義できます。Resource Endpointは、Load Balancerを持っていない場合や、Kafkaのようなメッシュプロトコルを使用している場合に特に便利です。このようなワークロードに非常に役立ちます。
これらのVPCを接続する方法は多数あることを覚えておいてください。私が強くお勧めするのは、80/20ルールを見つけることです。 つまり、トラフィックの80%を処理できる方法を見つけ、必要に応じてPrivateLinkやVPC Lattice、その他のソリューションを用意しておくということです。
すべてを1つのソリューションに詰め込もうとするのは避けましょう。ただし、ある程度のガードレールは設けておく必要があります。制御されていない状態で何でもかんでも起こることは避けるべきです。
マルチリージョン展開とDirect Connectの考慮事項
Amazon VPCの内部について多くお話ししてきましたが、ここでマルチリージョンを採用すべき場合について説明しましょう。まず、適切に設計されたアプリケーションから始めましょう。3つのAvailability Zoneがあり、その前にLoad Balancerが配置され、それらのLoad BalancerにDNS名が向けられています。これは素晴らしい構成であり、アプリケーションとして理想的な姿です。上部に2番目のリージョンを追加するのは、単に2番目のリージョンにコピーをデプロイし、Amazon Route 53を更新して2番目のリージョンのリソースを指すように設定するだけで簡単です。
ただし、いくつか注意点があります。Route 53には、トラフィックを制御するための興味深い方法がいくつか用意されています。ラウンドロビンを使用する必要は全くありません。Route 53では、クライアントとエンドポイント間のレイテンシー、地理的位置、地理的近接性に基づいてルーティングを決定できます。これらはすべて、クライアントの位置を特定し、適切なリージョンに送信するための方法です。例えば、アメリカのお客様をUSリージョンに、EUのお客様をEUリージョンに振り分けたい場合に便利です。
マルチリージョンデプロイメントは、レイテンシーを削減し、可用性を向上させるために使用します。マルチリージョンの構造、Transit Gatewayなどについて説明する際に覚えておいていただきたいのは、中国を経由することはできないということです。中国はAWS内で別のパーティションとなっているため、多くの場合独立した領域として扱われます。AWS Transit Gatewayはリージョン間を接続できるサービスの1つですが、ここで最も多く受ける質問は、このトラフィックがAWSのバックボーンから外れるかどうかということです。答えは「外れません」。このトラフィックがインターネットなどを経由することは一切ありません。
Transit Gatewayピアリングやその他のクロスリージョン接続を行う場合、そのトラフィックはAWSのバックボーン上に留まります。ただし、レイテンシーへの影響には注意が必要です。アプリケーションチームは同一Availability Zone内や同一リージョン内の異なるAvailability Zone間のレイテンシーには慣れていますが、マルチリージョン間のレイテンシーはかなり高くなります。幸いなことに、AWSはInfrastructure Performance toolを使って、どの程度レイテンシーが高くなるかを確認できるツールを提供しています。まだコンソールでご覧になっていない方は、非常に興味深いツールです。このツールを使用すると、AWSが測定しているリージョン間やAvailability Zone間のレイテンシーを確認でき、任意の組み合わせを選択してミリ秒単位でレイテンシーを示す分かりやすいチャートを得ることができます。
VPC間の接続について多く説明してきましたが、ここでデータセンターとの接続について説明しましょう。お客様はほぼ間違いなく、まずAWS Site-to-Site VPNから始めます。これは、お客様のサイトのルーターやファイアウォールと、AWS側のVPCの間に設定できるIPsecトンネルです。シンプルで分かりやすい方法です。ただし、設定時の重要な注意点として、トンネル1とトンネル2のオプションが表示されますが、必ず両方を設定してください。AWS側では比較的頻繁にメンテナンスを行っており、両方のトンネルを設定しておくことで、お客様側のデバイスがトンネル間でフェイルオーバーでき、影響を軽減できます。ただし、これはAWS側のフェイルオーバーに対する保護にすぎません。お客様側では、別のデバイスに向けて2つ目のトンネルセットを設定し、真の冗長性を実現することをお勧めします。
多くのお客様は、Site-to-Site VPNからAWS Direct Connectへと移行する傾向にありますが、Direct Connect とVirtual Interface（VIF）に関して多くの質問が寄せられています。Direct Connectはお客様とAWSを結ぶ光ファイバーリンクで、複数のVIFを設定することができます。VIFのタイプを選択する際、Private VIFは1つまたは少数のVPCに直接接続する場合に使用します。Transit VIFはTransit Gatewayを使用する場合に使用され、これが 現在多くのお客様が選択している方法です。つまり、Transit VIFを使用してセントラルのTransit Gatewayに接続するというものです。そして、よく見落とされがちな3つ目のタイプがPublic VIFです。
Public VIFについては誤解が多いようです。Public VIFはAWSのパブリックバックボーンへの接続を提供し、パブリックIPを持つAWSサービスにアクセスすることができます。また、パブリックIPを持つ他のお客様にもアクセスできるため、この接続は外部からのアクセスが可能なため、外部接続として扱う必要があります。ただし、インターネットへの直接アクセスは提供されず、AWSのパブリックリソースへのアクセスのみが可能です。また、ほとんどの企業や デプロイメントでは、グローバルで1つのDirect Connect Gatewayだけで十分です。Direct Connect Gatewayは純粋にコントロールプレーンのコンポーネントで、Route Reflectorと同様の機能を持ち、実際のデータはここを通過しません。VIFごとにDirect Connect Gatewayをデプロイしているケースを見かけますが、それは不要です。最後に、Direct Connectの冗長性については3つのレベルがあります。1つ目は開発やテスト用の単一接続で、1つまたは複数の接続を1つのロケーションに持つパターンです。
次のレベルは高可用性で、2つのロケーションを使用しますが、各方向に単一のリンクしかありません。 最後は最大冗長性で、これらすべてを組み合わせたもので、複数のロケーションに複数のリンクを持つことで最高のSLAを実現できます。SLAを設計する際はこれらを念頭に置いてください。
暗号化は常に考慮すべき要素として挙がってきます。 AWSは施設間のトラフィックをすべて保護しているので、そこまで心配する必要はありません。Direct Connect側の暗号化が気になる場合は、多くのサイトでLayer 2暗号化のMACsecをサポートしており、 これは有用なオプションとして利用可能です。また、Direct Connectリンク上でIP VPNを実装することもできます。Transit Gateway上で プライベートIP VPNを設定して終端させたり、Direct Connect経由でVPCにSite-to-Site VPNを終端させたりすることができます。ただし、 TLSなどのアプリケーションレベルの暗号化の方が、これらの心配をするよりも適切な解決策となることが多いでしょう。
DNSの設計とネットワークセキュリティの階層的アプローチ
最後に、Direct ConnectはVPNでバックアップできることを覚えておいてください。 そして、接続に関しては「1つは無に等しく、2つで1つ」という考え方を忘れないでください。IPアドレスについて多く話してきましたが、人間は数字が苦手だと言われています。では、どうすればよいでしょうか？ここで、Domain Name System（DNS）について、そしてAWS上での 適切な設計方法について話してみましょう。
VPCにインスタンスがあるとして、設定を変更しない場合、そのインスタンスはデフォルトでRoute 53 Resolverを使用します。これは、VPC内で利用可能な高可用性でスケーラブルなDNSリゾルバーです。また、VPCプラス2のIPアドレスでも利用可能です。デフォルトでは、パブリックDNSクエリを解決します。では、内部で使用する特別なドメインが必要な場合はどうでしょうか？この場合、aws.internalドメイン用のプライベートホストゾーンを設定し、その中にあらゆる種類のレコードを持つことができます。このプライベートホストゾーンにVPCを関連付けると、そのVPCのRoute 53 Resolverは、このプライベートホストゾーンからレコードを解決できるようになります。
カスタムDNSサーバーがある場合はどうでしょうか？オンプレミスの場合もありますし、AWSの他のDNSサービス、例えばActive Directoryの場合もあります。ハイブリッドDNS解決を実現するために、アウトバウンドRoute 53 Resolverエンドポイントを作成し、関連するリゾルバールールを作成します。これにより、特定のドメインに対して、DNSクエリを特定のDNSサーバー（IPv4またはIPv6）に転送するように指定します。このリゾルバールールは、組織全体でRAM共有することができ、VPCをそのリゾルバーに関連付けることができます。これを行うと、Route 53 Resolverは、特定のドメインに対するDNSクエリを、リゾルバールールで指定したDNSサーバーに転送します。
逆引きDNS解決の場合、AWS上のプライベートホストゾーン内のものなど、オンプレミスのDNSサーバーからDNSクエリを解決したい場合は、インバウンドリゾルバーエンドポイントを作成し、DNSサーバー上で適切な設定を行って、クエリをAWSに転送することができます。よく見かけるアンチパターンについてお話ししましょう。1つ目は、DHCPオプションを使用してデフォルトのDNSサーバーを上書きすることです。この場合、2つのDNSサーバーがあり、DHCPオプションを使用してDNSサーバーを変更します。リスト内の最初のDNSサーバーが高負荷になり、クロスAZトラフィックが発生し、その結果、追加の遅延、リスク、コストが発生します。一般的に、DHCPオプションの上書きはお勧めせず、デフォルトのVPCプラス2リゾルバーの使用を強く推奨します。
もう1つよく見かけるアンチパターンは、アウトバウンドからインバウンドエンドポイントにDNSトラフィックを送信する場合です。共有サービスVPCに2セットの異なるエンドポイントがあり、プライベートホストゾーンを共有サービスVPCに関連付けます。しかし、異なるドメイン用のリゾルバールールを作成し、アウトバウンドからインバウンドリゾルバーエンドポイントにトラフィックを送信します。これもクロスAZトラフィックを発生させ、これらのエンドポイントを通過するすべてのクエリに追加コストがかかります。一般的に、これは推奨されるアプローチではありません。
このようなアンチパターンを使用する代わりに、組織全体でDNS設定を一貫させる方法を説明させていただきます。プライベートホストゾーン、リゾルバールール、そしてRoute 53 Resolverを通過するすべてのDNSクエリをログに記録するクエリロギングを用意します。さらに、特定のDNSクエリをブロックまたは許可するDNS Firewallを追加することもできます。これらすべてをAmazon Route 53 Profileにまとめることができます。そしてRAM共有し、組織内のすべてのVPCに関連付けます。これにより、DNS設定への変更が環境全体に確実に伝播されるようになります。
DNSに関する重要なポイントをいくつかご紹介します。デフォルトのDNSサーバーは変更せず、 ハイブリッドDNS解決にはResolverエンドポイントを使用し、Resolver Rulesを使ってドメインのルールを設定します。 Route 53 Profilesを使用してDNS設定の一貫性を保ちましょう。では次に、 AWSにおけるネットワークセキュリティについて見ていきましょう。これは階層的なアプローチとして考えていただきたいと思います。AWSには、この分野で役立つ様々な層と様々なサービスがあります。
VPC内には、Security GroupsとNetwork Access Lists（NACLs）があります。Security Groupsは、ほとんどのネットワークインターフェースに存在する分散型のステートフルファイアウォールです。一方、Network ACLsは、サブネット間のステートレスファイアウォールです。一般的に、Network Access Listsの使用は最小限に抑えることをお勧めします。というのも、ルール数に制限があり、エフェメラルポートの扱いが非常に難しいためです。しかし、Security Groupsについては、できる限り活用することをお勧めします。
VPCの境界では、追加のファイアウォールを設置することができ、 それはAWS Network FirewallのようなAWSマネージドファイアウォールか、Gateway Load BalancerとGateway Load Balancer Endpointを使用したサードパーティ製ファイアウォールのいずれかを選択できます。既に説明したRoute 53 DNS Firewallでは、特定のDNSクエリのブロックや許可が可能です。Webアプリケーションに特化したセキュリティについては、AWS WAFの使用をお勧めします。 これにより、OWASP Top 10などの一般的なWebの脆弱性から保護することができます。レート制限ルールを設定することも可能です。
DDoS対策が必要な場合は、 AWS Shieldを利用できます。これにはStandardとAdvancedの2種類があります。 組織全体のセキュリティ設定（Security Groups、Network Access Lists、WAF ACLs、Network Firewall Policiesを含む）を管理したい場合は、AWS Firewall Managerを使用できます。
Security Groupsのクロスリファレンスについて、特に時間を割いて説明させていただきます。これは非常に強力な機能で、積極的な活用をお勧めしています。この例では、3層のアプリケーションがあります。 ロードバランサー、アプリケーション用のインスタンス、そしてデータベースです。それぞれの層に対して、特定のSecurity Groupを定義します。 これらの層間の適切な通信を許可するようにSecurity Groupルールを設定します。ご覧の通り、ここではIPアドレスをほとんど使用していません。これは非常に強力な特徴です。なぜなら、IPアドレスを気にする必要がないからです。さらに重要なのは、新しいロードバランサーや新しいAuto Scalingインスタンスなど、動的なIPアドレスがある場合でも、Security Groups の変更が不要だということです。
VPC Peeringに関するSecurity Groupのクロスリファレンスは以前からサポートしていましたが、現在ではTransit Gatewayでもサポートされています。ぜひこの機能を活用して、Security Groupルールの管理をスケールさせてください。では、お客様との会話で私が最も好きなトピックの1つである、トラフィックインスペクションのパターンについてお話ししましょう。ファイアウォールには通常、3つのユースケースがあります：VPC間のインスペクション（East-Westインスペクションとも呼ばれます）、エグレスフィルタリング、そしてイングレスフィルタリングです。それぞれについて詳しく見ていきましょう。East-Westについては、実際のユースケースと、達成したいセキュリティ上の目的について考えていただきたいと思います。ファイアウォールを設置する場合は、トラフィックが暗号化されている可能性が高いため、どのような設定を展開するかを具体的に考える必要があります。
トラフィックインスペクションパターンと実装方法
例えば、動的IPの場合、Security Groupのクロスリファレンスの方が適していると言えます。なぜなら、ファイアウォールのルールを変更する必要がないからです。また、Amazon EPCのようなサービスを使用して、アプリケーション層自体で認証と認可を行うZero Trustアプローチも検討に値します。
次にエグレスについて話しましょう。ワークロードがインターネットにアクセスする際には、IPv4のネットワークアドレス変換について考える必要があります。セキュリティ、特にエグレスドメインフィルタリングについて考慮する必要があり、NAT GatewayやAWS Network Firewallなどのサービスがこれを支援します。問題は、これらをどこに配置するかということです。エグレスの最初のモデルは、集中型エグレスです。この場合、ファイアウォールエンドポイントとNAT Gatewayを用意し、集中型エグレス用の特別なVPCを作成してそこに配置します。そして、このエグレスVPCをTransit Gatewayを使用して他のすべてのVPCと接続します。これは、お客様がよく実装されているアプローチです。
セットアップと管理が非常に簡単で、そのファイアウォールエンドポイントをEast-Westトラフィックにも再利用できます。ただし、ここではコストについて考える必要があります。エンドポイントとNAT Gatewayの数は少なくて済みますが、Transit Gatewayのデータ処理料金が追加で発生します。特にIPv6の場合、集中型エグレスにはプロキシまたはNAT66ソリューションが必要になります。これに代わるのが分散型エグレスです。この場合、各ワークロードVPCにファイアウォールエンドポイントとNAT Gatewayを配置します。主なメリットは、他のVPCから独立してスケールできることです。プラス比率が単一のVPCに限定されます。IPv6にネイティブ対応していますが、コストについて考える必要があります。この場合、ファイアウォールエンドポイントとNAT Gatewayの数は多くなりますが、Transit Gatewayのデータ処理料金は発生しません。
次に、おそらく最も議論を呼ぶトピックの1つであるイングレスについて話しましょう。ユーザーがアプリケーションに安全にアクセスするにはどうすればよいでしょうか？おそらく何らかのファイアウォール機能が必要になるでしょう。最初のパターンは集中型で、一般的に多くのバリエーションがあります。主に2つのサブパターンを見かけます。1つはTransit Gatewayを使用するパターンです。この場合、集中型イングレスVPCにファイアウォールを配置し、インターネット向けのロードバランサーを設置し、場合によってはAWS WAFを使用します。そしてスポークVPCには、ワークロードと別のロードバランサーを配置します。もう1つのバリエーションは、Transit Gatewayの代わりにAWS PrivateLinkを使用するパターンです。
分離の観点からはこちらの方が優れており、コストも抑えられます。左右のVPCは実際に分離されており、特定のサービスに対する通信のみを指定します。 また、Load Balancerの前後にFirewallを配置することも可能で、それぞれに異なるメリットがあります。多くのお客様がこのアプローチを好む理由は、オンプレミスでの実装方法に似ているためです。これはDMZに似たアプローチで、 単一のアカウントで公開証明書を一元管理できますが、いくつかの欠点があります。 まず、アプリケーションごとに異なるニーズがあるにもかかわらず、すべてのアプリケーションがこの中央の場所に置かれることになり、これは合理的とは言えません。また、Firewallが検査のためにTLSを復号化し、再度暗号化する必要が生じる可能性があります。 さらに、スケーリングを行いたい場合は、Workload VPCに追加のLoad Balancerが必要になります。
このWorkload VPCでAuto Scalingを実現するためには、追加のNetwork Load Balancerが必要になり、 これによりコストが増加します。もう一つの選択肢として、分散型のIngressを実装することができます。この場合、各Workload VPCで、 インターネット向けのグローバルなApplication Load Balancerを作成します。ユーザーがインターネットからアプリケーションにアクセスできるようにしたい場合は、AWS WAFを追加できます。 多層防御のためにFirewallを追加することも可能です。また、キャッシングとエッジでの追加保護のために、Amazon CloudFrontのようなCDNを追加することもできます。 さらに、DDoS対策としてAWS Shieldを追加することができます。
これは費用対効果の高いソリューションです。一般的に、私たちは強く 分散型Ingressを推奨しています。アプリケーション固有の設定がすべて一箇所にまとまるためです。また、影響範囲が限定される ため、設定ミスがあっても他のアプリケーションには影響しません。AWS WAFを使用して Webアプリケーションを保護でき、多層防御のためにFirewallを追加することもできます。ただし、これらの異なるアカウントや VPCすべてにおいて、コンプライアンスとガバナンスを満たすための自動化について検討する必要があります。
ここで重要なポイントをまとめましょう。Egressについては、集中型と分散型の両方のアプローチが有効です。 IPv6の場合は、ProxyやNAT66ソリューションを避けるため、分散型Egressを使用することをお勧めします。Ingressについては、 分散型を推奨します。Web攻撃からの保護にはAWS WAFを使用できます。追加の保護には AWS Network Firewallを使用できます。キャッシングとエッジでの保護にはAmazon CloudFrontのようなCDNを使用でき、DDoS対策にはAWS Shieldを使用できます。
VPC設計の考慮事項とInfrastructure as Codeの活用
今日カバーしたこれらの情報を活用して、VPCの設計と考慮すべき点に立ち返りましょう。まず、使用するAvailability Zoneの数を決定することから始めます。次に、ルーティングパターンを特定し、 Firewallルールのために異なるWorkloadやインスタンスをどのようにグループ化するかを検討します。各Subnetで必要なIPアドレスの数を理解し、 成長の余地を残して記録することが重要です。異なるWorkloadには異なるサイジングニーズがあるかもしれません。Containerを使用する場合は、数千の Network Interfaceが必要になる可能性があり、そのVPCはより大きくなります。IPv6の場合、IPプランニングは より簡単で、ほとんどのSubnetがスラッシュ64になります。VPCのサイジングに関する考慮事項については、 ドキュメントページで確認することをお勧めします。
このインフラストラクチャを大規模に実装する場合、インフラストラクチャのパターンやテンプレートを作成するために Infrastructure as Code ツールを使用することをお勧めします。以下は、インフラストラクチャコードのスタック分離を実現する方法の例です。 IPAM のスコープとプールのためのスタックを用意することができます。AWS Cloud WAN や AWS Transit Gateway インフラストラクチャ用のスタックを用意することもできます。 Route 53 Profile を使用したDNS設定のために、異なるリージョン用のモジュールとスタックを作成できます。 集中型の送信トラフィック共有サービスを独自のモジュールとして持つことができる、特殊なVPCのためのモジュールを用意できます。VPCサブネット、ルートテーブル、インターネットゲートウェイ、フローログ設定などを組み合わせて、すべての設計上の決定を取り込んだワークロードVPC用のモジュールを作成することをお勧めします。Route 53 Profile の関連付けや Transit Gateway Cloud WAN アタッチメントの作成も追加できます。最後に、 インスタンス、ロードバランサー、セキュリティグループを含むアプリケーション自体のためのスタックを用意する必要があります。
Arm社のAWSネットワーキング実装事例
それでは、Arm社のAWSにおけるネットワーキングの取り組みについて、Radekからお話を伺いましょう。 私が一緒に仕事をしているエンジニアたちは、現代において最も成功している製品の1つを開発しています - 現在、人類の70%が使用しているArm アーキテクチャ製品です。私の役割は、AWSのサービスを活用してソリューションに組み込み、これらのソリューションから複雑な環境を構築し、エンジニアたちの業務をサポートするためにこれらの環境を共有することです。皆様、私の名前は Radek Podedworny で、Director of Engineering Platform Architecture を務めています。
これから15分間、クラウドへの journey についてご説明させていただきます。Armが6年前に始めたクラウドへの journey についてお話しさせていただきます。私たちが採用したサービス、開発したソリューション、そして私たちが下した決断 - この journey の始まりの時点で目指していた場所に、まさに到達することを可能にした決断についてお話しします。最初から、私たちはマルチリージョン、マルチアカウント環境でAWSを利用することを知っていました。私たちは、完全メッシュ構成の地域別Transit Gatewayをベースにバックボーンを構築しました。この場合、リージョンAとリージョンB間のトラフィックは常に最短経路を使用し、必ず2つのTransit Gatewayを経由します。
クラウドへのワークロードの移行が進むにつれて、クラウド外、主に自社のデータセンターにある依存関係がより多く見つかりました。データセンターとクラウドの間にセキュアな接続を構築することが自然な解決策でした。これを、地域別Transit Gatewayで終端する複数のSite-to-Site VPNとして実現しました。これは非常にうまく機能しましたが、皆様の会社でも経験されているかもしれない興味深い課題を生み出しました。私たちには2つのチームがありました：企業全体のネットワークを担当するネットワーキングチームと、クラウドとネットワーキングのスキルを持つクラウドチームです。
これらのチーム間に境界線を引くために、オンプレミスで使用していたアプライアンスを仮想化し、クラウドにデプロイしました。Site-to-Site VPN接続を構築しました - 仮想アプライアンスとデータセンター間の1つのグループと、仮想アプライアンスとTransit Gateway間の別のグループです。これは機能しましたが、特に仮想アプライアンスにおいてパフォーマンスの問題を引き起こしました。両方のVPNセットを置き換える解決策を見つける必要がありました。最初のVPNは Transit Gateway Connect アタッチメントに置き換えられ、2番目のVPNグループはAWS Direct Connectに置き換えられ、最初の1年間はデータ転送の媒体として使用されました。
1年後、私たちはこのシステムを改良し、パートナーの1社がSD-WANソリューションを提供するための基盤として活用しました。そして今、私たちは再びAWS環境に焦点を当てています。現在、マルチトランジットゲートウェイのシナリオの後継となる AWS Cloud WAN を実装しており、 これによってコードを使用してネットワークを構築できるようになり、自動化を推進する上で非常に有用です。
インフラストラクチャーの作業を始める前に、 まずIPv4とIPv6のIPアドレス計画を立てました。IPv4は当初から計画されていましたが、IPv6は2年後に計画され、要件がどのように変化したかをご覧いただけます。IPv4については、4つの主要リージョンでの展開、各リージョンで100以上のVPCに対応できること、そして2つのAvailability Zoneにまたがる高可用性を実現することを目指しました。VPCごとに/24を使用することを検討の出発点としました。その結果、/15を取得し、リージョンごとに4つの/17に分割しました。 各リージョン内では、/17をVPCごとに128個の/24に分割し、各/24は更にAvailability Zoneごとに2つの/25に分割しました。
2年後、IPv6の実装を決定しましたが、要件は完全に 異なるものでした。もはや4つのリージョンだけでなく、16のリージョンの使用を目指しました。100ではなく4,000のVPCを目標とし、リージョンによって数が異なることを認識した上で、すべてのAvailability Zoneを活用したいと考えました。その結果、/25のIPv6アドレス空間を取得しました。 この/25から、AWS専用の/42を取得し、これを16個の/36にリージョンごとに分割しました。各/36はアカウントごとに4,096個の/48に分割され、各/48はVPCごとに256個の/56に分割され、各VPCはサブネットごとに256個の/64に分割されました。
IPアドレッシングは一つの側面ですが、もう一つの 重要な側面は、私たちのお客様、パートナー、エンジニアが利用しているアカウントの構成です。これらは様々なプロジェクトで実装されているシステムです。
エンジニアと議論した各プロジェクトは、ネットワークアーキテクチャに関する固有の要件を持つユニークなものでした。しかし、運用の観点から、現在および将来のプロジェクトで共有できるテンプレートの提供を目指しました。私たちは3つのパターンを開発し、これらをフレーバーと呼んでいます。最初のパターンはArmからのフルテーブルで、特別なものではなく、データセンターからの比較的小規模な/24フルテーブルを持つ1つのVPCです。
2番目のパターンは、2つのCIDRを持つ部分的なVPCです。1つはArmからの比較的小規模なフルテーブルで、もう1つはAWSのクォータによって制限された大規模なCIDRで、VPC内でのみ可視化されます。これは、VPC外からの直接接続を必要としないノードに多くのIPアドレスを必要とする、私たちのハイパフォーマンスコンピューティングのニーズに完璧に対応しています。
3番目のパターンは特に興味深く、ネットワーキングチームと実装したソリューションを再現したものです。リージョナルTransit Gateway専用の/17を持ち、そこからプロジェクトTransit Gateway専用の/20を取り出しました。プロジェクトチームは必要に応じてこのIPスペースを分割できます。ご覧のように、/21を使用する大規模なVPCを持つアカウントと、それぞれ/24を持つ3つのVPCを持つ別のアカウントがあります。さらに、VPC Peeringを使用して完全に異なるIPアドレスを持つ別のアカウントもあります。
先ほどDmitryが言及したように、ハイブリッドクラウドを考える際には、ハイブリッドDNSを避けて通ることはできません。私たちはインバウンドエンドポイントとRoute 53ルールについてAWSのベストプラクティスに従っていますが、さらに一歩進んで、ユーザーが必要に応じてDNSをカスタマイズできるようにしています。新しいスポークアカウントが作成されると、すべてのRoute 53ルールがそのアカウントと共有されます。アカウント内には、プライベートホストゾーンの作成を可能にするAWS Service Catalogプロダクトがあり、作成されたゾーンは自動的にハブアカウントに関連付けられます。その結果、新しく作成されたものを含むすべてのDNSゾーンは、単一のスポーク内だけでなく、AWS内のすべてのスポークおよびデータセンターからも解決可能になります。
クラウドジャーニーの中で、AWSサービスが特定の要件を直接満たせない状況に多く遭遇し、カスタムの自動化が必要になりました。その一例が、EC2インスタンスが破棄後もMACアドレスを保持する必要があるMAC保持です。これを解決するため、EC2インスタンスに自動的に着脱する独立したインターフェースを作成しました。この自動化は、Auto Scalingグループによる自動修復機能、インターフェース管理用のLambda関数、ソフトウェアデプロイメント用のAWS CodeDeployを使用して構築されました。これにより、適切なインターフェースとMACアドレスを持つ新しいEC2インスタンスの作成だけでなく、必要なソフトウェアのインストールまで、エンドツーエンドの自動化が実現されました。このアーキテクチャは、フロー番号7で拡張され、オブジェクトストアとCodeDeployの組み合わせをAWS CodePipelineでオーケストレーションすることで、既存のEC2インスタンスを破棄せずに更新できるようになりました。
これまでの議論をまとめるにあたり、古代ギリシャの哲学者Heraclitusの言葉を引用させていただきます：「大きな結果には大きな野心が必要である」。これに異論を唱える人はいないでしょう。私が付け加えたいのは、大きな結果を得るには、ビジョンと計画が必要だということです。ビジョンは何を達成しようとしているのかを示し、計画はそれをどのように達成するのかを示します。この計画が意思決定の指針となり、ビジョンで示された目標の達成に向けて進むことができるのです。
皆様、私は Radek Podedworny と申します。Director of Engineering Platform Architecture を務めております。本日はお越しいただき、ありがとうございます。
AWSネットワークアーキテクトの考え方とまとめ
では、AWS のネットワークアーキテクトとしての考え方について、これまでの内容をまとめていきましょう。まず、計画が重要です。アカウント構造や、VPC 構造の計画を立て、現在のニーズだけでなく、将来のニーズにも適切なサイズになっているか確認することが大切です。先ほど Arm の事例でお話ししたように、v4 から v6 までのわずか2年の間でも、彼らは考え方を見直す必要がありました。そういった変化に備えておく必要があります。AWS での展開を始めると、要件が変化することに気づくでしょう。しかも、その変化は予想以上に早いかもしれません。
IP アドレスと ASN 番号の計画を立て、可能な限りオーバーラップを避けましょう。IPv6 を使えば IP アドレスの重複を避けるのはずっと簡単になりますが、IPv4 の世界でも考慮する必要があります。重複は対処が難しく、事前に計画しておけば不要な複雑さを避けることができます。VPC 間の接続サービスについても計画を立てましょう。ほとんどのお客様は、Arm の事例で見たように、AWS Transit Gateway と AWS Cloud WAN を使用して大部分の接続を行います。ただし、先ほど説明した AWS PrivateLink や VPC Lattice のリソースエンドポイントなど、他のサービスについても覚えておくと良いでしょう。これらは、特に厄介な問題に遭遇したときに非常に便利なツールとなります。
オンプレミスのデータセンターがある場合は、そことの接続に関する要件を理解し、定義し、それに基づいて設計することが重要です。SLA や IPsec トンネル、AWS Direct Connect についてお話ししましたが、必要な接続を構築するためのツールは多数用意されています。SLA だけでなく、場所に関連する要因など、さまざまな要因があるかもしれません。しかし、じっくりと考えて、本当に何を目指して設計しているのかを確実に理解することが大切です。単に最高レベルの可用性を目指すのではなく、本当に必要なレベルを見極めましょう。
DNS については、特別なユースケースがない限り、Amazon Route 53 Resolver または VPC プラス2つのリゾルバーを使用してください。Route 53 は高い冗長性とスケーラビリティを備えており、そのために用意されているものです。Route 53 Resolver を使用する際は、Dmitry が説明した Route 53 Profiles が、デプロイメントの一貫性を保つ上で非常に役立ちます。運用の経験がある方なら分かると思いますが、システムの一貫性を保つことは、深夜2時に特定の VPC の特殊な設定について慌てふためくことを防ぐ上で非常に重要です。
AWSのセキュリティ機能について、十分に理解して計画を立てることが重要です。ただやみくもにすべてを適用するのではなく、よく考える必要があります。例えば、あちこちにFirewallを設置するというセキュリティグループのポリシーがあるかもしれません。しかし、セキュリティの観点から実際に何を達成しようとしているのかを考えてみてください。Deep Packet InspectionやIntrusion Detectionが本当に必要なのか、それとも単にGeo Blockingを避けたいだけなのか。セキュリティ戦略を立てる前に、そのレベルまで掘り下げて検討する必要があります。
最後に、Dmitryが説明した集中型と分散型のトラフィック検査パターンについて評価してください。これは一つのサイズですべてに対応できるものではありません。もしそうであれば、ゴールデンガイドとして既に提供されているはずです。re:Inventでは、他にもいくつかのセッションをお勧めします。このセッションの続編として、本日後半に開催されるNET301では、高度な設計と新機能について説明します。また、NET403ではPlanet-scaleのネットワーキングについて説明します。これらは非常に興味深いセッションですので、本日参加できない方は後ほど視聴することをお勧めします。
皆様、ご参加ありがとうございました。私はAndrew Grayです。DmitryとRadekと一緒に発表させていただきました。このあと外で質疑応答の時間を設けていますので、お気軽に声をかけてください。改めて、ご参加いただき、ありがとうございました。セッション終了後のアンケートへのご協力もよろしくお願いいたします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion