プログラマでありたい

おっさんになっても、プログラマでありつづけたい

AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版が販売開始します

 AWS認定ソリューションアーキテクト アソシエイトの試験対策本であるAWS認定資格試験テキストの改訂版を執筆し2021年1月21日に販売開始することになりました。執筆作業が大幅に遅れ、旧版が長らく在庫切れ状態、新版が出てこないという状態でした非常にご迷惑をお掛けしました。

改訂の方針

 今回の改訂の方針としては、基本的には第一版をベースにしています。試験範囲の差分については目次レベルで加筆、機能が更新されたものについては修正しています。汚い字で恐縮ですが、目次レベルで確認の上で本文の情報を一つ一つ確認していくという形をとっています。外出時の隙間時間での作業が多かったので、傍目にはめっちゃ熱心に勉強している人に見えたかもしれません。

f:id:dkfj:20210120012059j:plain

 Amazonのレビューを見ていると、試験問題について簡単過ぎるというコメントが多かったです。個人的には練習問題なので認定試験特有の枝葉の情報を除いて、AWSの機能の部分を問うていたつもりです。なので、難易度は関係ないかなぁと思っております。一方で、コメントに対応する形で、少し難易度を高めた問題も増やしています。きっと満足いただけると信じています

2色刷りに変更

 これは著者の努力の反映ではないのですが、今回は 2色刷りに変更しています。読み比べてみると、見やすくていいなぁと思います。やっぱり視覚に訴えるのも大事ですね!!

https://m.media-amazon.com/images/S/aplus-media/vc/50d8d51c-1820-4138-a405-a490d949763e.__CR0,0,970,600_PT0_SX970_V1___.png

その他の改修ポイント

改定前のAWS認定試験との分野の違いを解説

 今回、SAAの試験はSAA-C02というコードになっています。実はこれ試験の分野が一部修正されていて、オペレーションに関する部分が分野として消えています。それがどのような変化になっているかの解説もしています。SAA-C01で合格した人で、そろそろ試験の更新という人も出てくると思います。そういった人へのガイドにもなるように心がけております

コラムの充実

 編集上の都合で空白になる部分が出てきます。そういった所については、今回コラムを掲載しています。AWS認定試験に関する今後の方向性の考察や或いはポエミーな内容までいろいろ書いています。息抜きになっていいと思うので、是非読んでみてください。

まとめ

 改訂版の紹介ってしにくいなぁと思いながら書きました。イマイチ筆が乗らなかったので、別途AWS認定ソリューションアーキテクト アソシエイトの勉強の仕方というテーマで書いてみようと思います。前回の出版から2年も経たずに改訂が必要という著者泣かせな部分がありますが、試験をどんどん進化させていくというAWSの姿勢は素晴らしいと思います。この本が、AWSの世界に入っていく際の道標の一つになることを願っています。

目次

以下、目次です。目次としては、結果的に大きく変わっていないかも

第1章 AWS認定資格
1-1 AWS認定試験の概要
1-2 学習教材
1-3 学習の進め方
1-4 何に重きをおいて学習すべきか

第2章 グローバルインフラストラクチャとネットワーク
2-1 リージョンとアベイラビリティゾーン
2-2 VPC

第3章 ネットワーキングとコンテンツ配信
3-1 CloudFront
3-2 Route 53

第4章 コンピューティングサービス
4-1 AWSにおけるコンピューティングサービス
4-2 EC2
4-3 ELB
4-4 ECS
4-5 Lambda

第5章 運用支援サービス
5-1 AWSにおける運用支援サービス
5-2 CloudWatch
5-3 CloudTrail

第6章 ストレージサービス
6-1 AWSのストレージサービス
6-2 EBS
6-3 EFS
6-4 S3
6-5 S3 Glacier
6-6 Storage Gateway
6-7 FSx

第7章 データベースサービス
7-1 AWSのデータベースサービス
7-2 RDS
7-3 Redshift
7-4 DynamoDB
7-5 ElastiCache
7-6 その他のデータベース

第8章 セキュリティとアイデンティティ
8-1 セキュリティとアイデンティティ
8-2 KMSとCloudHSM
8-3 AWS Certificate Manager

第9章 アプリケーションサービス
9-1 AWSのアプリケーションサービス
9-2 SQS
9-3 SWFとStep Functions
9-4 SNSとSES

第10章 開発者ツール
10-1 AWSにおける継続的なアプリケーション開発の支援サービス
10-2 CodeCommit
10-3 CodeBuild
10-4 CodeDeploy
10-5 CodePipeline

