AWS事例-TransitGatewayを利用したNW集約
環境
オンプレとAWSアカウント間で日々の業務データのやり取りが相互に発生している環境
◆ オンプレ側のシステム群:本社センターまたは物理的なシステムを置くデータセンター
◆ AWS側のシステム群:複数のAWSアカウントにまたがる業務システム群
相互のやり取りにはAWS DirectConnectやPeeringのサービスを経由して通信を確立している
課題
- NWの保守に掛かる料金が大きいため無駄なコストは削減したい
- AWS DirectConnectの障害が発生した場合に業務が完全に停止することは回避したい
- AWSのアカウントを管理しているベンダが分かれるため通信のフローの把握が困難
- 今後の拡張などを見越した場合に1つ1つのダイレクトコネクトの回線帯域が不十分である
- 複数の業務データが共有する形でDirectConnectを利用しているが一部の業務システムが回線を占有したときに
送信元や原因の特定ができない
解決方法
- TransitGatewayのサービスを利用することによって、複数のDirectConnectを1本に集約
- AWSアカウント間の通信をPeeringの機能で実現していたが、通信の統制やトラフィックフロー可視化の目的でTransitGatewayに集約
- TransitGatewayのフローログを元に回線圧迫時に送信元を特定するための仕組みを実装
- DirectConnectサービス障害に備えてSite to Site VPNをバックアップ回線として採用
構成図のBefore/Afterイメージ
・Before
・After
ハマった箇所
◆ TransitGatewayのルートテーブルについて
- Peering通信では通信をするべきアカウントと通信するべきでないアカウントが存在したため
TransitGatewayのルートテーブルを分ける工夫をした - 将来的な要件の変化を見越して重複する内容でもアカウント毎にルートテーブルを分けた
▼ 注意ポイント- ルートテーブルを分ける場合、TransitGateway作成時に「デフォルトルートテーブルの関連付け,デフォルトルートテーブル伝搬」のパラメータをOffにして作成する必要があり作成後は変更ができないため注意が必要
- 1つのAttachmentに対して関連付けが可能なTransitGatewayルートテーブルは1つまでのため注意が必要
◆ 非対称ルート発生時のMTUの考慮
- 切替時に非対称ルートが発生するタイミングで仕様によりTransitGatewayの中で8500バイト以上のジャンボフレームを落とすことが判明。影響を検証
▼ 結論：今回の環境ではLinux同士の通信かつジャンボフレームでのUDP通信やICMP通信が無いことから、OSのMTU値のチューニングを行わずに切替を実施
▼ 注意ポイント- EC2のLinux対象のAMIにセットされるIFのMTU値はデフォルトで9001を利用する。Windowsはデフォルト1500を利用
- TransitGateway自身はMTU8500までをサポート。8500以上のジャンボフレームが届いた場合はパケットをドロップする仕様となる
- DirectConnectを経由したTransitGateway通信に関しては間にNW機器が入るため、TCP通信の場合はPath MTU Discoveryが有効であればLinix同士の通信でもジャンボフレームでパケットを送信することはない。Peering通信をTransitGatewayへ切り替える場合には中間にNW機器が入らないため注意が必要
- データ伝送に利用しているプロトコルがTCPかUDP/ICMPかによって動作が異なるため切替の設計を行う場合は移行計画について慎重に検討や検証を重ねることをお勧めします
◆ DirectConnectのVGWルート伝搬
- 既存のDirectConnectのルート情報についてVGWのルート伝搬があることで手動で変更ができなかった。結論としてルートを重複させてもOKであることが分かり、以下の内容でも無影響で切替ができることを確認した
1.手動で新規に重複するルートを追加
2.ルート伝搬無効化の対応を行う
効果、変更後のメリット
- DirectConnectの料金だけでなく、中間に挟まる回線業者向けのランニングコスト削減
- バックアップ回線を敷設し回線冗長を実現。DirectConnect障害時に自動切り替えができるようになった
※切替時は1分未満の停止。DirectConnectのサービス復帰後切戻り時は無影響の結果を確認 - 将来的に監査用/セキュリティ用/インターネット接続用のVPCを新たに繋げて管理を行うことも可能に
- VPN ECMPサポートがあるため将来的にVPNのtunnelを束ねて回線増強することも可能
- 新規でVPCを作成する場合にDirectConnect敷設の考慮が不要になるため、気軽にVPCやAWSアカウントの増加が可能になった
※DirectConnectでも契約によってDirectConnectGWを使って複数のVPCを接続することは可能 - 管理ベンダが異なるAWSアカウントもTransitGatewayに集約したことにより通信フローの把握が可能になった
- DirectConnect通信圧迫時にある程度の原因特定ができるようになった。
▼ イメージ
おわりに
DirectConnectと違いTransitGatewayはAttachmentの料金とトラフィックのIN/OUTの料金も発生するため
小規模な環境には合わないが、NWやアカウント量が増加していくことが見えていれば、
NWの複雑性へのコントロールするための管理コストを考慮するとTransitGatewayを採用するメリットがあり、通信コントロールについても柔軟性が高いサービスだと思いました。
今後新規でAWSアカウント間やDirectConnect間の通信を接続する際にはTransitGatewayの利用をご検討下さい。