More than 1 year has passed since last update.

試験対策: AWS Certified Advanced Networking - SpecialtyのDesign and Implement Hybrid IT Network Architects at Sacleまとめ

AWS認定試験

Posted at 2021-12-05

試験対策: AWS Certified Advanced Networking - Specialtyの無料トレーニングをまとめました。

私個人の学習メモのため、記載粒度は私の理解に合わせて省略していることご了承ください。
原文が全て英語のため、誤訳、誤解釈はご了承ください。

Design and Implement Hybrid IT Network Architects at Sacle

Conectivity Options

大きく以下3つの接続オプションが存在することをおさえる。

Public Internet

パブリックIP、Elastic IP、インターネットのoutgoingの料金。

VPN

インターネットのoutgoing料金はVPNにも適用される。
IPSecの認証と暗号化。
AWSのマネージドVPNとEC2を利用したユーザー管理型のVPN。

AWS Direct Connect

AWSパートナーとなるネットワークキャリアが提供するダイレクトコネクト。
インターネットとのプライベート通信の分離、一貫性のあるネットワーク提供、グローバルな多拠点との接続。
※Sub-1Gbpsは、100Mbpsや500Mbpsといった帯域を指す。

プライベートな通信を実現するのに、料金の観点でVPNを選択するべきか、Sub-1GbpsのDirect Connectを選択するべきか、他の観点でも考慮した時に何を選択するべきなのか、について言及。

Types of VPN

VPNにはSite-to-site VPNとClient-to-site VPNが存在する。

Site-to-Site VPNのアーキテクチャパターン

アーキテクチャパターンとして二つ存在。

Virtual Private Gateway (VGW)がカスタマーとのVPN接続の終端となるケース。VGWはAWSが提供するマネージドサービス。
EC2上にVPNを終端するソフトウェアを準備し、それがカスタマーとのVPN接続を終端するケース。

VGWはIPsecのみをサポートしているため、GREやDM-VPNなど別プトロコルを利用してカスタマー拠点側と接続したい場合は2つ目のアーキテクチャパターンを選択する必要がある。

VGW

VGWに関する説明。

マルチAZで構成。
1VPCにつき、1VGWをアタッチ。
VPNとダイレクトコネクトに利用。
VPCに対してアタッチもデタッチも可能。アタッチは同一アカウントであり、かつ同一リージョンの必要あり。
プライベートAS番号を選択可能。(BGP利用時)

ルーティングテーブルのターゲットとしてVGWが選択されている場合、図のようにデータセンターの192.168.1.0/24のセグメントへのルートとなる。
またデータセンター側へのルートの準備は2パターン存在する。

BGPによりデータセンターからルーティングを受け取るパターン。この場合、PropagatedはYesとなる。
手動でルーティングテーブルを設定するパターン。この場合、　PropagatedはNoとなる。

VGWには2つのパブリックIPが準備されており、IPsec接続の冗長性を確保できるようになっている。

BGPによるルーティング制御

非対称ルーティングとならないようにBGPを設定する。
カスタマー拠点とAWS間はeBGPによる接続のため、ASパス長による優先度制御またはMEDを利用した優先度制御を使って冗長化を実現しながら非対称ルーティングとならないようにする。
※これはAWSサービスというよりネットワークのルーティング設計の話。

VGWによるcloudhub機能

一つのVGWに複数のカスタマー拠点がVPN接続されている場合、VGWをハブとし、カスタマー拠点をスポークのような形でカスタマー拠点間の通信が可能。

VGWの大事なことまとめ

VGWのIPsecは初期ネゴシエーションでイニシエーターにならない。そのため、VGWとVGW間でIPsecを張ることはできない。カスタマー拠点のIPsecを張るルーターから接続を開始する。
VGWが発したDPDの確認メッセージにカスタマー拠点側が3回続けて応答がない場合は、IPsecトンネルをクローズする。→カスタマー拠点側はDPDの設定は有効にする必要あり。
ルートベースもポリシーベースも対応しているが、ポリシーベースではトンネル一つにつきSAが一つしか作れない。→ポリシーで指定した1つのネットワーク空間だけ通信可能となることを考慮して設計。

