1. はじめに
- 仕事上で以下のような初めての要件があったため、やったことを整理しておく。
- 基本的には、Privetelink（エンドポイントサービス）の、「エンドポイントサービスのプライベートDNS名の有効化」機能を使ってみた話。
2. 要件
- Provider(Webサービスを提供)は、AWS東京リージョン/大阪リージョンのマルチAct/Act構成で存在している。
- Consumerは、AWS東京リージョンに存在している。
- ConsumerはProviderの東京/大阪リージョンそれぞれとPrivatelink接続する。
- Provider側で、Consumerがどちらのリージョンにアクセスするのか制御したい。（例：普段は東京・大阪両方にアクセスさせるが、メンテナンス時や障害時には片寄せするなど）
3. 構成図
4. 設計概要
- 普通に Consumer(東京)-Provider(東京)、Consumer(東京)-Provider(大阪)間をPrivatelinkした場合、Consumer側でどちらのエンドポイントにアクセスするのかを制御する必要がある。
- Provider側で東阪それぞれのエンドポイントサービスにプライベートDNS名を付与し、その上でProvider側のRoute53プライベートホストゾーンにて、2つのエンドポイントサービスのプライベートDNS名をまとめるCNAMEレコード（加重ルーティング）を作成する。
- これにより、Consumer側からは1つのFQDNにアクセスすればよくなり、かつ、Provider側では加重の調整により、どちらのエンドポイントにアクセスさせるのかの制御も可能になる。
5. 手順
5.1 前提・事前準備
- Consumer側のAWSアカウントの東京リージョンにVPCを作成する。
- Provider側のAWSアカウントの東京リージョン・大阪リージョンにVPCを作成する。
- Provider側の東京リージョン・大阪リージョンそれぞれで、Internal NLBを作成し、ターゲットにnginxインスタンスを登録する。
- Provider側のAWSアカウントで、パブリックドメイン mksamba-test.net (本記事内で使用する架空のドメイン）を保有しており、パブリックホストゾーンが存在している。
5.2 エンドポイントサービスの作成
- Provider 側で東京・大阪それぞれのエンドポイントサービスを作成する。（以下は東京の手順を記載。大阪も同様に作成する）
- エンドポイントサービスの作成時、「プライベートDNS名を有効化する」にて、「プライベートDNS名をサービスに関連付ける」にチェックを入れて、プライベートDNS名を「tokyo.mksamba-provider.mksamba-test.net」とする。
- エンドポイントサービス自体は作成されるが、ドメインの検証ステータスは「Pending verification」となり、プライベートDNSはまだ使用できない状態。
- Route 53 パブリックホストゾーン「mksamba-test.net」に、以下のレコードを作成し、ドメインの所有者であることを証明する。
- レコード名： エンドポイントサービス作成時に表示された「ドメインの検証名」
- レコードタイプ： txt
- 値： エンドポイントサービス作成時に表示された「ドメインの検証値」
- レコードの作成後、エンドポイントサービスの画面にて、「プライベートDNS名のドメイン所有権を確認」を行う。検証が完了するとステータスが「Pending verification」から「Verified」に変化する。
- Consumer のAWSアカウントからのエンドポイント作成を可能にするため、「プリンシパルを許可」でConsumer AWSアカウントを許可する。
5.3 インタフェースエンドポイントの作成
- Consumer側で、5.2 項で作成したエンドポイントサービスに対してのインターフェースエンドポイントを作成する。（以下は東京側の手順だが、同様に大阪側へも作成する。）
- エンドポイントの作成時は、「プライベートDNS名を有効化」のチェックは外しておく。
- Provider側で接続申請を承諾してもらい、ステータスが使用可能になったら、設定を編集し、「プライベートDNS名を有効化」にチェックを入れる。
- 東京・大阪向けのインターフェースエンドポイントを作成し、それぞれ「プライベートDNS名を有効化」すると、AWS側で管理する隠しホストゾーンのようなものが、Consumer側のVPCに作成される。（マネコンでは見えず、CLIで確認）
~ $ aws route53 list-hosted-zones-by-vpc --vpc-id vpc-xxxxxxxxxxxxxxxx --vpc-region ap-northeast-1
{
"HostedZoneSummaries": [
{
"HostedZoneId": "xxxxxxxxxxxxxxxxxxxxxxx",
"Name": "osaka.mksamba-provider.mksamba-test.net.",
"Owner": {
"OwningService": "vpce.amazonaws.com"
}
},
{
"HostedZoneId": "xxxxxxxxxxxxxxxxxxxxxxx",
"Name": "tokyo.mksamba-provider.mksamba-test.net.",
"Owner": {
"OwningService": "vpce.amazonaws.com"
}
}
],
"MaxItems": "100"
}
~ $
-
これまでの設定で、Consumer側にて、以下のようにインターフェースエンドポイント経由でのアクセスが可能（全て同じ結果になる）
- インターフェースエンドポイントのプライベートIPを指定
- インターフェースエンドポイントの既定のDNS名（vpce-xxxxxxxxxxxxxxxxx-xxxxxxxx.vpce-svc-xxxxxxxxxxxxxxxxx.ap-northeast-1.vpce.amazonaws.comのようなもの）を指定
- インターフェースエンドポイントのプライベートDNS名（tokyo.mksamba-provider.mksamba-test.net）を指定
-
例として、Consumer側のVPC内CloudShellから以下のようにプライベートDNS名を指定してProvider側のnginxへのアクセスが可能。
~ $ curl http://tokyo.mksamba-provider.mksamba-test.net
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
Tokyo!
5.4 プライベートホストゾーンおよびレコード作成とConsumer側への共有
-
これまでの設定で、Consumer側からは tokyo.mksamba-provider.mksamba-test.net を指定して Provider(東京)に、osaka.mksamba-provider.mksamba-test.net を指定して Provider(大阪)にアクセス可能になった。
-
ここからは、Consumer側でcommon.mksamba-provider.mksamba-test.net にアクセスした際、Provider側のレコード設定に従い、tokyoかosakaに振り分けられるようにする。
-
Provider側で、プライベートホストゾーン mksamba-provider.mksamba-test.net を作成する。
-
プライベートホストゾーン内に、加重ルーティングを行うためのレコードを2行作成する。
| レコード名 | タイプ | ルーティングポリシー | 差別化要因 | 値 |
|---|---|---|---|---|
| common.mksamba-provider.mksamba-test.net | CNAME | 加重 | 50 | tokyo.mksamba-provider.mksamba-test.net |
| common.mksamba-provider.mksamba-test.net | CNAME | 加重 | 50 | osaka.mksamba-provider.mksamba-test.net |
- 作成したプライベートホストゾーンをConsumerのVPCに関連付ける。
# Provider側 で関連付けを許可
aws route53 create-vpc-association-authorization \
--hosted-zone-id [作成したホストゾーン] \
--vpc VPCRegion=ap-northeast-1,VPCId=[ConsumerのVPC]
# Consumer側 で関連付けを申請
aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id [作成したホストゾーン] \
--vpc VPCRegion=ap-northeast-1,VPCId=[ConsumerのVPC]
# provider側で 関連付け許可設定を削除（関連付け自体は残る）
aws route53 delete-vpc-association-authorization \
--hosted-zone-id [作成したホストゾーン] \
--vpc VPCRegion=ap-northeast-1,VPCId=[ConsumerのVPC]
- Consumer 側のVPC内CloudShellで、common.mksamba-provider.mksamba-test.net が tokyo/osakaのどちらかに名前解決されることを確認する。
~ $ ping common.mksamba-provider.mksamba-test.net
PING tokyo.mksamba-provider.mksamba-test.net (10.0.141.107) 56(84) bytes of data.
~ $ ping common.mksamba-provider.mksamba-test.net
PING osaka.mksamba-provider.mksamba-test.net (10.0.132.239) 56(84) bytes of data.
- また、Consumer 側のVPCにプライベートホストゾーンが関連付けられていることを確認する。
~ $ aws route53 list-hosted-zones-by-vpc --vpc-id vpc-XXXXXXXXXXXX --vpc-region ap-northeast-1
{
"HostedZoneSummaries": [
{
"HostedZoneId": "XXXXXXXXXXXXXXXXXX",
"Name": "mksamba-provider.mksamba-test.net.",
"Owner": {
"OwningAccount": "XXXXXXXXXXXX"
}
},
{
"HostedZoneId": "XXXXXXXXXXXXXXXXXX",
"Name": "osaka.mksamba-provider.mksamba-test.net.",
"Owner": {
"OwningService": "vpce.amazonaws.com"
}
},
{
"HostedZoneId": "XXXXXXXXXXXXXXXXXX",
"Name": "tokyo.mksamba-provider.mksamba-test.net.",
"Owner": {
"OwningService": "vpce.amazonaws.com"
}
}
],
"MaxItems": "100"
}
6. まとめ
- 「エンドポイントサービスのプライベートDNS名の有効化」機能により、エンドポイントサービスに対して、分かりやすいプライベートDNS名を付与することができる。設定したプライベートDNS名はインタフェースエンドポイントにも付与され、ConsumerはプライベートDNS名でインタフェースエンドポイントにアクセスできる。
- この機能で使うプライベートDNS名のドメインは、なぜか自分が管理するパブリックドメインである必要がある（Privatelinkでプライベートに使うだけなのに...）。
- この機能を使うだけなら、プライベートホストゾーンをConsumer側に共有する必要はない。今回はプライベートゾーンのレコードを用いて、加重ルーティングで東阪の負荷分散するようにしたため、プライベートゾーンをConsumerのVPCに関連付けする必要があった。
7. 所感
- 前から少しだけ気になっていた「エンドポイントサービスのプライベートDNS名の有効化」をついに活用することができてよかった！