AWS PrivateLinkの使い方と注意点 ～VPCピアリングとの使い分け～

2018年5月11日2019年11月3日Amazon Web Services,AWS PrivateLink

プラットフォーム技術部の小林正彦です。

本記事ではVPCサービスとして提供されているPrivateLinkについて、2017年11月のリリース以降エンハンスされた機能も含めた現行機能の整理と、PrivateLinkの使いどころや注意点などをまとめます。

最後に、実際にPrivateLinkを使ってプライベートサブネットからインターネットを経由せずにKinesisに対してAPIコールを実行する手順を掲載します。

PrivateLinkって何？

PrivateLinkとは「AWSへのAPIアクセスをインターネットを経由せずに行えるインターフェースタイプのVPCエンドポイント」です。

PrivateLinkを使うことでインターネットに出る必要がなくなるため「IGW、NATデバイス、VPNコネクション、パブリックIP」の導入・設定が不要になり、環境設計が必要なコンポーネントを減らすことができます。また、セキュリティ要件の厳しいシステムやクローズドな環境での稼動が必須となるシステムをAWS上に構築する際に役立ちます。

そもそもVPCエンドポイントって何？

さきほどのPrivateLinkの説明の中で、「PrivateLinkはインターフェースタイプのVPCエンドポイント」と書きましたが、そもそもVPCエンドポイントとは何でしょうか。

VPCエンドポイントとは、VPCと他のサービス間の通信を可能にするVPCコンポーネントで、その実態は仮想デバイスです。VPCエンドポイントをVPCに作成することで、VPC内のインスタンスとVPC外のサービスとで通信ができるようになります。（詳細はVPCエンドポイントのガイドを参照してください。）

VPCエンドポイントは下記の2つのタイプが提供されています。

• インターフェースタイプ
  • PrivateLinkと呼んでいる
  • 実態はプライベートアドレスをもつENI
• ゲートウェイタイプ
  • ルートテーブルで送信先に対するターゲットとして指定する

二つのタイプのVPCエンドポイントを使用した構成例を下図に示します。タイプによって、インスタンスとサービス間での通信経路が異なります。

ゲートウェイタイプを使用する場合はルーティング設定が必要です。図に示したルートテーブルにあるように、Destinationとして「使用するサービスのエンドポイント（この場合は東京リージョンのS3のpl-id（プレフィックスリストID））」、Targetとして「作成したVPCエンドポイントのID(vpce-id)」を指定します。このルートを設定することでVPC内部からVPC外のサービスへの通信ができるようになります。

タイプによる違いを整理：ゲートウェイとインターフェース

ゲートウェイタイプとインターフェースタイプで異なる制限を下表に整理します。

カテゴリとサービス一覧

タイプによって利用できるカテゴリとサービスが異なりますので、それぞれ利用できるものを整理します。

カテゴリ一覧

まずはカテゴリの一覧です。2018年5月時点で利用できるカテゴリは下表のとおりです。

サービス一覧

つぎは各カテゴリで利用可能なサービスについて整理します。

AWSサービス

まず1つめの「AWSサービス」カテゴリでは、AWSプリンシパルなサービスが提供するエンドポイントを選択できます。

下表に、現時点で提供されているサービスと対応するエンドポイントタイプ、エンドポイントをまとめています。

※ ”amazon”、”aws”という語は省略してサービス名順に並べています

昨年11月のre:invent 2017で紹介されたサービスや、2018年になって新たに追加されたサービスも記載しています。いずれも東京リージョンで利用可能なサービスです。VPCエンドポイントに対応するサービスはどんどん追加されていきますので、VPCエンドポイントを使用する際にはその時点でどのサービスが利用可能なのかを確認するようにしましょう。

なお、公式のVPCエンドポイントのガイドに掲載されているサービス一覧表は最新の状態にアップデートされていないため、2018年5月時点ではこちらの表に記載の内容が正しいです。ご注意ください。

独自サービス

2つめは「独自サービス（VPCエンドポイントサービス）」です。