第11章 プロビジョニングサービス
11-1 AWSにおけるプロビジョニングサービス
11-2 Elastic Beanstalk
11-3 OpsWorks
11-4 CloudFormation

第12章 分析サービス
12-1 EMR
12-2 ETLツール
12-3 その他の分析サービス

第13章 AWSのアーキテクチャ設計
13-1 AWSにおけるアーキテクチャ設計
13-2 回復性の高いアーキテクチャ
13-3 パフォーマンスに優れたアーキテクチャ
13-4 セキュアなアプリケーションおよびアーキテクチャ
13-5 コスト最適化アーキテクチャ
13-6 オペレーショナルエクセレンスを備えたアーキテクチャ

第14章 問題の解き方と模擬試験
14-1 問題の解き方
14-2 模擬試験
14-3 模擬試験の解答

AWS認定 高度なネットワーキング(アドバンストネットワーク)専門知識に合格しました

 AWS認定資格12冠(コンプリート)に向けて、個人的な最大の関門であったAWS認定 高度なネットワーキング(アドバンストネットワーク)専門知識に合格しました!!得意じゃない分野だったので、嬉しいです!!ということで、受験体験記を残しておきます。試験内容についての言及は、NDAで禁止されているのでどういった勉強したかを中心です。

合格までの道のり

 実はアドバンストネットワークは、一度落ちています。2019年12月の年末に、準備不足のまま受験して見事に玉砕しています。その後、リベンジしようと思いつつコロナ禍の影響や、何となく面倒くさくなったまま1年以上経ってしまっていました。夏くらいに一度申し込んだものの、急な用事で受けられず延期しその後キャンセルとなりました。今回も2回延期の末にようやくの受験です。さっさと受けろよと我ながら思います。

勉強の準備

 まずは試験範囲を確認するのが最重要と思い、AWS公式のExam Readinessのデジタル講座を受講しました。
Exam Readiness: AWS Certified Advanced Networking - Specialty (Digital)
www.aws.training

 これオンラインで無料で受けられるのですが、めちゃくちゃ長いです。なんと合計9時間近く。試験範囲のところの目次も作っておきたかったので、聞いたり止めたり少し巻き戻したりと、なんだかんだで1.5倍くらいの時間が掛かったと思います。さらに、これモジュールの途中から再生という機能がないのですよね。この辺りは改善して欲しいなぁと思います。目次はこんな感じでまとめています。勉強の方針を決める上で重宝しています。

f:id:dkfj:20210120010437p:plain

 ちなみにNetworkについては、日本語字幕付きにはなっていないです。そのうち字幕付きのものも出てくるといいなぁと思います。そして書いていて思い出したのですが、日本のSA陣による試験準備の動画コンテンツがありました。散歩中にTwitterでみて、家帰って見ようと思いつつ忘れていたことを今思い出しました。
※まだ見ていないです。ごめんなさい

pages.awscloud.com

重点的に勉強したところ

 自分の中の知識として、Direct Connectに関するものが圧倒的に不足していると自覚がありました。なので、そこを重点的にすることにしました。が、昔から試験勉強は苦手なので、ブログを書きながら整理するというスタイルを取っています。そのために書いたのが、Direct Connect 5部作です。誰かDirect Connectの薄い本を書いてくれないですかねぇ?

AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その2 プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その3 パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その4 Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その5 経路選択と冗長化 - プログラマでありたい

 また夏頃に、AWS認定ソリューションアーキテクトの改訂作業があり、その際に加筆のためにELBの整理を改めてしていました。そこも結果的に役に立っていたのかなぁという気がします。

AWSのAutoScalingの整理 スケーリングポリシー編 - プログラマでありたい
AWSのAutoScalingの整理 猶予期間・ウォームアップ・終了ポリシー編 - プログラマでありたい

 またもう少し知識を整理しようと思っていたサービスとして、Route53があります。今回は時間が足りずブログは書いていませんが、どこかのタイミングでまとめてみたいなぁと思います。

まとめ

 果たしてこの勉強の仕方は他人にとって役に立つのか、非常に疑問ではあります。が、今回、ものすごく真面目に試験対策しましたので、書き記しておきます。動画を見るのに12〜13時間くらい。Direct Connectの勉強に10時間くらい費やしました。いやー、苦労しました。次は2月初旬にデータベースを、下旬にはAlexaを取ろうと思っています。
 ちなみに、AWSの試験対策本として下記のような本がありますよというステマで締めさせて頂きます

