先日もQuickSight特化の1Dayイベントがありましたが、今回はNetworking特化です！
AWSのRoadshowシリーズはグローバルで各国開催されているようで、今回も海外の製品企画部門の方からのキーノートもありました。
エンプラ現場でシステムを扱っていると何だかんだでネットワーク関連は避けられないので、とても楽しみなセミナーでした！
各セッション内容の簡単な紹介
聴きながらの走り書きのため、部分的な内容となることご容赦ください🙏
キーノート：今後の AWS Networking
AWSグローバルのNetworkingテックリード、Steveさんからのキーノートです。
AWSの物理インフラについて
- AWSの持つグローバルインフラが各サービスを提供する基礎になっている
- 現在AWSリージョンは３２あり、それぞれ最低3つのAZを持つことで可用性を保っている
- 離れたAZ同士を繋ぐためにかなりの数のケーブルを引いている
- 各リージョンに最低2つのトランジットセンターがあり、AZやリージョン間の接続を担っている
- ローカルゾーンを展開しているリージョンもあり。低遅延を実現できる
- Direct Connectは125以上のロケーションがあり、日本にも3つある
仮想インフラ
- VPCはクラウドリソースをバーチャルに切り分けて提供している
- ユーザーが保有するVPCが想定以上に増えたため、ピアリングによる相互接続を提供した
- さらに多数のVPCを相互接続しやすいように、トランジットGWをリリースした
- そこからネットワーキングサービスは膨大に増え、使いこなすには魔術師のようなスキルが必要
サービスメッシュの必要性
- AWSはアプリケーションの開発をシンプルにしたい。ネットワークにも管理者と開発者でロールが分かれる
- 両者の観点で接続性、セキュリティ、可視性を満たすためにサービスメッシュの考え方がある
- サービスメッシュの課題：プロキシが必要、ワークロードのコンテナ化、ネットワーク知識も必要
- そこでVPC Latticeをローンチ。アプリレイヤーのネットワーキングをシンプルにした
- Latticeはサイドカー不要、コンテナ以外にも対応、ネットワーク知識不要、権限管理も可能に
VPC Latticeの紹介
- 最初に管理者がサービスネットワークを作成し、必要な開発者の権限などを定義する
- 開発者はアプリケーションの開発をサービスネットワーク内で実施するだけでよい
- 開発者はネットワーク全体のポリシーは気にせずに、自分が必要な通信先とのポリシーのみ設定できる
- 管理者は継続的にトラフィックやセキュリティ上の課題を監視できる
ゼロトラストの考え方
- 最初のステップ：クラウド上の複数のアプリに対して利用者がアクセスする際、まずVPNレイヤーを設ける
- 次に、不正な侵入防止のためアイデンティティを確認するポリシーを設ける
- そしてデバイスへ利用可能なアプリケーションを定めるポリシーを設定する必要がある
- これをAWS社内でも模索する中で生まれたのがAWS Verified Access
AWS Verified Accessの紹介
- クラウド上のアプリへ向かう途中にAVPを配置する
- AVPでポリシーをまとめて設定しておくことで、エンドユーザーは適切に各アプリを利用できる
AWS Cloud WANの紹介
- 従来型のエンプラネットワーク：本社と支社や各拠点があり、どこかのデータセンターを介して繋がっている
- そこにクラウドが出現することで、データセンター経由でさらにクラウドと接続される
- Cloud WANはここで物理拠点とクラウドを対等に繋いでくれるサービス
- セグメントという考え方で接続を分割し、VRFのように複数のセグメントを管理できる
- これによって従来型のWANがクラウドへ移行されるようになり、コスト削減にも役立っている
- コスト削減できる理由：ネットワークコンポーネントの数を減らせるため
WANのクラウド移行
- エンプラの従来型WANの課題：帯域幅の制約、長期契約の縛り、管理負荷
- Cloud WANでは各拠点やデータセンター、AWSリージョンがハブのように接続でき、操作も簡単
- AWSのWANソリューション：SD-WAN、Direct Connect、VPNサービス
- DX Sitelinkを使えば各拠点の接続をまとめることが可能
QA
- VPCの帯域幅に上限はある？
- EC2インスタンスタイプごとに公表されている
- 複数のEC2へのトラフィックがIGW帯域幅ネックになることはあるか？
- ない。インスタンスごとに上限があるので安心を。IGWは裏で複数コンポーネントに分かれている
- トランジットセンターなるものはAZのファシリティとは独立している？
- 基本的にその通り。複数のプロバイダーと接続しやすいロケーションに配置されることが多い。
- Resiliency in Japanというレポートは随時更新されるものか？（定量情報が含まれるため）
- 大阪に2つ目のDXロケーション増設予定はあるか？
- 具体的な時期は約束できないが、複数の顧客から大きなニーズがあれば検討材料に入れたい。
- 今後、大阪リージョンで東京より先行した機能追加が行われることはありうるか？
- 顧客ニーズ次第。今後ぜひ大阪で最初に使いたい機能があればニーズを挙げてほしい。
- 来年2月からパブリックIPv4が有償化されるが、今後IPv6対応は進むのか？
- IPv6サポート対象を随時公開している。スコープは拡大予定。
- 台湾のDXロケーション2つが東京リージョンにあるのは何故？
- あれはDXのコントロールプレーンとしての所属を表している。データプレーンの実トラフィックはいちいち東京経由したりしないので安心してよい。
グローバルネットワーク展開、DR対策を迅速化するAWS Cloud WAN
SAの山本さん、小林さんより。
AWSのNetworkingビジョン
- エッジからデータセンターまでを繋げるよう、AWSインフラをオンプレNWの一部として使ってもらえる
- エンプラのよくあるWAN構成はデータセンターを中心として拠点を繋ぐ。ここにクラウド接続が追加される
AWSとオンプレの接続方法
- 主な2つとしてDirect Connect、Site-to-Site VPNの概要を紹介
- Direct Connectのバックアップ回線としてSite-to-Site VPNを使うことも可能
Cloud WANの紹介
- ポリシーで一元管理。リージョンまたぎでセキュアに通信可能
- 他のコンポーネントをアタッチメントとして接続可能（まだDXは未対応）
- Transit Gatewayなしでリージョン間VPC接続できる。本番・開発などのセグメント分けも可能
- DR対策でサブリージョンの接続を追加することもできる
- 既存のオンプレSD-WAN、VPNやAWSのTGW等をまとめてCloud WANに接続できる
- オンプレからのトラフィックをVPC経由でIGWからインターネットへ出すことも可能
Cloud WANの構成要素
- Cloud WANはグローバルネットワーク内のコアネットワークに存在
- セグメント：用途ごとにNWを可能分割できる
- アタッチメント：各NWサービスを接続可能
- コアネットワークポリシー
- ダッシュボード：AWS Network Managerでコアネットワーク全体を一元管理できる
- マネコンではNetwork Managerから管理できる
QA
- 大阪リージョンにも対応してユーザーは増えているか？
- 現状まだそこまで多数の利用者がいるわけではない
- すでにTransit Gateway配下に多数のリソースがある場合、Cloud WANを導入するメリットは？
- Cloud WANのメリットはTGWの設定・管理負荷の減らせる点。大規模の既存環境がある場合、移行手順は工夫が必要（そのままでもいいかも）
- DXをCloud WANに繋ぐ方法は？
- 現状Transit Gatewayをホップすることで接続可能ではある
- TGWと使い分けに迷った場合はどうすればいいか？
- 新規の場合、リージョン数やルーティングが複雑でない場合はTGWでもいいかも。大規模になるとCloud WANの方が楽。複数TGWでループ誤課金…みたいなことも防げる
- 既存TGWがある場合、複数TGWのメッシュをやめたい場合に有用
- VPCルーティングや経路フィルター的なメリットはあるか？
- そこはTGWと変わらない（Cloud WANも中身はTGWのため）
AWS Transit Gatewayハンズオン
ハンズオン内容は割愛しますが、TGWの使い方が非常に分かりやすいセッションでした。
以下補足。
- TGWを一言でいうと「リージョナルのL3ルーター」のようなもの
- AWS経由の通信の場合、ソースIPを固定できないことがあるためセキュリティ要件によっては注意
- TGW ENI用にサブネットを分ける理由：VPC着弾後に最初に参照されるルートテーブルをアタッチできるように（例：NAT GW用の別サブネットにルーティングするなど）。NACLを使い分けたい場合にも必要
AWSネットワークを守るファイアウォールの設計パターン
こちらはSAの山下さん、山田さんより。
選択肢① Security Group / Network ACL（セグメンテーション・アクセス制御）
- 無償のVPC基本機能。
- SG：5タプルのステートフルなノード通信制御
- NACL：5タプルのステートレスな通信制御。サブネット単位で設定する（内部通信には使えない）
選択肢② Network Firewall（ファイアウォール）
- マネージドFW。VPC内にエンドポイントとして配置できる
- ステートフル/ステートレス両方のパケットフィルターに対応
- 作成手順
- FW用のサブネットを作成してエンドポイントを配置する（専用サブネットを推奨）
- FWルールを設計する。AWSマネージドルールの利用も可能
- ルートテーブルを設定してこのサブネットを通過するように設定する
- マネージドルールグループ（IPS/IDS機能）：ドメインリストや脅威シグネチャに対応
- 料金：エンドポイント時間＋トラフィック従量で課金。
選択肢③ Gateway Load Balancer（3rdアプライアンス）
- ホスト型：マケプレで購入しEC2でデプロイ
- GWLBは上記ホスト型のEC2を収容しスケール可能にする
- FWaaS型：対象の通信を3rd環境へ転送して検査
- 3rdソリューションへ対しても、既存VPCからGWLBエンドポイント経由で転送可能
- FWaaS型のほうがユーザーの管理負荷を減らしやすいが、他社AWSアカウントへ通信転送が必要
使い分けまとめ
- シンプルな機能で十分であればAWS NWFWが向く
- 慣れた既存製品がある場合などはホスト型も検討
ユースケースとアーキテクチャ
- VPC内で通信するパターン
- NWFWやGWLBのエンドポイントを専用サブネットに配置し経由させる
- マルチアカウント/VPCをTGWで集約するパターン
- FW専用VPCを作成し、経由させるとよい
- DXやS2S VPNを組み合わせる場合も同様
- インターネット宛ての通信も同じ専用VPCで集約するとよい
- マルチAZ構成の場合
- NWFW/GWLBのエンドポイント用サブネットはマルチAZ化すべし
- TGWのアタッチメントはアプライアンスモードを有効にすること
QA
- Squid等の代替でNWFWを採用するとヘッダをいじるとバイパス出来てしまうケースがある？
- 認識どおり。許容できない場合はSNIベースではなく3rdソリューション等の検討を推奨
- ステートフル/レスなルールの使い分けは？
- 今は基本的にステートフルルールの利用を推奨。
※参考記事
柔軟にマイクロサービスを運用管理する － Amazon VPC Lattice基本のキ
注目のLatticeセッション！ SA須藤さんより。
そもそも、マイクロサービスがなぜ必要か？
- 従来は一つの巨大なアプリケーションが多数の機能を持っていた（＝モノリス）
- モノリスの課題：開発の遅さ（内部機能の相互依存）、変更時の影響範囲、技術選定の不自由さ、など
- 独立した複数のサービスでソフトウェアを構成するマイクロサービスが登場した
- 各サービス間はネットワーク経由で連携させる必要あり
- NW的な課題が出現：疎通性の確保、宛先IPの探し方、負荷分散、認証認可
- これをAWS的に解決する従来のアプローチ
- VPCピアリングやTGW：L3でNW接続しSGで制御する。IP重複がNGで、管理が煩雑になる課題あり
- PrivateLink：IP重複はOKとなるがNLB作成や個々のSG・IAM設定が大変になる場合も
- 登場人物の整理
- NW管理者：統制しつつ開発者に自由を与えたい。中央管理がしたい
- 開発者：NWを意識したくない。担当サービスのトラシューに必要な情報は見たい
- Latticeは上述の2ロール双方にメリットをもたらす新サービス
- 管理者：中央管理が可能
- 開発者：NW設計が不要
VPC Latticeの概要
- VPCをまたがるHTTP/S通信を中継するサービス
- ルートテーブルが設定不要
- CIDR重複OK
- 一元的にアクセス制御できる
- 構成要素
- サービス：個々のコンポーネントを指す。
- サービスネットワーク：上述のサービスを束ねる。各サービスが所属するVPCを関連づける
- 各VPCは一つののサービスネットワークにしか所属できないので注意
VPC Latticeの機能
- 負荷分散
- Latticeの「サービス」はALBとソックリな仕組み。
- サービス内にリスナーを作成し、ターゲットグループを複数設定できる
- 認証とログ管理
- サービスネットワーク、サービスそれぞれの単位でIAM認証ポリシーを設定できる
- アクセス元のVPCでサービス配下のリソースにセキュリティグループを設定してアクセス制御できる
- ログもサービスネットワーク、サービス各単位で出力設定できる
QA
- Lattice以外にも通信ログを統合管理できそうなAWSソリューションが複数あるが、使い分けは？
- まだ事例も多くないのでぜひ試してみてほしい
おわりに
ネットワーク特化ということで、参加者はエンプラSI系の方が多い印象でした。
ランチ・お菓子付きの手厚いセミナーで懇親会もあり、大変素晴らしい機会でした！