Open2025/01/21にコメント追加23

Cloud Lab で Direct Connect を試す

これを見ながら作ってみたんだが、そもそもこれは ExpressRoute でいうところの ExpressRoute Direct 相当っぽい。

普通の ExpressRoute 相当のはホスト接続というやつで、ユーザー側からで何かリソースを作る必要はなく、アット東京に作ってくれー、ってお願いするだけでいいっぽい。
AWS アカウント ID は自分のやつ、接続名はユーザー側から指定したとおりにアット東京側で作っていただける。

・AWSアカウントID: xxxxxxxxxxxx
・接続名（Connection）: ATTC1-Connection-1
・ご利用帯域（50 Mbps、100 Mbps、200 Mbps、300 Mbps、400 Mbps、500 Mbps、1 Gbpsのいずれか）: 50Mbps
・接続ロケーション（東京or大阪）: ap-northeast-1

なんか Gateway が 3 種類ある

Virtual private gateways
- Virtual Network Gateway っぽい
Direct Connect gateways
- Virtual private gateways を複数つないで使えるっぽい、リージョン間とか複数 VPC 束ねるときに使うような感じ
Transit gateways
- Virtual WAN と同じような感じらしいけど難しそう、これからいろいろトライしたい

BGP の MD5 が必須っぽい。optional だっていうから空欄にしておいたら勝手に値決められた。気づかずに繋がらなかってなかなか悩んでいた

VLAN ID は AWS console に書かれているものはどうでも良くて、アット東京から渡された値を使う

どうも内部的には勝手に VLAN 変換されてそうな感じ

基本的にはこの辺の手順を見る

VPC > Route tables の Routes に Virtual Private Gateway を宛先として static route を追加するようなことが書いてあるけど実際には追加しなくていい
Route propagation のところで Virtual Private Gateway の propagation: Yes とすればちゃんと BGP で聞こえてくるようになる
該当の経路は Routes のところで Propagated: Yes として経路が表示される

これの設定変更から実際に影響があるまでの時間が早い。Enable を外すと 1 秒くらいでつながらくなって、再度 Enable にすると 3 秒くらいで画面が更新して見えるようになる

VPC > Route tables には main かどうか、という概念があるみたいで、main な route tabl は削除できないっぽい。別の route table を "Set main routa table" すれば消せるようになる。
削除してよいかは Subnet associations も併せて確認する

Virtual private gateway は VPN gateway と呼ばれるときもあるみたい。

The VPN gateway is in use. Please remove all Site-to-Site VPNs, Direct Connect Virtual Interfaces, Direct Connect Gateways, and VPCs from the VPN gateway and try again.

Virtual interfaces (VIF) が関連付けられていると削除できない、それはわかる。
ただ、VGW の画面から何の VIF がくっついているのかは見れないような気がする。

VPC 作成時に VPC and more で作るといろいろ作られる。

Main として設定される route table があるんだけど subnet の紐づけが無くて謎
clab02-20250117-vpc
clab02-20250117-subnet-public1-ap-northeast-1a
clab02-20250117-rtb-public
clab02-20250117-igw


clab02-20250117-subnet-private1-ap-northeast-1a
clab02-20250117-rtb-private1-ap-northeast-1a
clab02-20250117-vpce-s3



までは意味があるんだけど、rtb-075b54b165139e14f っていういらないリソースが作成される。。

Transit Gateway を使う

プライベート仮想インターフェイス（Private VIF）だとDirect Connect GatewayとTransit Gatewayの併用構成をすることはできないため、事前にトランジット仮想インターフェイス（Transit VIF）を用意する必要がありますので、選んだAWS Direct Connectを提供しているデリバリーパートナーにお問い合わせください。

とあるけど実際には作れるっぽい、どっかで更新があったのかわからん

なんか構成例がいくつか載ってそう

VPC route table に static 書かないといけないのがなんかイケてない気がする

Virtual private gateway が ExpressRoute gateway みたいな感じに見える。
そっから直接 VIF を生やすパターンもあるけど、推奨は Direct Connect gateway を挟むパターンっぽい。

Direct Connect gateway に Allowed prefixes ってのがあるけど、実際にはここに書いたものが redistribute static のイメージで流れてくるので、VPC の CIDR じゃないのを書くと変に DX 側に吸い込む。
Allowed prefix だと route-map の prefix filter のイメージだったけど違うねこれ

意味はないのかもしれないけど Transit Gateway を 2 つつなげて、1 つは Direct Connect gateway (を経由して Direct Connect)、1 つは VPC、にして、それぞれ static とか propagate とか設定したら相互接続はできた

VPC への propagate はできるけど、Transit Gatway 同士の peering の設定に向かっては propagate の設定ができないっぽいので static を書くっぽい。Azure でいうところの vHub 間の通信フローかな

ふとした瞬間に region が切り替わっているので気を付けたい