AWS Direct Connectの勉強その5 経路選択と冗長化

 AWS認定アドバンストネットワーク(高度なネットワーキング)のために、苦手なDirect Connectの勉強をしよう。勉強するならブログにまとめようと軽い気持ちで始めたこのシリーズですが、いよいよ第5回目、最終回を迎えることになりました。

AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その2 プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その3 パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その4 Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その5 経路選択と冗長化 - プログラマでありたい

AWSとオンプレミス間の経路選択について

 AWSとオンプレミス間でDirect Connectで接続する場合、回線が1本の場合はそれが単一障害点となります。そのため、複数の回線を利用して冗長化するのが望ましいです。その場合、どの経路を通って通信するかという経路選択が必要になります。Direct Connectの場合(たぶんDirect Connect以外の専用線接続の場合でも)、BGPを使って経路をコントロールします。
 ということで、今日はみんな大好き(さっぱり解らない)BGPを中心としたAWSとオンプレミス拠点の接続の制御という観点でみていきます。まずBGPの基本として、同一AS内ではiBGP(Internal BGP)で異なるASとはeBGP(External BGP)で経路の制御をします。

f:id:dkfj:20210111224323p:plain

 経路の制御として、2つの値があります。

  • オンプレミス⇒AWS: Local Preference(LP)
  • AWS⇒オンプレミス: AS Path Prepend

 これ以外にも、MEDがあります。MEDによって優先度の制御はできるが、AWSとしてはサポートの対象外のようです。さて、この2つの設定値ですが、オンプレミス側のルーターで設定を行います。AWS側は一切設定しません。AWS側での設定が無いと初めて知った時は、へぇーって思いました。
※AS番号の設定等はしますが、経路選択に直接影響を与える訳ではないです。

経路選択

 では、実際の経路選択の例を見てみましょう。次の図は、2つのカスタマーゲートウェイに接続していて、Active/Standbyになっている例です。VGWからオンプレの経路は、AS Path Prependのパス長をみます。Activeな左側のルーターは、Prependがなしです。Standbyになっている右側のルーターは、Prependが2つあります。AS Path Prependは最小の方を優先されるため、Prepend なしのルートが選択されます。オンプレからAWSのルートは、Local Preference(LP)をみます。LPは大きな値の方が優先されるため、左側の200が設定されているルーターが優先されます。よって、Active/Standby構成になります。

f:id:dkfj:20210112000558p:plain

 Active/Activeの構成にしたい場合は、AS Path PrependとLocal Preferenceの値をどちらのルーターも同じに設定すれば良いです。

f:id:dkfj:20210112000611p:plain

 AS Path PrependとLocal Preferenceの付け方を間違えると、上りと下りのトラフィックが別々の経路を通る(非対称ルート)ということになるので、注意が必要です。

f:id:dkfj:20210112000725p:plain

VGWの経路選択の優先度

仮想プライベートゲートウェイ(VGW)の経路選択の優先度は以下の仕様になっています。

  1. ロンゲストマッチを優先
  2. Direct ConnectとVPNで冗長化時は、Direct Connectを優先
  3. スタティックルートと動的ルーティングを同時利用時はスタティックルートが優先
  4. BGPのAS-PATH属性を適用
  5. 上記に当てはまらないまたは同じ場合はロードバランス(Act/Act構成)

Site-to-Site VPN routing options - AWS Site-to-Site VPN


 この中でロンゲストマッチ(最長プレフィックス一致)というのが解りにくいです。宛先が172.16.1.1というものがあった通信があり、172.16.1.0/24と172.16.0.0/16の2つのネットワークが広告されていた場合、ロンゲストマッチとしては172.16.1.0/24となります。

経路障害の検知

 経路の冗長化と通常時の経路選択ができるとして、それでは経路障害時はどのように検知するのでしょうか?AWSには、2種類の検知のための設定値があります。

  • keepalive/ Hold Timer
  • BFD(Bidirectional Forwarding Detection)

keepaliveとHold Timerは、数十秒単位で設定するようです。BFDはミリ秒での設定のようです。BFDを有効にした方が早く検知できますね。

CloudWatchのDirect Connectの監視可能項目

 最後にCloudWatchでDirect Connectの監視可能メトリクスです。CloudWatchでは物理的な回線であるコネクションと、論理的な接続であるVIFの監視が可能です。メトリクスについては、公式ページを参照してください

docs.aws.amazon.com

まとめ

 苦手なDirect Connectについて5回に渡ってまとめてみました。基本的な要素・機能・考え方については理解できたので、もう少しユースケースとか実際の設定を試してみて身につけていこうと思います。こんな事も知っておいた方が良いよということがありましたら、是非教えて下さい。

