オンプレからAWSにシステム移行した時に推奨するDirectConnect周辺設計
これはなに？
オンプレにあったサーバをAWSのEC2に移行した場合、アクセス元は変わらずDirectConnectを経由した社内からがほとんどとという構成が多いです。
この場合、ALBを介してインターネットに公開するようなEC2インスタンスとは異なる目線での設計が必要でした。
このエントリーでは、上記のようなユースケースにおいておすすめのDirectConnect周辺設計を紹介します。
サブネット設計
次の図のようなサブネット設計を推奨します。
１と２のサブネットについて次項にて詳細を記載します。
（１）VPC Attachment専用サブネット
VPC AttachmentはPrivateサブネットに直接接続せず、専用サブネットを作成してそこに接続する構成が推奨されています。
Transit GatewayのVPC AttachmentをAttachする場合、VPC内にVPC Attachment専用のサブネットを作成して利用する構成をおすすめします。
https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-transit-gateway-2019/
（20191113 AWS Black Belt Online Seminar AWS Transit Gatewayから引用）
細かい説明
Transit GatewayのVPC AttachmentをAttachする場合、VPC内にVPC Attachment専用のサブネットを作成して利用する構成をおすすめします。
詳細は以下リンクを参照ください。
Amazon VPC Transit Gateways design best practices - Amazon VPC (日本語訳が微妙なので英語ドキュメントを参照ください)
Use a separate subnet for each transit gateway VPC attachment. For each subnet, use a small CIDR, for example /28, so that you have more addresses for EC2 resources. When you use a separate subnet, you can configure the following:
Keep the inbound and outbound network ACLs associated with the transit gateway subnets open.
Depending on your traffic flow, you can apply network ACLs to your workload subnets.
[AWS Black Belt Online Seminar] AWS Transit Gateway 資料及び QA 公開 | Amazon Web Services ブログ
Q. VPC をアタッチするときに指定するサブネットをアタッチ専用のサブネットとする必要性について、もう少し具体例を挙げて説明していただきたいです。そのサブネットの内部のEC2 インスタンスのルーティングに影響あるとのことでしたが、どのような影響があるのか？などを教えていただきたいです。
A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。
例えば インライン監査用の VPC の TGW の ENI がある Subnet 上に EC2 インスタンスを設置してしまうと、その EC2 インスタンスは必ずインライン監査のミドルボックス ENI に吸い込まれてしまい、EC2 インスタンスの意図するルーティングテーブルを作れなくなってしまいます。こういったことを防ぐために、TGW 専用のサブネットを作ることをお薦めしています。
（２）オンプレ向けEC2 用サブネット
Direct Connect の構成図を見ると、PrivateSubnetに接続されていることが多い。
実際にその構成で構築を開始すると、A.オンプレ向けにサービス提供しているEC2インスタンスとB.ALB経由でインターネット向けにサービス提供しているEC2インスタンスがPrivateSubnetに同居してしまう。
フロントにALBがあるとはいえ外部公開しているEC2インスタンスと同じサブネットに社内向けサーバが置いてあることがすごく不安になってくる。
上記のような状況が発生しないためにオンプレ向けEC2 用サブネットを用意しておくことを推奨する。
名前解決設計
概要
オンプレにあったサーバをAWSのEC2に移行した場合、名前解決は次の通り行いたい。
- 社内リソースの名前解決はオンプレのActiveDirectoryドメインコントローラー（DNS）にリクエスト
- CloudWatchLogsなどのAWS向け通信の名前解決はVPCにあるAWSのDNSにリクエスト
その場合は詳細解説：ガバメントクラウド名前解決編で紹介されている「Route 53 Resolver Rule を他の AWS アカウントへ共有する方法」のパターンを推奨する。
図としては次の通り。
構築
基本的には上記図の通り構築すればよい。
- Route53 Outbound Endpoint は、TransitGatewayを設置しているAWSアカウントに設置する
- Route 53 Resolver Ruleは次の２個作る
- 対象を「.」としてすべてのDNSクエリをオンプレにフォワードするルール
- amazonaws.com 宛のDNSクエリはVPCで名前解決するルール
- オンプレ向けの名前解決を行いたいAWSアカウント（VPC）は、上記で作成したRoute 53 Resolver Rule を共有することで実現する
ポイント
- 上記図の緑矢印で表現されている通り、DNSクエリは共有されたルールを経由しRoute53 Outbound Endpointからオンプレに到達する
- そのため、ルールを共有される側はDirectConnect接続は不要
感想
今回記載した内容はインターネットを探してもあまり事例が無かったので、みんなどうやって構成しているのか気になる。
Discussion