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

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

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

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

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

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

• オンプレミス⇒AWS：　Local Preference（LP）
• AWS⇒オンプレミス：　AS Path Prepend

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

経路選択

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

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

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

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の２つのネットワークが広告されていた場合、ロンゲストマッチとしては172.16.1.0/24となります。

経路障害の検知

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

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

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

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

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

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アカウントにも接続できるようになりました。

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

Direct Connect Gatewayの通信の制約

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

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

Transit Gateway

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

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

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

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

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

AWS VPN CloudHub

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

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

まとめ

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

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

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

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

　第三回目の今回は、パブリック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は１つのVPCと接続でしたが、パブリックIPの場合は中国を除く全リージョンのAWSサービスのパブリックIPが広告されます。つまりどこのリージョンのサービスでも接続できます

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

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

AWS Direct ConnectのパブリックVIFって、どんなユースケースで使うのかな？オンプレから直接S3を大量に扱いたい時以外思いつかない。誰か教えろください

— Takuro SASAKI＠技術書典9 (@dkfj) 2021年1月10日

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同士での接続が前提となるので必然的ですよね。

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

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

パブリックVIFのまとめ

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

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

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

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

プライベート接続

単一VPCへの接続

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

データセンター側にルーターが必要となります。ルーターの機能要件としては、下記の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に接続する方法が次の図です。

　その解決方法は、ずばり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に接続するというパターンです。スポークとは、車や自転車のタイヤで中心から伸びてるあれです。

※Wikipediaさんから拝借

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

　オンプレミス拠点とハブ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ピアリングは今でも採用されるケースが多いように思えます。

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

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

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

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

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

まとめ

　Direct ConnectのプライベートVIFについて接続パターンをまとめてみました。プライベートVIFはVPCと１対１で接続するため、複数の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の勉強その２ プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その３ パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その４ Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その５ 経路選択と冗長化 - プログラマでありたい

高度なネットワークング周りの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・データセンターに分散しているためですね。

　東京リージョンだと、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絡みの問題は、やったことがないよって状態になることが多いです。

Link Aggregation Group（LAG）

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

　ちなみに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の帯域を利用できます。

※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の説明していきます

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の２種類があります。次回はPrivate VIFやPublic VIFの接続パターンや経路選択・経路切替について説明してみようと思います。経路選択にはBGPの知識が必要なので、これを上手く理解して説明できるか今後の自分に期待しています。ネットワークは苦手な分野なので、認識違いありましたら容赦ないマサカリをお願いします

2021年1月の目標

昨年の実績がダメダメだったので、初心に戻って月ごとの目標を立てていきます。いつまで続くか解りませんが、まずはやってみます。

2021年1月の目標

• AWS 認定 高度なネットワーキング – 専門知識の取得
• 序章を完成させる
• 新規書籍の目次完了。メンバーが執筆レディの状態にする
• 技術ブログを４本書く

AWS 認定 高度なネットワーキング – 専門知識の取得

12冠の最大の壁、AWS認定 アドバンストネットワーク – 専門知識の受験と合格目指します。試験範囲については、年末にまとめていて、1/15に受験するので勉強時間を15時間ほど確保する。平日1時間×８日と休日2時間×3日とどこかでプラスアルファ。ついでに勉強した内容をブログにまとめる

序章を２本完成させる

　昨年末に手をつけていた新刊の序章を完成させる。残り8,000字くらい

新規書籍の目次完了

　企画が完了している新規書籍の目次を完成させる。メンバーと担当箇所を割り振って、執筆可能な状態に持っていく

技術ブログを４本書く

　毎週１本を目安に技術ブログを書く。今月は、AWS認定アドバンストネットワークの勉強した内容を中心にまとめる。一本は、昨年まとめていなかったre:Inventの１行まとめ

その他

• 毎日１万歩歩く。１月は31万歩
• 仕事始める時に、１日分のToDoリストを作る
• 本を５冊読む