AWS Direct Connectの勉強その4 Direct Connect GatewayとTransit Gateway

AWS認定アドバンストネットワークのための、Direct Connectの勉強シリーズです。今回で、第4回目。ようやくDirect Connect Gatewayにたどり着けました。

AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その2 プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その3 パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その4 Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その5 経路選択と冗長化 - プログラマでありたい

Direct Connect Gatewayとは?

 Direct Connect Gatewayは、単一のPrivate VIFを利用して中国を除く世界の全リージョンの複数のVPCに接続するためのサービスです。これまでのDirect Connectの解説で、Private VIFは同一リージョンの一つのVGWしか接続できず、Public VIFは中国を除く全リージョンに接続できるがパブリックIPのサービスなのでVPWには接続できないという説明をしてきました。Direct Connect Gatewayを利用することで、単一のPrivate VIFで自リージョン以外のVPC含め、複数のVPCと接続できるようになりました。また、サービス発表当初は、同一AWSアカウントのみの接続可能でしたが、2019年10月のサービスアップデートで別AWSアカウントにも接続できるようになりました。


f:id:dkfj:20210111194244p:plain

 Direct Connect Gatwayは、利用にあたって追加の費用は発生しません。将来的な拡張性を考えると、Direct Connectの当面の接続先が1つの場合でも、Direct Connect Gatewayを挟んでおいた方がよいのではないでしょうか。

Direct Connect Gatewayの通信の制約

 とっても便利なDirect Connect Gatewayですが、幾つかの制約があります。その中で大きいものは、折返しの通信ができないということです。折返しの通信とは、例えばオンプレミスを経由しないVPC間の通信や、逆にオンプレミス間の通信です。

f:id:dkfj:20210111194823p:plain

 これ以外に接続するVPCが最大10までと、思ったより少ないというのがあります。管理している大量のVPCを管理するのに良さそうに見えますが、Direct Connect Gatewayはそういうサービスではないのです。そういう用途として、Transit Gatewayというサービスが用意されています。

Transit Gateway

 Transit Gatewayは、ハブ型のネットワークを構築できるサービスです。AWSの様々なネットワークサービスに接続可能で、VPC以外にDirect Connect Gatewayやオンプレミス拠点とのVPN接続などが可能です。接続可能なVPCは、最大5,000と非常に多いです。一方で、Direct Connect Gatewayと違ってリージョナルサービスです。つまり東京リージョンで作成したら、東京リージョン内のリソースとのみ接続可能です。

f:id:dkfj:20210111205841p:plain

 あとちょっと不思議な事に、VPC間の接続をVGWではなくTransit GatewayとAZごとに作成されたENIを通じて通信をします。

Transit GatewayとDirect Connect Gatewayの組み合わせ

 Transit Gatewayの発表当初はできなかったのですが、今だとTransit GatewayとDirect Connect Gatewayを組み合わせて利用することができます。

f:id:dkfj:20210111210724p:plain

 Transit Gatewayは、Direct Connect Gatewayと接続することが可能です。この際には、パブリックVIFでもプライベートVIFでもなく、Transit VIFという特別なVIFを使います。このTransit VIFは、Connectionにつき1つしか作れないという制約があります。このため、Connectionを複数で共有する共有型Direct Connectでは使いにくいという問題があります。これを解決するために、Private Link等を活用した様々なデザインパターンがありますが、ここでは割愛します。

AWS VPN CloudHub

 Transit Gatewayを紹介したついでに、もうひとつのハブ型のネットワークである AWS VPN CloudHubを紹介します。これ概念としては聞いた事があるのですが、実際に構築したこともありません。Transit Gatewayが出た今となっては、たぶん構築することもないと思います。AWS側のVPCをハブとして、複数の拠点をVPNで接続するのがVPN CloudHubです。といっても、特別なサービスがある訳でもなく、通常のVPNでBGPを使って相互に経路を広告しあうという構成のようです。

f:id:dkfj:20210111213136p:plain

AWSの下記のページより拝借
VPN CloudHub を使用して安全なサイト間通信を提供する - AWS Site-to-Site VPN

まとめ

 長い長いDirect Connectの説明を経て、ようやくDirect Connect GatewayとTransit Gatewayの触りの部分を説明できました。サービスの進化の順番に学びなおしたので、何が足りなかったので新しいサービスが出てきたのかが理解しやすかったです。次は、Direct Connect等を利用した経路の制御や冗長化の話です。苦手なBGP等がどっさりと出てくるはずです。次回で最終回にできるかな?