マネジメントコンソールでは「サービスを名前で検索」というカテゴリで表示されています。インターフェイスタイプのエンドポイントが利用可能なカテゴリです。

独自に作成したサービスをVPCエンドポイントサービスとして公開し、AWSネットワークに閉じて利用することができます。利用するにはNLBの作成が必須です。

独自サービスを利用するために図に示したように3つのステップで設定していきます。①独自アプリケーションの前段にNLBを配置して、②NLBを指定してVPCエンドポイントサービスを作成します（例：com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxxxxxxxx）。③そのVPCエンドポイントサービスに接続するインターフェースVPCエンドポイントを作成します。エンドポイントサービスの作成にはNLBの関連付けが必須となりますのでご注意ください。

図に示したように、PrivateLinkとNLBのVPCエンドポイントサービスを使用することで異なるVPC間の通信が可能になります。となると、VPCピアリングとの使い分けについても気になると思いますがそちらについては「VPCピアリングとの違い」の節でまとめていますので参考にしてください。

マーケットプレイスサービス

3つめはマーケットプレイスサービスです。

マネジメントコンソールでは「ご使用のAWSマーケットプレイスサービス」として表示されています。このカテゴリは2017年11月に追加されたカテゴリです。AWSマーケットプレイスが提供するサービスを利用できます。対応するタイプはインターフェイスタイプのみです。マーケットプレイスでSaaSとして提供されているサービスに対してVPCエンドポイントを作成することで、インターネットを介さずにSaaSを利用することができます。

AWS Marketplace で AWS PrivateLink が利用可能に

AWS Marketplace で AWS PrivateLink が利用可能に メインコンテンツに移動 アマゾン ウェブ サービス ...

 https://aws.amazon.com/jp/about-aws/whats-new/2017/11/aws-pr...

2018年5月時点で利用可能なVPCエンドポイント対応のマーケットプレイスサービスは下表のとおりです。

セキュリティ関連のSaaSが利用可能になっているようです。こちらも随時対応サービスが拡張されていくと思いますので、VPCエンドポイントを使用したSaaS利用を検討している方はチェックしておきましょう！

VPCピアリングとの違い

独自アプリケーションのVPCエンドポイントサービスを作成することができるようになり、異なるVPC間での通信が可能になりました。「異なるVPC間での通信」という観点で、PrivateLink機能を利用するべきか、VPCピアリングを利用するべきかを検討する際の参考情報として下表に機能の違いを整理しました。

ユースケース

上記の比較を受けて、PrivateLinkはどのような状況で使用するべきでしょうか。

独自のサービスにクローズドな環境で通信をしたい場合はPrivateLinkが適しているかもしれません。また、そのサービスがマーケットプレイスでエンドポイントサービスとして提供されているものである場合はPrivateLinkを選択しましょう。

Direct Connect接続経由のエッジツーエッジルーティングを実現したい場合は、VPCピアリング接続では実現できないのでPrivarteLinkを選択する必要があります。

VPCのCIDRブロックが重複している場合も、VPCピアリング接続での実現ができないのでPrivateLinkを使用します。すでに存在するVPC同士を接続する場合は、CIDRブロックを確認してVPCピアリング接続が可能かどうかを確認しましょう。

現在のネットワーク構成やセキュリティ要件、通信要件からはVPCピアリングとPrivateLinkのどちらを使用しても大差ないという状況であれば、設計・構築・運用の作業の大変さ、という観点でどちらがいいかを検討するのもよいでしょう。

VPCピアリングを使用する場合は、ルートテーブル/NACL/SGでアクセスを限定していくので詳細な制御ができる反面、設計や構築作業、構築後のメンテナンスが複雑になってしまうかもしれません。PrivateLinkを使用することで通信経路が可視化され構成図がシンプルになる可能性もあります。現行の運用方法に即して選択することをおすすめします。

PrivateLinkを使ってみる

実際にPrivateLinkを使ってみます。今回は下図のような簡易な構成を作成していきます。

プライベートサブネット内のインスタンスからインターネットを経由しないでKinesisのエンドポイントにAPIアクセスをしてみます。

PrivateLinkの作成