2020年の振り返りと2021年の目標

　あけましておめでとうございます。今年もよろしくお願いします。
毎年恒例の、昨年の振り返りと今年の目標です。2020年の主な活動は、執筆3冊と登壇4回です。あと、AWSにアンバサダーでTop Japan Ambassadorsとして貢献度日本一と表彰されました。これだけ書くと順調のようですが、個々の振り返りをしてみると非常に苦しんだ1年です。

11,12冊目の本の出版と13冊目の執筆

　昨年の執筆実績は3冊です。と言っても、執筆に当てられる時間が少なく、純粋に書いた文字数ではここ数年の中で一番少なかったかもです。1冊目は、AWS認定セキュリティの試験対策本である、要点整理から攻略する『AWS認定 セキュリティ-専門知識』。こちらは初のマイナビ出版さんから刊行です。また執筆自体も、私は最初の企画と一章のナビの部分のみで、あとは殆ど会社の同僚の上野さんと小林さんの執筆です。初版の誤植などの問題はありましたが、内容的なクオリティは非常に高いと思っています。絶賛発売中です

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

　12冊目は、また技術同人誌です。前回はIAM本だったので、次はAWSアカウントセキュリティにフォーカスを当てています。物理開催される予定だった技術書典8に合わせて書いていたのですが、残念ながら物理開催は中止でオンラインで販売中です。まぁこれも、技術同人誌というカテゴリーの中ではかなり売れていると思います。合わせて技術書典9で、AWSのマルチアカウント本を書いて3部作完結とする予定でしたが、気力が尽きて書けていません。春までには書きたいですね

booth.pm

　13冊目は、AWS認定ソリューションアーキテクトの対策本の改訂です。2019年に書いたのに、2020年に試験が改訂されたのでそれに合わせての修正です。執筆が遅れて2021年1月の発売になってしまいました。そのため、10月過ぎくらいから在庫切れが続き、出版社にも購入希望者にも申し訳なかったです。すいません。

AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版

登壇

　昨年は登壇は4つと少なめです。新型コロナの影響というより、気力・体力の関係ですね。登壇すると自分自身の学びの効果も高く効率がいいのですが、なかなか手を挙げられませんでした。もともとは無理やり機会を作るために、地方の勉強会に参加しようと意気込んていたのですが、物理開催が難しくなり実現できずです。論理開催になったので、全国の勉強会に参加するチャンスはできたのですが、その辺りを活かせずですね。

『AWSの薄い本 IAMのマニアックな話』の輪読会

　登壇ではないのですが、唯一物理参加したのが輪読会です。自著の輪読会が開催されているのを知って、押しかけさせてもらいました。楽しかったです。都合があえば可能な限り参加するので、お気軽にお声がけください

blog.takuros.net

富山IT勉強会

　地方に旅行することをモチベーションに、勉強会に登壇の機会を増やそうと考えていました。ちょうど良いタイミングで富山であると知って参加予定でしたが、残念ながら新型コロナの影響で論理開催に。少人数でいろいろ話せたので、これはこれで良かったです。また参加したいです。

blog.takuros.net

Fin-JAWS

　AWS認定セキュリティの対策本の執筆記念にお声がけいただきました。Fin-JAWSは初参加だったのですが、金融クラスターの方々と話ができる良い機会でした。

speakerdeck.com

JAWS-UG朝会

　AWS OrganizationsとCloudFormation StackSetsの話をしたくて申し込みました。朝の時間を有効活用できるのは良いですね。またこの辺のテーマの話は、もっといろいろしたいです。

speakerdeck.com

Security-JAWS

　同じくAWS認定セキュリティの対策本の執筆記念にお声がけいただきました。テーマがFin-JAWSで話したのと同じだったのと、参加者の層もかぶっていたので、結果的に2回聞いたという人も多かったようです。この辺は工夫すべきでした。反省

speakerdeck.com