AWS Direct Connectの勉強その3 パブリックVIF

 AWS 認定 高度なネットワーキング専門知識(アドバンストネットワーク)の試験勉強の続きです。みんな(?)苦手なDirect Connectについてのまとめです。

AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その2 プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その3 パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その4 Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その5 経路選択と冗長化 - プログラマでありたい


 第三回目の今回は、パブリックVIFとDirect Connect Gatewayについてまとめます。15日に試験受けるつもりですが、このペースだと間に合わないなぁと思いますが、まぁやるだけやってみましょう。

パブリックVIF

 AWSのDirect Connectは、物理的な回線である接続(Connection)とそれを論理的な単位に切り分けた仮想インタフェース(Virtual Interface = VIF)があります。VIFには、プライベートVIFとパブリックVIF、あとTransit Gatewayに利用するTransit VIFがあります。前回、プライベートVIFの説明をしたので、今回はパブリックVIFです。

 パブリックVIFの特徴は、ユーザー側の拠点とAWS側をパブリックIPでつなぐという点です。そのため、接続対象はプライベートIPであるVPC内のサービス(EC2やRDS)ではなく、VPC外のパブリックIPで提供されるサービス(S3やDynamoDB)となります。また、プライベートVIFは1つのVPCと接続でしたが、パブリックIPの場合は中国を除く全リージョンのAWSサービスのパブリックIPが広告されます。つまりどこのリージョンのサービスでも接続できます

f:id:dkfj:20210111103240p:plain

パブリックVIFのユースケース

 さて、そのパブリックVIFを利用したDirect Connectですが、ユースケースとしてはどんなものがあるのでしょうか?先述の通りVPC外のAWSリソースを専用線経由で使うサービスなのですが、専用線経由である必要があまり思いつきませんでした。今はPrivateLinkもあるし。そこでTwitterで知恵を求めたところ、幾つかのアイデアを頂きました。



VPC外のAWSリソースにアクセスしたい

 代表的なケースとしては、やはりVPC外のAWSリソースにアクセスしたいと。特に、Amazon ConnectとAmazon WorkSpacesに対するニーズが高いようでした。Amazon Connectは、電話番号も含めてコンタクトセンターサービスを提供する素晴らしいサービスです。コールセンターという業務上、機密性が高く専用線接続をしたいというニーズも納得感があります。
 次に多かったのが、Amazon WorkSpacesです。WorkSpacesは、仮想ディスクトップ(VDI)を提供するサービスです。VDIまでの経路に関するニーズも多く、専用線を使いたいというケースも多いのではと想像できます。ちなみに、テレワーク前提で考えると、個々に専用線を引くのは現実的ではなく、クライアントVPNを併用したいというケースも多いです。
※一方で経路の安全という意味では、もともとHTTPSで暗号化した通信で確保できています。専用線接続やクライアントVPNは、接続元に対する制限の追加という意味合いが強いのでしょうね。

専用線接続 + IPSec(AWS Site-to-Site VPN)

 なるほどなと思ったのが、専用線の間を流れる通信を暗号化したいというユースケースです。専用線間の通信は、サービス側で暗号化等の処理はしません。必要に応じて利用者側が対応する必要があります。セキュリティを強固にする必要があるシステムの場合、クライアントからサーバーまで全ての経路で暗号化が必須という要件がある場合があります。その場合、単に専用線を利用するだけではNGとなります。そういった時に、個々のアプリで暗号化を実現するのが大変な場合、IPSecを併用するというのが現実解となります。
 AWSの場合、Direct Connect + AWS Site-to-Site VPNを利用したい場合、Private VIFではなくPublic VIFを利用する必要があります。IPSecのサービス自体が、グローバルIP同士での接続が前提となるので必然的ですよね。

f:id:dkfj:20210111112201p:plain

 図の通り、複数のVPN接続をすることも可能です。ちなみに、専用線を経由せず直接IPSecのVPNでいいのではという疑問が出てくるかもしれません。それは、そのとおりです。暗号化強度的には専用線を経由しようが、インターネットを経由しようが同じです。
※盗聴&解析の危険性はインターネット経由の方が高いでしょうが、通信内容が暴かれるというリスクは現実的にはあまり変わらないと思います。

 専用線経由のメリットとしては、通信の安定性です。一般的にはインターネット経由より専用線経由の方が通信の安定性は高く、レイテンシー(遅延)も低いです。その上でのIPSecの通信は、当然通信品質が高くなります。