VPCサービスから「エンドポイント > エンドポイントの作成」と選択します。

サービスカテゴリは「AWSサービス」を選択します。

表示されたサービス名の一覧から「Kinesis-streams」サービスを選択します。（東京リージョンで作業をしているので、com.amazonaws.ap-northeast-1.kinesis-streamsと表示されています）

つづいて、VPC、AZ、プライベートDNS設定、セキュリティグループを選択していきます。

VPCをプルダウンから選択すると利用可能なAZとサブネットが表示されるので、VPCエンドポイントを作成するサブネットを選択します。

プライベートサブネット内のインスタンスから、AWS CLI によってVPCエンドポイントに対してHTTPS で API コールを実行します。そのため、VPCエンドポイントのセキュリティグループには、TCP ポート 443 でのインバウンド接続のみ有効にしたルールを設定します。

セキュリティグループのインバウンドルール

すべての項目を設定して「エンドポイントの作成」をクリックし、エンドポイント作成の完了です。

コンソールでエンドポイント画面を見ると先ほど作成したVPCエンドポイントが表示されています。

詳細情報欄にはDNS名として「サービスデフォルトのDNSホスト名」と「エンドポイント固有のDNSホスト名」の2種類のDNSホスト名が表示されています。

表示されているDNSホスト名のどちらを使用するかは、プライベートDNSの設定〔有効/無効〕によって変わってきます。下表に示すように、プライベートDNSの設定値によって、各DNSホスト名を指定した場合の経路が変わります。

プライベートDNSを有効にした場合はどちらのDNSホスト名を指定してもVPCエンドポイントを経由します。つまり、パブリックサブネット上のインスタンスがサービスデフォルトのDNSホスト名を指定した場合でもインターネットを経由せずにAPIアクセスをすることができます。

プライベートDNSを無効にした場合は、どこからアクセスするかによってインターネットを経由するか、そもそも疎通ができない、VPCエンドポイントを経由する、というように結果が異なってきますので注意が必要です。

プライベートDNSを有効にする場合はVPC 属性のenableDnsHostnames およびenableDnsSupport を true に設定する必要がありますので、設定を変更する際は「VPCのDNSサポートを更新する」を参照して作業を行ってください。

PrivateLink経由でKinesisにAPIアクセスをしてみる

プライベートサブネット内のインスタンスからさきほど作成したPrivateLinkを経由して、Kinesisに対してAPIコールを実行してみます。

準備

パブリックサブネットに踏み台サーバを設置し、踏み台サーバからプライベートサブネット内のインスタンスサーバへログインします。ログインしたサーバでaws configureを行い、AWS CLIコマンドを実行する環境を整備します。（手順は割愛します）

プライベートサブネット内のインスタンスでAWS CLIコマンドを実行する準備ができましたので、Kinesisに対して基本的なストリームオペレーションを実行していきます。

ストリームの表示

まず、現時点で存在するストリームを表示してみます。–endpoint-url オプションでVPCエンドポイント固有DNSホスト名を指定します。

今の時点ではストリームは何も作成されていません。

$ aws kinesis list-streams --endpoint-url https://vpce-xxxxxxxxxxxxxxxxxx-xxxxxxxx.kinesis.ap-northeast-1.vpce.amazonaws.com
{
"StreamNames": []
}

ストリームの作成

つぎに、create-streamコマンドを実行してFooストリームを作成します。さきほどと同じように–endpoint-url にエンドポイント固有のDNSホスト名を指定しています。

create-streamコマンドを実行後に結果を確認すると、FooストリームのStreamStatusがACTIVEになっていることからストリームを使用する準備ができたことがわかります。また、今回リクエストした単一のシャードに関する情報が表示されています。

