この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、大前です。
Route 53 Resolver Rule を AWS Resource Access Manager（以下 RAM） で他アカウントに共有する機会がありましたので、ブログに残したいと思います。
構成
今回試した構成の概要は以下です。
- アカウント A
- Route 53 Resolver Outbound Endpoint から転送される DNS クエリを解決する EC2（「pasuta.local.」を管理）
- Route 53 Resolver Outbound Endpoint の設定
- Route 53 Resolver Rule の設定
- RAM で Route 53 Resolver Rule をアカウント B に共有
- アカウント B
- DNS クエリを発行する EC2
Route 53 Resolver Outbound Endpoint の転送先として DNS の問い合わせを処理する EC2 を指定し、Route 53 Resolver Rule で "pasuta.local." への問い合わせを Outbound Endpoint に転送する様に設定します。
やってみた
0.事前準備
まず、アカウント A 上に DNS クエリを受け付ける DNS サーバを用意します。
用意に当たっては、以下ブログの手順を参考に Amazon Linux 2 で EC2 を作成し、Unbound をインストール+設定しました。
作成した conf ファイルは以下です。"web.pasuta.local." に対する A レコードを提供します。
server:
interface: 0.0.0.0
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/16 allow
do-ip6: no
local-zone: "pasuta.local." static
local-data: "web.pasuta.local. IN A 10.0.0.51"
local-data-ptr: "10.0.0.51 web.pasuta.local."アカウント B にも、Amazon Linux 2 で EC2 を 1台立てておきます。特に初期設定は不要です。
当たり前ですが、この時点でアカウント B の EC2 から web.pasuta.local. に対して名前解決を行っても何も帰ってきません。
イメージとしては、今は下記の状態です。
1. Route 53 Resolver Outbount Endpoint の作成
Route 53 Resolver Outbount Endpoint を作成していきますが、先にエンドポイントに割り当てるセキュリティグループを作成しておきます。
今回は以下で作成しました。
| タイプ | プロトコル | ポート範囲 | ソース | 説明 |
|---|---|---|---|---|
| DNS(TCP) | TCP | 53 | 10.0.0.0/16 | アカウントAのVPC |
| DNS(UDP) | UDP | 53 | 10.0.0.0/16 | アカウントAのVPC |
| DNS(TCP) | TCP | 53 | 172.31.0.0/16 | アカウントBのVPC |
| DNS(UDP) | UDP | 53 | 172.31.0.0/16 | アカウントBのVPC |
Route 53 > リゾルバー > アウトバウンドエンドポイント から「アウトバウンドエンドポイントの作成」をクリックし、各パラメータを設定していきます。
- エンドポイント名 ... 任意
- 当該リージョンの VPC ... アカウント A の VPC
- このエンドポイントのセキュリティグループ ... 上記にて作成したセキュリティグループ
IP アドレスの設定は 2AZ 分行います。
- アベイラビリティーゾーン ... 任意
- サブネット ... 任意
- IP アドレス ... 自動選択された IP アドレス
作成後、ステータスが「実行中」になれば OK です。
リソースの状態は以下図の通りです。Outbound Endpoint ができました。
2. Route 53 Resolver Rule の作成
Route 53 > リゾルバー > ルール から「ルールの作成」をクリックし、各パラメータを設定していきます。
- 名前 ... 任意
- ルールタイプ ... 転送
- ドメイン名 ... pasuta.local.
- このルールを使用する VPC ... アカウント A の VPC
- アウトバウンドエンドポイント ... 先ほど作成したエンドポイント
ターゲットの IP アドレス には Unbound を設定した EC2 のプライベート IP を指定します。実際の環境では、オンプレミス側のアドレスを指定する事が多いかと思います。
アカウント A 上で Route 53 Resolver Rule の作成まで完了しました。
試しに、この状態でアカウント A の VPC 上に EC2 を立てて "web.pasuta.local." を問い合わせて見るとちゃんと結果が帰ってきます。
3. RAM で Route 53 Resolver Rule を共有する
アカウント A 作業
では、作成したルールをアカウント B でも使える様に、RAM によるリソース共有を設定していきます。
コンソールで RAM を開き、「リソース共有を作成」をクリックします。
- リソース共有の名前 ... 任意
- リソース ... "リゾルバルール" を選択し、先ほど作成したルールをチェック
アクセス許可の付与は特に操作なしで進みます。
- プリンシパル
- 外部とのプリンシパルとの共有を許可
- "AWS アカウント" を選択した状態でアカウント B の ID を入力し、「追加」
今回は検証のためアカウント ID 直指定としていますが、Organizations 環境では共有先として OU などを指定することもできます。
これで共有設定の作成は完了です。「共有プリンシパル」のステータスがずっと "Associating" から変わりませんが、組織外のアカウントに共有する場合は共有先で承認が必要な為です。
アカウント B 作業
アカウント B にて、同じく RAM を開くと、招待がきている事を確認できるので開きます。
招待がきているリソースの詳細を開き、「リソースの共有を承認」をクリックします。これにより、アカウント B にてリソースが利用できる様になります。
今の状態は下図の通りです。ルールをアカウント B に共有するところまで完了しました。
4. 共有された Route 53 Resolver Rule を VPC に関連付ける
最後に、共有されたルールを VPC に適用します。
アカウント B にて Route 53 Resolver Rule を開くとアカウント A から共有されたルールが表示されています。
詳細を開き、「VPC を関連付ける」からルールを適用したい VPC を選択し、「追加」します。
ステータスが "完了" になれば OK です。これで一通りのリソース設定が完了しました。
5. 動作確認
一通りの設定が完了したので、アカウント B 上の EC2 から "web.pasuta.local." に名前解決をしてみると、無事に名前解決の結果が帰ってきました！from server 172.31.0.2 の部分からも、アカウント B の VPC に存在している Route 53 Resolver 経由で名前解決できていることがわかります。
おわりに
RAM を使用して Route 53 Resolver Rule をアカウント間で共有し、名前解決をしてみました。オンプレミスと絡んだマルチアカウント環境において DNS 管理を特定アカウントに集約したい場合などに役立つ手順だと思います。また、DNS 管理を行なっている VPC とピアリングや Transit Gateway で接続する必要がない点もポイントだと思います。
Route 53 はコンポーネントが多く、動作や役割を理解しづらい部分もありますが、少しは仲良くなれた気がします。
作成したエンドポイントの削除はお忘れなく。
以上、AWS 事業本部の大前でした。
4