パブリックVIFのまとめ

 パブリックVIFの基本的な概念と代表的なユースケースをまとめてみました。全般的にいうと、Private Linkの登場でパブリックVIFの必要性は少なくなっていると思います。一方で、もともとプライベートに接続する要件がまったく無いよという場合は、パブリックVIFも選択肢になります。用途の違いを把握したうえで、使い分けを考えてみましょう。
 次はようやくDirect Connect Gatewayです

AWS Direct Connectの勉強その2 プライベートVIFの接続パターン

 昨日に引き続きAWS Direct Connectのお勉強です。大切なことなので繰り返しますが、私はネットワークについては苦手なので、勘違いしていることがあれば容赦のないマサカリをお願いいたします。

AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その2 プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その3 パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その4 Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その5 経路選択と冗長化 - プログラマでありたい

プライベート接続

単一VPCへの接続

 まずはプライベート接続からです。一番、基本的なオンプレミス側のデータセンターとAWSのVPCを一つ接続するパターンです。

f:id:dkfj:20210105234445p:plain

データセンター側にルーターが必要となります。ルーターの機能要件としては、下記の4つです。

  • BGP サポート
  • MD5認証 サポート
  • IEEE802.1q サポート
  • VLAN サポート

 Private VIFをVGW(Virtual Private Gateway)にアタッチし、VPCとデータセンター間の通信を確立します。その際に、異なる2つのネットワークの経路を制御するのがBGP(Border Gateway Protocol)です。BGPを介して、双方のネットワークを広告します。図中に、eBGPと書いていますが、これはExternal BGPの略です。External(外部)という言葉から解るように、異なるネットワーク(AS)間の経路交換です。同一ネットワーク間の間の経路交換の場合はiBGP(Internal BGP)を利用します。この辺りは経路の冗長化のところで説明します。

複数VPCへの接続

 開発用VPC・検証用VPC・本番用VPC或いは、システムA用VPC・システムB用VPCと複数のVPCを利用するケースは多いと思います。Direct Connectを利用する企業の場合、むしろ複数VPCを活用しているケースの方が多いのではないでしょうか? Direct Connectのみで、複数VPCに接続する方法が次の図です。

f:id:dkfj:20210106002918p:plain

 その解決方法は、ずばりVPCごとにPrivate VIFを用意して異なるVLANを割り振ってそれぞれ接続するという方法です。Direct Connectは基本的には論理的接続であるPrivate VIF単位ではなく物理的な回線であるConnection単位です。そのため、一本のConnectionを複数のPrivate VIFに分割しても料金は基本的には変わりません。(パートナー経由でPrivate VIFを提供されている場合は、そうでないケースは多いと思います。)
 一方で、Connectionの全体の帯域をPrivate VIFで分け合うので、Private VIFが増えるとVIF単位の帯域は狭める必要があります。そもそも、VPCの数が数個くらいであれば大きな問題にはなりませんが、10や20或いは100といった単位で利用している場合はVPCごとにPrivate VIFを用意するのは困難です。そこで今まで色々なパターンの接続方法が編み出されてきました。その辺りも紹介していきます。

Transit VPC

 複数のVPCに接続するパターンとして昔からあるパターンの一つがTransit VPCです。いわゆるハブアンドスポークネットワークトポロジーの接続形態で、オンプレミスの拠点とハブとなるVPCを接続し、ハブVPCから複数のスポークVPCに接続するというパターンです。スポークとは、車や自転車のタイヤで中心から伸びてるあれです。

f:id:dkfj:20210106005411j:plain
※Wikipediaさんから拝借

概念的には普遍的な接続形態だと思うのですが、AWSの場合はTransit VPCというとハブVPC内にCiscoのルーターを置いたものを指すようです。

f:id:dkfj:20210106011435p:plain

 オンプレミス拠点とハブVPCは、VPNもしくはDirect Connectで接続します。まぁこの文脈だとDirect Connectを利用してくださいですが。ポイントはハブVPCとスポークVPCの接続です。これはハブVPC内に起動したルーター機能を果たすec2インスタンスとスポークVPC間でVPN接続をします。なぜ、AWSの機能であるSite to Site VPNを使わないかというと、AWSのVGWはIPSECのネゴシエーションはしないので、VPC同士でVPNを貼れないからです。そこでルーターの仮想アプライアンスを利用するという形になっています。

 実際のTransit VPCの構成は、可用性を確保するために2つのAZにそれぞれ仮想アプライアンスを配置し冗長化した構成になっています。詳細は、下記のページを参照してください。

aws.amazon.com