VGWを使ったVPNでアクセスできるAWSリソースとそうでないもの

画像の通り。

※NLBとPrivateLinkは現在アクセスできるようだ。EFSについてもPrivateLinkに対応しているため、現在アクセスできないのはVPC DNP IPとAWS public IP rangeくらい？
https://aws.amazon.com/jp/about-aws/whats-new/2018/09/network-load-balancer-now-supports-aws-vpn/
https://aws.amazon.com/jp/about-aws/whats-new/2018/09/aws-privatelink-now-supports-access-over-aws-vpn/

モニタリングとコスト

モニタリング対象はトンネルの状態、トンネルのデータのin/out。
スループットは1.25Gbpsまで。
トンネル一つあたり0.05ドル/1時間。

EC2を利用したSite-to-site-VPN

VGWじゃ足りないという人はEC2で好きにやってくれという話。

EC2を用いたSite-to-site VPNのアーキテクチャ例。
カスタマー拠点側と通信したいEC2インスタンスがあるサブネットのルーティングには、VPNを終端するEC2のENIをネクストホップに指定する設定になる。
またこの場合、スループットは2〜2.5Gbpsが期待できるため、VGWより優位。
※プレイスメントグループの通信フローの設定次第で最大10Gbps, IGWでは最大5Gbps出るはずなのに、なぜ2〜2.5Gbpsなのかについて言及されており、これはEC2のソフトウェア処理がボトルネックとなっていると説明されている。

EC2を用いたVPNの注意点

EC2のヘルスチェックをすること。
BFDで高速なルートの切り替えを行うこと。
pingによるモニタリングを行うこと。
VPNコネクションは第二の代替経路を準備すること。
AWS側のルーティングテーブルの書き換えも必要なため、それも考慮すること。
※AWS MarketPlaceに上記一式をやってくれるやつがあるから探すとよい。

EC2を用いたVPNのまとめ。

EC2を用いたVPNにしかないメリット (VGWとの比較)

VPNを終端するEC2でNATも行えば、VGWではアクセスできないAWSサービスにカスタマー拠点側からアクセスできるという話。
※上記で触れたように現在、VGWでもほとんどのAWSサービスにアクセスできるため、あまりメリットとならない予感がしている。

水平スケーリング例A

垂直スケーリングはEC2インスタンスのスペックアップだが、水平スケーリングはEC2を横に並べる。垂直スケーリングを行っても、2-2.5Gbpsの上限は突破できないため、それを突破する例として図のようなスケーリング例が紹介される。

カスタマー拠点の通信先セグメントを2つに分けて、ルーティングによって通信経路を分散させる方法。ただし、特定のサーバに通信が偏ってしまった場合の管理は大変だよね、と投げかける。

水平スケーリング例B

例Aではカスタマー拠点側を分割していたが、例BではAWS側のインスタンスのサブネットを分割して通信を分散させる。ただし、例Aと同様に特定のインスタンスに通信が偏ったらどうするのと投げかけ。

水平スケーリングと終端例A

IPsecを終端するEC2インスタンスの手前に通信を分散させるEC2インスタンスを挟む例。
このEC2インスタンスが2-2.5Gbpsの壁にひっかからないか触れており、あくまで2-2.5GbpsはIPsecの暗号化と復号化を行うIPsecを終端させるインスタンスの話であって、この分散処理を行うEC2はその壁に引っかからないと説明している。
そのため、この終端例Aはあり。

水平スケーリングと終端例B

GREトンネルを張る例Bは、本来AWS内で利用できないマルチキャスト通信をカスタマー拠点に届けることが可能になる。

Client-to-site VPN

VGWは対応していない。EC2インスタンスを利用して実現する必要がある。

図ではシングルサブネットに収容しているがマルチAZを利用して可用性を高める。VPNソフトの機能やDNSを利用して負荷分散を実現することが大事。

VPNユースケースまとめ