$ aws kinesis create-stream --stream-name Foo --shard-count 1 --endpoint-url https://vpce-xxxxxxxxxxxxxxxxxx-xxxxxxxx.kinesis.ap-northeast-1.vpce.amazonaws.com
$ aws kinesis describe-stream --stream-name Foo --endpoint-url https://vpce-xxxxxxxxxxxxxxxxxx-xxxxxxxx.kinesis.ap-northeast-1.vpce.amazonaws.com
{
"StreamDescription": {
"KeyId": null,
"EncryptionType": "NONE",
"StreamStatus": "ACTIVE",
"StreamName": "Foo",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "340282366920938463463374607431768211455",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber": "49584239740445610367505881482844466786565739057732648962"
}
}
],
"StreamARN": "arn:aws:kinesis:ap-northeast-1:xxxxxxxxxxxx:stream/Foo",
"EnhancedMonitoring": [
{
"ShardLevelMetrics": []
}
],
"StreamCreationTimestamp": 1525684537.0,
"RetentionPeriodHours": 24
}
}

ストリームの存在確認

list-streams コマンドを使用してストリームを表示すると、先ほど作成したFooストリームが存在することが確認できました。

$ aws kinesis list-streams --endpoint-url https://vpce-xxxxxxxxxxxxxxxxxx-xxxxxxxx.kinesis.ap-northeast-1.vpce.amazonaws.com
{
"StreamNames": [
"Foo"
]
}

つづいて、コンソール画面でKinesisのダッシュボードの状態を確認してみます。こちらにも先ほど作成したFooストリームが表示されています。

プライベートサブネット内のインスタンスからKinesisに対してAPIコールを実行できました。

補足

今回はプライベートDNSを「有効」にしているので、VPCエンドポイント固有のDNSホスト名ではなくサービスデフォルトのDNSホスト名を指定しても同じ結果が得られます。

デフォルトのDNSホスト名で解決されるので、–endpoint-url を指定しなくてもさきほどと同じ結果が得られます。

$ aws kinesis list-streams
{
 "StreamNames": [
 "Foo"
 ]
}

あるいは、–endpoint-url にデフォルトのDNSホスト名を指定しても同様の結果となります。

$ aws kinesis list-streams --endpoint-url https://kinesis.ap-northeast-1.amazonaws.com
{
 "StreamNames": [
 "Foo"
 ]
}

プライベートサブネット内のインスタンスから他のサービスに対してAPIコールを実行できないことも確認してみます。

今回はKinesisを利用するエンドポイントのみを作成しているので、他のサービスに対してAPIコールを実行してもアクセスはできないはずです。

試しにEC2に対してAPIコールを実行してみるとタイムアウトエラーで終了しました。EC2用のVPCエンドポイントを作成していないので接続できないことが確認できました。

$ aws ec2 describe-vpc-endpoints

HTTPSConnectionPool(host='ec2.ap-northeast-1.amazonaws.com', port=443): Max retries exceeded with url: / (Caused by ConnectTimeoutError(<botocore.awsrequest.AWSHTTPSConnection object at 0x7f844cee0d10>, 'Connection to ec2.ap-northeast-1.amazonaws.com timed out. (connect timeout=60)'))

まとめ

PrivateLinkを利用する際の情報を整理し、実際にプライベートサブネット内のインスタンスからKinesisに対してインターネットを経由することなくAPIコールを実行できることを確認しました。

VPCエンドポイントとは

VPCと他のサービス間の通信を可能にするVPCコンポーネント（仮想デバイス）です。VPCエンドポイントをVPCに作成することで、VPC内のインスタンスとVPC外のサービスの間で通信ができるようになります。

VPCエンドポイントには2つのタイプがある

VPCエンドポイントにはインターフェイスとゲートウェイタイプの2種類があります。タイプによって制限や利用可能なサービスが異なるので利用したいサービスに対応しているエンドポイントのタイプと、タイプの制限を確認しましょう。

VPCエンドポイントのサービス内容は日々エンハンスされていくので、現時点でどのサービスが利用可能なのかを事前に確認しましょう。

VPCピアリングとの使い分け

PrivateLinkのユースケースを検討する際にはVPCピアリングとどう使い分けるのかが問題になると思います。両VPCのネットワーク構成や利用用途、あるいは現行の運用方法などを考慮してVPCピアリングとPrivateLinkのどちらを利用するのが適切であるかを検討しましょう。