[レポート] NET301: AWS PrivateLinkのベストプラクティス #reinvent

re:Invent 2018に参加しています。NET301 Best Practices for AWS PrivateLink のセッションに参加しました。PrivateLinkの様々なユースケースやベストプラクティス、顧客の事例などが主な内容です。

AWS re:Invent 2018

#AWS PrivateLink

#AWS

佐伯航

2018.11.30

この記事は公開されてから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アドレスを知ることができませんのでご注意下さい。