IPsecならVGWを利用したマネージドVPN
IPsec以外ならEC2ベースのVPN
IDSやIPSといった手法でセキュリティを確保したいならEC2ベースのVPN ※マネージドVPNの間にコンポーネントを挟んでもいいのでは・・・
EC2間でL3で暗号化した通信をしたい場合はホスト間VPNを導入する。※ここまであまり話に出てない
ダイレクトコネクトはTLSを提供しないため、ダイレクトコネクト上でマネージドVPNを利用するケースもある
マルチキャストに対応したい場合はGREトンネルを終端同士で張る。

ダイレクトコネクト概要

カスタマー拠点との通信とインターネット通信を完全に分離できる
インターネットのアウトバウンドの料金よりDXの料金の方が安い。※とても強調している
インターネットは国をまたいだり、距離が長くなる場合に通信品質を保証できないがダイレクトコネクトは保証される
一つのダイレクトコネクト接続拠点からグローバル(あらゆるリージョン)のAWSインフラに接続できる

ダイレクトコネクトロケーション(DX location)は、AWSが所有しておらず、例としてEquinixのようなデータセンターサービスを提供する事業者によって準備されている。AWSとしてはダイレクトコネクトルータ(Direct Connect Router)を準備しているだけ。
Direct Connectを経由してVPCへの接続はもちろん、各リージョンのVPCには配置されないサービス(パブリックサービス)にも接続ができる。
ダイレクトコネクトロケーション内にカスタマー用のオンプレミスサーバを設置(Coloation)してもいいし、そこからネットワークを伸ばした自身のデータセンターにつないでもいい。

ダイレクトコネクトロケーション内にオンプレミスサーバを設置するパターン
AWSと事業パートナーを結ぶ通信キャリアがキャリアサービス内でダイレクトコネクト接続を提供するパターン
ダイレクトコネクトロケーションと自身のデータセンター間をVPNサービスで自身やサードパーティの提供者によって接続するパターン

AWSとしてはリクエストから72時間でダイレクトコネクトルータのポートと接続を提供するが、あくまで提供範囲はダイレクトコネクトルータまでであることを強調。

ダイレクトコネクトの始め方