VPCピアリングのパターン

 先程のTransit VPCのパターンと同様にVPC Peeringを使ってHub VPCとSpoke VPCを形成することも可能です。VPCピアリングはVPWを利用したVPN通信ではなく、VPC同士をネットワーク的に通信可能にする機能です。通常のAZ間、或いはリージョン間の通信として扱われるため、Direct Connect GatewayやTransit Gatewayを介した通信より低コストで運用できることが多く、VPCピアリングは今でも採用されるケースが多いように思えます。

f:id:dkfj:20210107000107p:plain

 ちなみにVPC Peeringは、隣接するVPC同士の通信のみサポートするので、オンプレからspoke VPCのインスタンスに対して直接通信するような透過的通信はできません。
※上のTransit VPCでも同様だと思います。(未確認)

プライベートVIFからのVPC外のAWSサービスへの接続方法

 ここまででプライベートVIFの接続パターンや構成パターンを幾つか見ました。さて、S3やLambdaのようなVPC外のAWSサービスにアクセスしたい場合はどうしたら良いのでしょうか?次の図のようにプライベートVIF経由では、VPC外のAWSサービスに直接アクセスすることが出来ません。Direct Connect経由でS3にアクセスしたいというユースケースはわりとありまして、そういった時の接続パターンの一つとしてはVPC内にプロキシ的な役割を果たすEC2インスタンスを用意するといった方法があります。ちょっと面倒くさいですね

f:id:dkfj:20210107004849p:plain

 そういった用途に応えるためのAWSサービスとして、インターフェース型のVPCエンドポイント(Private Link)があります。これは、VPC内にAWSサービスのエンドポイントをのばしてきて、あたかもVPC内のリソースにアクセスするというサービスです。

f:id:dkfj:20210107004820p:plain

なおS3とDynamoDBはVPCエンドポイントに対応しているのですが、ゲートウェイ型VPCエンドポイントという形式です。これを利用しても、オンプレからプライベートVIF経由でS3にアクセスすることはできません。2020年のre:Inventの発表でS3もインターフェース型VPCエンドポイント(Private Link)に対応するという宣言があったので、近い将来利用できるようになるです。

まとめ

 Direct ConnectのプライベートVIFについて接続パターンをまとめてみました。プライベートVIFはVPCと1対1で接続するため、複数のVPCを利用している場合は接続パターンに工夫が必要です。今回はプライベートVIFのみで解決する方法を幾つか紹介しています。が、どれも使いにくいというのが正直なところです。その改善として、AWSはDirect Connect GatewayやTransit Gatewayを出してきています。これもそのうち紹介したいです。
 今回のDirect Connectの勉強シリーズは、自身の苦手なところの補強。そして、BGPの理解のために書いています。が、なかなかそこまでたどり着かないので、来週に控えたAWS認定アドバンストネットワークに合格できるか不安になってきました

AWS Direct Connectの勉強

現在、AWS認定は9個持っていますが、どうせなら12個全部取ってドヤ顔したいと思っています。残りはアドバンストネットワーク(高度なネットワーキング)、データベース、Alexaです。データベースとAlexaは取れる自信があるので、最大の鬼門のアドバンストネットワークを片付けたいです。これを取るためには、Direct Connectまわりの理解が必要です。Direct Connectは利用者としての知識しかないので、ちゃんと勉強してみようと思います。

AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その2 プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その3 パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その4 Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その5 経路選択と冗長化 - プログラマでありたい

高度なネットワークング周りのDirect Connectの出題範囲

まずは試験範囲の確認として、AWS公式のExam Readinessのデジタル講座を受講しました。
Exam Readiness: AWS Certified Advanced Networking - Specialty (Digital)
https://www.aws.training/Details/Curriculum?id=21330

Direct Connect周りは、下記の知識が必要なようです

  • Direct Connectの概要
  • BGP
  • Public VIF
  • Private VIF
  • Connecting to VPC Multiple Accounts
  • VPN and Direct Connect Communication Outside of VPC
  • Transit VPC
  • Direct Connect Gateway

まずはDirect Connectの基礎知識から、BGP・VIF辺りを確認してみます。

Direct Connectの構成要素

Direct Connect ロケーション

 Direct Connectは、ユーザーが利用しているデータセンターなどの物理拠点とAWSの間を専用線で接続するためのサービスです。しかし、物理拠点とAWSは直結されるのではなく、Direct Connect ロケーションと呼ばれる接続ポイントを介して接続します。AWSの所有するデータセンターがどこにあるか解らないし、かつ複数のAZ・データセンターに分散しているためですね。