ブログ

　自分にとっての活動のバロメーターであるブログの投稿は、2020年は41本でした。2019年は26本だったので少し復調かなという気はしますが、月によってのばらつきがありコンスタントな活動ができていません。またブログのアクセス数は86,126と前年の202,257に較べて大幅減です。定期的な投稿していないと減るのよねぇと改めて実感です。今年は毎週1本くらいのペースに戻そうと思います

　10年くらいのスパンでみると、低迷っぷりは明白です

Japan APN Ambassadorで日本一

　唯一明るいニュースが、AWSのAPN Ambassadorで地域（日本）貢献度で一番ということで表彰されました。ありがとうございます。ちなみに一番順位が高い時は、世界で3位くらいでした。※

www.nri-net.com

　なお、今では同僚の上野さんに抜かれて、国内2位です。
※Ambassadorだけが入れるポータルがあり、そこでランク付けされています。

2020年の目標に対しての採点

本を3冊書く　⇒　○　一応3冊分書いたので良しとしましょう。今年は複数人で並行で進めているのを、一気に展開したい
Kindle本を書く　⇒　○　IAM本とAWSアカウントセキュリティ本をKindle本として出してみました。少しだけ様子が解りました　
ブログ　⇒　☓　9万ビュー弱。昨年から半減以下。最盛期の1/10くらい。コンスタントに書く習慣が無くなってから駄目だ　
英語ブログ　⇒　☓　全く取りかかれず　
資格試験　⇒　☓　なんと一度も試験を受けず
英語　⇒　☓　何もせず。。。

自己採点すると、もうダメダメです。このレベルになると、やろうとしている方向性と目標の立て方がずれていたということでしょう。

2021年の目標

• 本を書く　自分中心ではなく、周りの人を巻き込んでの活動にします。2020年からこの活動はしているので、順調にいけば2021年には結構な本数を出せると思います。ただ、AWSの薄い本の三部作目は自分の手で完結させたいです。あと1冊ずっと出せていない本もちゃんと書かないと。
• 動画コンテンツ　個人でやるか会社としてやるか、或いはその両方か検討中ですが、動画コンテンツに挑戦してみたいです。今までブログや書籍など活字コンテンツ中心だったので、違う市場というのを見てみたいというのが目的です
• 資格試験　AWS認定試験12冠。これだけはちゃんと達成します。3月まで
• ブログ　ページビュー数を目標じゃなくて、毎週書くということを目標に再設定します。考えてみたらビュー数は結果ですし、忙しくても書くという習慣化が必要なのだと思います
• IAM本を英語化＆Kindleで全世界販売　世界の市場規模を知りたいので、これをやってみたい。2年ほど前から検討してたのですが、今年こそはやります。誰か手伝ってくれる人募集
• 事業として考える　過去の執筆物が積み上がり技術同人誌の販売をしていて、経理とか含め片手間でやるのがしんどくなってきました。この辺り、一度ちゃんと税理士さんとかと相談できるような体制つくりたいと思っています。※ちゃんと毎年納税していますよ
• Twitterのフォロワー5,000人　最近マーケティング的な動き方というのも模索しています。まずは自分ごとで始めるのが大事なので、Twitterのフォロワーを増やしてみたいです。現時点で2,600人なので倍の5,000人。かなり厳しいですが、方法考えてみます

まとめ

　全般的に不調な2020年でした。子供が地域の野球チームに入ったので、土日にそれの手伝いが必要など時間的な制約面が大きかったのかもしれません。が、それ以上にやる気がでなかったのが大きいと思います。理由の一つとしては、活動がマンネリ化していることだと考えています。執筆活動はそれなりにもう充分成果は出してきたと思うので、企画等の段階から含めて若者に任せていきたいと思います。その代わりに新しい挑戦をしていきたいです。具体的な内容については、計画立てて順次発表していきたいと思います。
　2021年も宜しくおねがいします