1Gまたは10Gの専用ポートの利用。
- ポートの帯域を全て自身で利用できる。
- 複数のバーチャルインタフェースに対応。（パブリックとプライベート）
- 準備手続きはAWSマネジメントコンソールで承認の手紙をダウンロードするだけ。
sub-1G (50Mbps-500Mbps)のホストされた接続の利用。
- AWSパートナーネットワークによる提供。AWSパートナーがホストし、それをユーザーに分割して提供する。
- 各接続は帯域とVLANが決定されている。
- 各接続は一つのバーチャルインタフェースに対応(パブリックまたはプライベート）

ダイレクトコネクトの物理的接続仕様

1Gまたは10Gの専用線ポートを利用する場合はDX location内にてCross Connect (構内接続)を完了させる必要あり。
光ファイバーの接続 1000Base-LX (1G) または10GBase-LR (10GB) のどちらか。
接続機器はVLANは802.1qに対応、ルーティングはBGPに対応する必要あり。
BFDに対応していると望ましい。

BFDは必須ではないが障害時のフェールオーバーまで時間が大きくなってしまうことから推奨。

物理接続後のダイレクトコネクトの設定の始め方

VIFからはじめる。VIFにはプライベートとパブリックの2種類が存在。
プライベートVIFはVPCと接続する。VPCにVGWを準備しVIFを接続する。この場合、前述のVPNで話した1.25Gbpsの上限はない。
パブリックVIFはDynamoDBやKinesisといったパブリックサービスにネットワークの揺らぎなしにアクセスできる。
準備するASNは、プライベートでもパブリックでも利用可能だが、もちろんパブリックの場合は自身が所有している必要あり。
VIFが3つあるということは、VLANが3つ存在しているということ。

Direct Connect Gateway

Direct Connect Gatewayは任意のリージョンに接続することが可能。
ただしVPCへの接続のみに限定。パブリックVIFは利用不可。
前スライドではDirect Connectの一つのVIFがあるVPCのVGWへ直接接続をしていたが、図の通りDirect Connectの一つのVIFがDirect Connect Gatewayに接続される。それが各VPCのVGWがDirect Connect Gateway接続する。
VGWからDirect Connect Gatewayの接続は、Amazonのバックボーンを経由する。そのため、あるDirect Connect Gatewayに全く異なるリージョンのVPCが複数接続されていても気にする必要はない。※もちろん、オンプレミス拠点とリージョンが異なる場合は、一定の遅延などはある理解。

パブリックVIF

パブリックVIFにはパブリックIPアドレスが必要。
パブリックASNが必要。プライベートASNでもいい。ただしAS-PATH prependが利用できないため、経路の優先制御をしたい場合は注意。
パブリックVIFを通じて、BGPでAWSサービスのパブリックIPレンジが送られてくる。適切にルーティング情報をフィルタリングしよう。
SNSトピックで広報されるルーティング情報の変化をサブスクライブできるらしい。
BGPコミュニティ属性を使ってDirect Connect経由とするかインターネット経由とするか区別できる。

コミュニティ属性(タグ)により、AWSサービスのパブリックIPをどこまでDirect Connect経由にするか制御できる。
- Local AWS Region：自リージョン (Direct Connect Locationの？　）
- Local Continent: 自身の大陸のリージョン
- Global: 全て

VPC接続の通信の暗号化

プライベートVIFでは通信が暗号化できない。
通信を暗号化した接続は以下が必要。

AWSマネージドVPN(VGW)を利用する場合はパブリックVIFを選択することで実現できる。
EC2によるVPNアプライアンスを利用すれば、プライベートVIFでもパブリックVIFでもどちらでも実現できる。

DX＋VGWを利用した暗号化通信の実現

プライベートVIFによるDX接続は暗号化できないが、図のようにパブリックVIF接続によりDX＋暗号化の通信が可能になる。
VGWの接続エンドポイントのグローバルIPアドレスはDynamoDBやS3などその他サービスと同様にパブリックVIFによって拠点側に広報されるため、そのグローバルIPアドレスにたいしてカスタマー拠点のルーターがVPNを張ることでDX上に暗号化通信を実現できる。

DX+EC2を用いたVPNによる暗号化通信の実現

プライベートVIFを経由してVPC上のEC2インスタンスとカスタマー拠点のルーター間でVPNを張ればよい。
ただしVPNを張っても張らなくてもVPCのセグメント情報を経路情報としてカスタマー拠点に広報すれば通信できてしまい、VPNトンネルを経由する通信としない通信の二つの経路が存在することになる。これは問題を引き起こす原因になりかねないため、望ましくない。

パブリックVIFであれば、上記のVGWと同様にElastic IPアドレスが広報されるためEC2を用いたVPN接続をグローバルIPアドレスを使って確立できる。これは上記のプライベートVIFのような懸念を引き起こさない。

複数AWSアカウントをまたいだVPC接続

一つのDirectConnect Gatewayでアカウント跨ぎの接続は不可。

上記のように異なるDirectConnect Gatewayをもう一つ準備する必要がある。
ダイレクトコネクトは追加する必要はなく、プライベートVIFを追加し、もう一つのDirectConnect Gatewayと接続をすればよい。

VPCピアリングとDirectConnect

上図のようにVPC1とVPC2がVPCピアリングで接続しており、VPC1はDirectConnect Gatewayで接続している。この場合にVPC2のサーバにカスタマーのオンプレミス拠点からは接続できない。

実現するにはVPC2にもDirectConnect Gatewayで接続させる必要がある。
DirectConnect Gatewayを経由したVPC間の通信はできない。ただし、カスタマー拠点を折り返しポイントとしたVPC1とVPC2間の通信は実現しようと思えば可能。

LAG

LACPを使えば複数の物理リンクを論理的に一本の回線にまとめることが可能。
1Gbpsと10Gbpsに対応。まとめる物理リンクは全て同じ帯域である必要がある。
最大4つの接続をLAGにまとめることが可能。
LAGを構成する接続は必ず同じダイレクトコネクトのロケーションでかつ同じエンドポイントとなるデバイスに全て終端する必要がある。

BGPの最大マルチパス数を2以上に設定し、Active/Activeの等コストロードバランスを構成する必要あり。
ポートは同一シャーシに存在する必要あり。
LAGを維持するのに必要な有効な接続数は最小に設定する。（例：4本でLAGを組んだ場合に2本ダウンしたら、残りの2本でLAGを維持するか、維持せずLAGを解散し、4本の別接続とするか)
LAGに追加費用なし。

ネットワークの柔軟性

上記のような構成を考えた際に、ルーティングの優先順序はどのように制御されるのかを考える。

上図の例で言うと、DirectConenct Gateway (またはVGW) -カスタマールータ間のルーティング情報の制御にあたる(はず)
VGWが受けるルーティング情報は、

プレフィクスのロンゲストマッチで優先順位が決められる
BGPのAPパス長、そしてLocal Preferenceで優先順位が決められる。(iBGP区間の動作)
※BGPのmultipathによるロードバランシングは同一のDX Loationである必要があるため、上の図では当てはまらない。

VPC内のルーティングの優先制御の話。以下は優先順。

VPC内ローカルのアドレス宛のルート
ロンゲストマッチによるルート
静的ルート
動的ルート
- DXのBGPルート
- VPN(IPsec等)の静的ルート
- VPN(IPsec等)の動的なルート

VPN(IPsec等)の静的ルートとは、おそらく以下。site-to-site-VPNの編集画面でVPN接続先のセグメント情報を入力すると、それをVPCのルーティングテーブルに広報してくれるもの。
https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/vpn-edit-static-routes.html

BGP内のルーティングの優先順位は画像の通り。

請求

DX

ポート/時間単位の課金。スタンバイとしていてもかかる。
AWSからのアウトバウンドのデータ転送のみに課金。
DX上にVPNを張ったデータ転送もインターネット経由のVPNに比べて課金に割引が効く。
データ転送料はVGWまたはDirectConnect Gatewayを所有するアカウントに課金する。※DirectConnectがセットアップされているアカウントとそれらが異なる場合にはこの区分けに注意が必要。

Public VIF

上記のDX同様に割引された転送料が適用される。
自身のリソースへのアクセスの転送料は、自身への支払い。
請求が統合されたアカウント内のリソースへのアクセスの転送料は、自身への支払い。
他人へのリソースへの転送料は、他人の支払い。

※上記の割引とは、インターネットと比べて？と思われる。

VPC Peering

VPC Bから図への各リソースへのアクセスを考えた際に、VPC A以外へはどこへもアクセスできない。
これはVPC Peeringの仕様上そのようになっている。

「VPCにパケットが流れるときに、宛先または送信元どちらかはそのVPCのセグメント内のアドレスとなっていなければ通信は成立しない仕様」

この仕様により、上図の構成ではAWS Managed VPN経由のデータセンター拠点はVPC A以外とは通信不可。

ただし、AWS Managed VPNではなくDXの場合は少し状況が変わる。DXが接続するInterface VPC endpointと通信が可能。

Proxyを用いた解決策

図のようにProxyをセットしたVPCを挟めば、カスタマー拠点からピアリングしたVPCやAWSサービスにアクセスは可能。
Proxyを挟むことで通信がProxyのVPCで一旦終端するため。

※動画では2例Practiceが紹介されたが省略。

VPNを用いた解決策

VPC A,B,CがVPC Peeringで繋がっており、VPC BにVPN接続用EC2インスタンスをたて、それぞれのVGWとIPsecで繋げば、VPC AからVPC Cへ通信が可能になる。

※VPN区間はトンネル用のIPヘッダでカプセリングされるため？
VPC AからVPC Cへ通信する際に・・・
VPC AからVPC Bへ渡ってきたカプセリングされたパケットはEC2インスタンス内でカプセリングが解除され、それがAWSのサブネットにさらされることなく、EC2内で再度VPC BからVPC Cへ渡すためのカプセリングがされてVPC Cへ渡るためと思われる。

Transit VPC

顧客の心配事

レイヤー4レベルではSecurityGroup等によってAWSのサービス内で実現できるが、IDSやIPS、アプリケーションファイアウォールのようなレイヤー7のセキュリティ検査を入れたい場合はどうするべきか。
上図のようにVPCが増えるごとに検査インスタンスを導入するのは得策ではない。そこで・・・

上図みたいにできると理想に近づけるよね、という話。

ただし、上述のVPC Peeringで触れたようにトランジットなルーティングはAWSではサポートされていないし
VPCとリモート拠点のIPアドレスの重複も気になるし
トランジットなVPCをつなげつようと思ったらケースによっては大量のVPNが必要になるし

気になることが多いよねという話。

Transit VPC

Transit VPCは、複数VPCやカスタマーのオンプレミス拠点を接続するためのハブVPCを準備すること。
VPNを張るEC2インスタンスはペアで準備し冗長性を確保する。

Transit VPCのケース例

カスタマーのオンプレミス拠点から複数のVPCに対してVPNを張る際に、必要なVPN数を削減する。
- DirectConnect Gatewayを使えば削減可能、ただし複数AWSアカウントへ接続が必要な場合・・・は、アカウント数分だけDirectConnect Gatewayが必要になる。
Transit VPCにセキュリティポイントを設ける。
カスタマーのオンプレミス拠点とVPCとのIPアドレスの重複はTransit VPCでNATを利用して調整する。

Transit VPCのアーキテクチャ例

中央にあるのがTransit VPCとなり、各拠点、VPC、サービスと繋がりハブとなっている。

その中でも右下のDirectConnect接続しているDetached VGWが少し特殊。
VGWは本来、VPCに接続して利用するが、VPCに属せず、DirectConnectのVIFを受けつつVPNを張る受け口になることが可能。
そのため、Transit VPCのEC2とのVPNとDirectConnectをつなぐ役割となることができている。

Transit VPCの大事な点

VPNを張るEC2インスタンスはペアで用意し冗長性を確保する。
BGPをVGWとEC2インスタンス間で利用し、フェールオーバー時のルーティングの切り替えを行う。
BFD,DPD,BGPタイマーを利用してフェールオーバーのリカパリ時間を短縮する。
CloudFormationやLambdaを用いて、スポークとなるVPCが追加された場合は自動でVPNが張られてTransit VPCに参加するように設定する。
オープンソースやサードパーティベンダーのVPNソフトをTransit VPCに利用する。

Transit VPCアーキテクチャ検討例1

Transit VPCとスポークVPCを繋ぐ手段として、VGWを用いるべきか、EC2インスタンスを用いるべきかの検討について考える。

VGWを利用する場合、
マネージドのため冗長性の確保を意識しなくていいのがメリット。ただし、インターネット経由となる点を許容できるかどうか。(IPsecで暗号化されているとはいえ)
EC2インスタンスを用いれば、VPC Peeringを経路として接続できるが、冗長性の確保は自身で考える必要がある。あとIPsec以外のトンネルも利用できることになる。

Transit VPCアーキテクチャ検討例2

二つのVPCを接続するとき、Transit VPCを使ってつなぐべきか、VPC Peeringを使ってつなぐべきかの検討について考える。

二つのVPCがTrustedの扱いであれば、その間にセキュリティの検査やフィルタは不要なのでVPC peeringでつなげばよい。
片方のVPCがUntrustedの場合は、Transit VPCでセキュリティ検査をする機能を挟んでTransit VPC経由で通信をさせる。
Transit VPCとVPC peeringが同居する場合、2つのルートが存在することになるが、VPC peeringは静的ルートのため、こちらがルーティングで優先される。

Transit VPCアーキテクチャ検討例3

カスタマーのオンプレミス拠点とVPCを接続するとき、Transit VPCを使って繋ぐべきか、DirectConnect Gatewayを使って繋ぐべきかの検討について考える。

検討例2と同様で、互いにTrustedか片方がUntrustedで選択する。

互いにTrsutedであれば、DirectConnect Gatewayを選択する。
Transit VPCとDirectConnect Gatewayが同居する場合、2つのルートが存在することになるが、DirectConnect Gatewayの方がBGPのASパス長が短いため、こちらのルートが優先される。