f:id:dkfj:20210111103458p:plain

 東京リージョンだと、Equinix TY2が有名ですが、アット東京 CC1や大阪・台湾など幾つかのDirect Connect ロケーションが利用可能です。Direct Connect ロケーション内には、AWSが管理する機器とユーザーもしくはDirect Connect提供パートナーが管理する機器があります。

Connection(接続)

 AWSが管理する機器とユーザーもしくはDirect Connect提供パートナーが管理する機器も同一構内にありますが、この間もネットワークによって接続されます。これをConnection(接続)と呼びます。Connectionは1Gbps or 10Gbpsで 接続できます。ちなみに、ユーザー自身でも直接Direct Connectを敷設できますが、直接利用するケースは少なくDirect Connect提供パートナー経由で利用することが殆どです。そのため、アドバンストネットワークで問われるDirect Connect絡みの問題は、やったことがないよって状態になることが多いです。

f:id:dkfj:20210111103514p:plain

Link Aggregation Group(LAG)

 10Gbps or 1Gbpsの回線を利用可能ですが、それ以上の帯域が必要な場合はどうしたら良いのでしょうか?Link Aggregation Group(LAG)を使って複数の物理的な回線を1本の論理的な回線にまとめることができます。集約する場合は、等速度の回線を利用する必要があります。また最大4本までです。つまり、(オーバーヘッド分を無視すると)40Gbps分の帯域が利用可能になります

f:id:dkfj:20210105004022p:plain

 ちなみにDirect ConnectのFAQを眺めていると、途中でLAGのリンクを追加できるようです。例えば、最初2本で集約していたところに更に2本追加して4本というようなことも出来るようです。ただし、追加しようとした時にLAGを形成しているポートに空きが無い場合は、新たにLAGを組み直さないといけないようです。問い合わせる時、超ドキドキですね

仮想インタフェース(Virtual Interface = VIF)

 先程、Connectionが1Gbps or 10Gbpsの物理的な接続と説明しました。このConnectionをそのまま使うのではなく仮想インタフェース(VIF)と呼ばれる論理的なインタフェースとして扱います。Connectionは10Gbpsか1Gbpsですが、VIFはもっと細かい単位で利用できます。パートナー経由の提供ですが、1Gbps未満の50,100,200,300,400,500Mbpsの帯域を利用できます。

f:id:dkfj:20210105011426p:plain

※AWSのWebサイトから拝借

 先程、Direct Connectを直接利用する人は少なくパートナー経由の提供が多いといいましたが、パートナーのサービスの多くはConnectionではなくVIFを提供することになります。そのため、多くの人のイメージではDirect Connect = VIFになるのではないでしょうか。Connection自体を提供するのが専有型で、VIFを提供するのが共有型です。
※だからAWS認定アドバンストネットワークが難しく感じる。愚痴です

 さて、このVIFですが、実はPublic VIFとPrivate VIFとTransit VIFの3種類があります。Transit VIFはTransit Gatewayと密接な関係があります。ここでは、Public VIFとPrivate VIFの説明していきます

f:id:dkfj:20210111103624p:plain

Private VIF

 まずPrivate VIFです。Private VIFはVPCに接続するために利用します。Direct Connectの目的の9割9部がこちらの方ではないでしょうか?オンプレミスのデータセンターのプライベートネットワークから、VPCのプライベートネットワークまでグローバルIPを介すことなく通信可能にします。

Public VIF

 Public VIFはオンプレミスのデータセンターのプライベートIPをパブリックIPにNATして利用するサービスです。そして、S3やDynamoDBなどVPCに入らないサービスを直接利用可能にします。と言っても、Direct Connect提供パートナーでこちらのサービスを提供しているところは殆どありません。Private VIFのニーズが高いのでしょうね。
 ちなみに、S3やDynamoDBはVPCの中には入らず、基本的にはパブリックIPで接続します。このAWSネットワークの中でVPCじゃない空間は一体何なのでしょう?インターネット空間なのかそうではないのか?これは面白いテーマなので、いつか解説しようと思います。

まとめ

 力尽きたので、今日はここまでです。今回はDirect Connectの物理的な設備(Direct Connect ロケーション)のところから、物理的な回線(Connection)、論理的な接続として提供されるVIFまでです。VIFには、馴染みがないですがPrivate VIFとPublic VIFの2種類があります。次回はPrivate VIFやPublic VIFの接続パターンや経路選択・経路切替について説明してみようと思います。経路選択にはBGPの知識が必要なので、これを上手く理解して説明できるか今後の自分に期待しています。ネットワークは苦手な分野なので、認識違いありましたら容赦ないマサカリをお願いします