この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、つくぼし(tsukuboshi0755)です!
re:Invent2022のセッション Introducing Amazon VPC Lattice: Simplifying application networking を視聴したので、レポートしたいと思います。
セッションの概要
The new Amazon VPC Lattice service gives you a consistent way to connect, secure, and monitor communication between your services. This session provides an overview of the new service and walks through defining and applying policies for network access, traffic management, and monitoring for applications across virtually any compute type. Explore how Amazon VPC Lattice context-specific authentication and authorization can improve your application security posture.
新しい Amazon VPC Lattice サービスは、サービス間の通信を接続、保護、監視するための一貫した方法を提供します。このセッションでは、新しいサービスの概要を説明し、ネットワーク アクセス、トラフィック管理、およびほぼすべてのコンピューティング タイプにわたるアプリケーションの監視に関するポリシーの定義と適用について説明します。Amazon VPC Lattice のコンテキスト固有の認証と承認が、アプリケーションのセキュリティ体制をどのように改善できるかをご覧ください。
スピーカー
- Justin Davies, Principal Product Manager, Amazon
- Sathya Ramaseshan, Principal Product Manager, Amazon Web Services
- Dave Ward, GM of Application Networking, AWS
セッション内容
サービス間通信の必要性
- モノリスなアプリケーションは、システムのモダナイズ化によりマイクロサービスに分割されるようになった
- マイクロサービス化により、サービスのネットワーク設定やアクセス権限を、各々のVPCやアカウントで管理するようになった
- AWSにおけるコンピューティングサービスは、インスタンス/コンテナ/サーバレスと様々な種類が存在する
- マイクロサービス化により、上記のコンピューティングサービスを用いたサービス間通信の制御が複雑になってしまう
現時点のサービス間通信に対するソリューション: 概要と問題点
- ネットワークの面では、Internet Gateway/Transit Gateway/VPC Peering/Private Linkを用いたソリューションが挙げられる。
- サービス間通信の制御には何が必要か？
- サービスディスカバリ
- トラフィックマネジメント
- ロードバランシング
- 認証
- 認可
- オブザーバビリティ
- アプリケーションの面では、Route53/Cloud Map/API Gateway&NLB/ALBを用いたソリューションが挙げられる
- コンテナについては、VPC内の通信/サービスディスカバリ/ロードバランシングは上記のソリューションで解決可能
- トラフィックマネジメント/認証/認可/オブザーバビリティは上記のソリューションでは解決が難しいのでどうするか？
- 一つの方法として、ALBをIngressコントローラーとして扱う事で解決可能
- もう一つの方法として、サービスメッシュ(App Meshまたはenvoy)を使用する事で解決可能
- しかし以上のソリューションを全て組み合わせようとすると、どうしてもネットワーク設定の管理が困難になりがち
- なぜなら運用者と開発者の両者間で、ネットワークレイヤー/アプリケーションレイヤー/セキュリティレイヤーにおいて、解決困難な問題が生じるため
- 運用者側がやりたい事
- 運用者側からの制御を失うことなく、開発者側に権限を与えたい
- 組織のセキュリティ体制を実装および実施するために、一元化されたツールを必要とする
- 開発者側がやりたい事
- ネットワークについてはなるべく扱いたくない
- アプリケーションの最適化とトラブルシューティングに役立つ高度なテレメトリを必要とする
VPC Lattice: 主な特徴と機能
- 運用者と開発者のギャップを埋めるため、Amazon VPC Lattice(プレビュー)が発表された
- アプリケーションレイヤーのプロキシにより、ネットワーク接続を組み合わせる
- VPCとアカウントの間で、自動で接続を取り持つ
- ブルーグリーンデプロイメントを支援する、アプリケーションレイヤーのロードバランシングや加重ターゲットといった高度なトラフィック制御を実施する
- ゼロ・トラスト原則の実装を支援
- IAM との統合: 認証を強制し、独自のサービス間通信に必要となるきめ細やかな承認を実装します。
- インスタンス、コンテナ、サーバーレス全体で一貫したエクスペリエンス
- VPC に直接組み込まれ、AWS サービスとネイティブに統合されているため、コンピューティングタイプを組み合わせて各サービスのニーズを満たすことができます
- Amazon VPC Latticeの主要コンポーネント
- サービス
- サービスネットワーク
- 認証ポリシー
- サービスディレクトリ
- サービスとは
- インスタンス、コンテナー、およびサーバーレスで実行され、リスナー、ルール、およびターゲットグループで構成されるアプリケーションの単位
- サービスネットワークとは
- サービス検出と接続を自動的に実装し、共通のアクセスポリシーとオブザーバビリティポリシーをサービスの集合体に適用するために使用される論理単位の境界
- 認証ポリシーとは
- リクエストレベルの認証とコンテキスト固有の認可をサポートするために、サービスネットワークや個々のサービスに関連付けられるIAMリソースポリシー
- 運用者/開発者の認証ポリシーの例
- サービスディレクトリとは
- 所有しているサービス、または AWS RAMを通じて共有されているサービスの一元的なビュー
- 運用者側のタスク
- サービスネットワークの作成
- アクセス方法及びモニタリング方法の定義
- VPCとサービスの紐付け
- 他アカウントへの共有
- 開発者側のタスク
- サービスの作成
- ルーティング及び認可の定義
- サービスネットワークへの紐付け
- 運用者側のメリット
- 運用者側からの制御を失うことなく、開発者側に権限を与えられる
- セキュリティガードレールを矯正できる
- 一元化されたツールでサービス間通信を監視できる
- 開発者側のメリット
- シンプルなオンボーディング - ネットワークを考慮する必要がない
- インスタンス、コンテナ、サーバレスといったコンピューターサービスを柔軟に選択できる
- 高度なデプロイメントバターン(ブルーグリーン、カナリー等)を支援するためのリクエストレベルのルーティングやロードバランシングを使用できる
- きめ細やかかつコンテキスト特有の認可を使用できる
- 可視性の向上のための詳細なメトリクス及びアクセスログを確認できる
- 設定方法
- Amazon VPC Latticeを用いてサービスを作成
- サービスをサービスネットワークに紐付け
- サービスネットワークをVPCに紐付け
- 各々のVPCはサービスネットワークを1つだけ紐付け可能
- 各々のサービスは多数のサービスネットワークと紐付け可能
- ネットワークレイヤーでの制御
- VPC内のどのリソースがサービスネットワークにアクセスできるかをセキュリティグループを用いて制限できる
- アプリケーションレイヤーでの制御
- サービスネットワークやサービスに認証ポリシーを適用する事で認証・認可を強制する
使用例: VPC Latticeがどのように役立つか
- マルチクラスター、マルチVPCのKubernetesシステムで使用可能
- Kubernetes ゲートウェイ API： ingressからの進化
- 汎用性、表現力、拡張性、役割指向の面でより高度な設計がされている
- マルチクラスター、マルチVPCのKubernetesシステムで、様々なサービス間通信の問題を解消できる
- クラスター更新は支援できるか？→クラスター/VPC間でトラフィックを移せるか？
- 加重ルーティング/ロードバランシング、及びパスルーティングとの併用により、様々なコンピューティングサービスのターゲットと柔軟に通信できる
- VPC Latticeのモデル(開発者側)
- サービスは自身のVPC/アカウントを持っている(この時点ではサービス間通信は行われない)
- 開発者は共有したいサービスを登録する
- AWS RAMを使用する事で、組織または運用者アカウントに対してサービスが共有される
- VPC Latticeのモデル(運用者側)
- 運用者は共通のアクセス許可要件に基づき、サービスをサービスネットワークに紐づける
- 運用者はアクセス許可要件に基づき、サービスネットワークをアカウント毎に共有する
- Amazon VPC Latticeのまとめ
- デフォルトでセキュア: サービスは、サービス ネットワーク内のサービスにのみアクセス可能
- サービス間のすべてのリクエストに認証と承認を強制
- 適切なネットワークスコープによるシンプルな認証ポリシー
- 独自のアクセス要件を持つVPCは、独自のサービスネットワークを使用可能
最後に
今回はAmazon VPC Latticeに関するセッションレポートについて、記載させて頂きました。
AWS上でのマイクロサービスアーキテクチャにおけるサービス間通信を制御するために発表された本サービスですが、個人的にかなり可能性を秘めていると感じてます。
セッション内では複数のKubernetesクラスターでのサービス間通信が使用例として挙げられていましたが、インスタンス/コンテナ/サーバレス全てのサービス間通信を管理可能ので、応用の幅はかなり広そうです。
なお2022年12月時点では、米国西部 (オレゴン) リージョンにてプレビュー版のみ利用可能なので、ご注意ください。
またAWS公式でも、Amazon VPC Latticeに関する記事が出ているので、ぜひご参照ください。
以上、つくぼし(tsukuboshi0755)でした!
2
