プログラマでありたい

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

JAWS-UG 初心者支部でIAMの「あ」の話をしました

 こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木(@dkfj)です。

 なんかIAMの話をしてリクエストがあったので、IAMの「あ」というタイトルで、IAMの基本的な部分について話す機会を頂きました。運営の方々、ありがとうございます。

jawsug-bgnr.connpass.com

発表内容

10分のLTなので、後半の細かい話はすっ飛ばして、下記の3点を中心に説明しています。

  • 認証認可とは
  • IAMの動き
  • IAMユーザーとIAMロール

speakerdeck.com

LT大会について

 今回のテーマは、LT大会ということで10分・5分が沢山でした。最近、勉強会自体もあまり参加できずだったのですが、参加するといろいろな刺激があっていいですね。特に初心者支部は、初めての人に積極的に登壇を勧めているようです。登壇に慣れている人でもリモート登壇は難易度高いのですが、そこを運営の人も参加者の人も温かくサポートしていて、いい雰囲気のイベントでした。会社の後輩とかにも発表して欲しいなぁと思いました。
 他の方の登壇内容については、AWSのマルチアカウント運用に関する発表も多く、最近の自分の関心軸と一致しました。どこも試行錯誤していて、その生の声が聞けるのはありがたい限りです。
 他の登壇者含めてのまとめは既に山下さんがしているので、こちらのブログを参照してください

www.yamamanx.com

 Togetterでイベントの様子も解ります。いいね!!

togetter.com

感想

 ということで、半年ぶりくらいの勉強会の参加&登壇でした。去年目標にしていた、全国のいろいろな支部に参加してみるというのを、今年こそはチャレンジしてみたいと思います。また、輪読会みたいな少人数でディスカッションできるのにも積極的に参加してみたいので、もし佐々木が書いた本をテーマに開催する場合は、ぜひお声がけください。可能な限り参加します

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認定アドバンストネットワークに合格できるか不安になってきました