この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、佐伯です。
引き続きre:Invent 2018に参加しています。NET301 Best Practices for AWS PrivateLink のセッションに参加しましたので、レポートとなります。ざっくりとした内容ですが、PrivateLinkの様々なユースケースやベストプラクティス、顧客の事例についてとなります。
概要
AWS PrivateLink is a networking service that allows you to increase the security, scale, and resiliency of your services. In this session, we review the way AWS PrivateLink works, best practices, and how to increase availability and security. We review how to set up both the consumer and provider sides of PrivateLink, use cases, and interoperability with other AWS services. Whether you want to consume services in a more scalable and private way or you have services you want to share with others, we help you understand best practices for AWS PrivateLink.
スピーカー
Puneet Konghot - Senior Product Manager, EC2, AWS
James Devine - Solutions Architect, AWS
Paul Revello - Cloud Architect, HSBC
アジェンダ
- PrivateLinkについて
- ユースケース
- ベストプラクティス
- カスタマーユースケース: HSBC
PrivateLinkについて
なぜPrivateLinkが必要なのか
- VPC間でのプライベート通信が必要なケースがある
- ユーザーは多くのVPCを管理している場合がある
- VPCピアリングではIPアドレス重複が起こらぬようにIPアドレス管理が必要
- ルーティングの管理も必要
- プライベートIPでAWSサービスへのアクセスが必要なケースがある
- そもそもインタネットゲートウェイをなくしたいがAWSサービスにアクセスするので必要などのケースもあり
VPCにサービスを提供する
サービスプロバイダーがサービスコンシューマーへVPC間でサービスを提供できる
- 以下、2つの重要なクラウドコンセプトを取り入れている
- Virtual Private Cloud(VPC): プライベートネットワークはインターネットと分離できる
- Software delivered as a service: プロバイダーが所有・運営し、消費者(コンシューマー)は消費する
- PrivateLinkを利用することでインターネットを経由することなくサービスを利用できる
PrivateLinkとは
- コンシューマーVPCとプロバイダーVPC間のサービスリンク
- コンシューマーVPCのインタフェースVPCエンドポイント
- 1つまたは複数のENI
- リージョンとAZレベルのDNS名
- プロバイダーVPCのサービスフロントエンドとしてのNLB
- VPCエンドポイントとNLBをリンクする
- NAT、VPN、プロキシが不要
- 重複するIPアドレスのVPC間で動作可能
- PrivateLinkでアクセス可能な3種類のサービス
- AWSサービス
- ユーザーが内部サービスをホストする
- サードパーティサービス（SaaS）
ユースケース
既存アプリケーションへの負荷分散
既存アプリケーションへのプロキシ構成
マイクロサービス
オンプレミスからAWS環境へのアクセス
AWSからオンプレミス環境へのアクセス
VPC間でのVPCエンドポイントの共有
クロスリージョン接続
別リージョンへのサービス提供
ベストプラクティス
DNS設計
- アーキテクチャに適したDNSを選択
- PrivateLinkのDNSオプション
- Private DNS nameオプションは自動的にプライベートDNS名を作成する
- AWSがアサインしたパブリックDNSは各インタフェースエンドポイントにDNS名をアサインする
- Route 53のPrivate Hosted ZoneでインタフェースエンドポイントにCNAME/ALIASをつける
- Route 53 Resolverを使用してVPCピアリング/オンプレミスから名前解決可能
PrivateLinkの性質を考慮
- PrivateLinkのデータパスはひとつのAZ内で動作
- VPCエンドポイントのENIは同じAZのNLB ENIへマップされる
- コンシューマーはVPCEリージョナルDNS名を使用したほうが良い
- AZ障害時を考慮
- サービスプロバイダはNLBを全てではないにしてもほとんどのAZにNLBを配置したほうが良い
- クロスゾーン負荷分散を有効化するか検討する
VPCEリージョナルDNS名でのサービスへのアクセス
クロスゾーン負荷分散
サービスプロバイダ - アクセス権限
- 少なくともAWSアカウントレベルでホワイトリストを作成
- 必要に応じて細かく設定する
- パブリックサービスであれば "*" でAWSアカウントを指定ないことも可能
サービスプロバイダ - エンドポイントの受け入れ
- センシティブなサービスであれば接続リクエストを必須にする
- Amazon SNSを使って自動承認ワークフローを作成することも可能
- パブリックサービスであれば自動承認にすることも可能
コスト
- コンシューマー
- 処理されたデータ量(GB)
- VPCエンドポイント料金
- クロスゾーンデータ転送料
- サービスプロバイダー
- NLBの料金
- NLBのクロスゾーンデータ転送料
- PrivateLinkは特別な料金はかからない
- VPCエンドポイントあたりの適切なAZ数を選択する
コストのわかりやすい図
- 紫色の$はコンシューマー側コスト
- 赤色の$はプロバイダー側コスト
カスタマーユースケース
大規模なVPCの共有構成から
PrivateLinkを利用した構成へ
どこからはじめればいいか?
- Greenfield
- 接続ポイントとしてのPrivateLink
- マイクロセグメンテーション/マイクロサービス
- 既存のアプリ
- 接続を解除できる場所を特定
- それをサポートするプロキシ
- サービスのためにNLBを活用
- オンプレミスアクセス
- VPN/Direct Connectを活用する
- リージョン間
- インターリージョンVPCピアリングを活用して他のリージョンに拡張
- 追加したリージョンで段階的にインフラ整備
最後に
プロバイダーとしてPrivateLinkを使ってサービスを提供する場合、サービスへのアクセスはNLBのプライベートIPとなります。NLBはProxy Protocolをサポートしていますが、Proxy ProtocolはL4(TCP)で機能します。よって、一般的なWebサーバー(Apacheなど)だけでは送信元IPアドレスを知ることができませんのでご注意下さい。
3
