導入
ネットワークがつながっても、名前解決(DNS)がオンプレとAWSでバラバラのままでは、アプリケーションは相手を見つけられません。ハイブリッド構成の最後のピースが、DNSの統合です。
説明
デフォルトでは、VPC内のリソースは Amazon provided DNS(VPC内蔵のリゾルバ、.2アドレス) を使って名前解決しますが、これはそのVPC内のプライベートホストゾーンやAWSのパブリックサービスしか解決できません。オンプレのDNSサーバーが管理する名前や、逆にオンプレ側からAWSのプライベートホストゾーンを引きたい場合には工夫が必要です。
そこで使うのが Route 53 Resolver の2種類のエンドポイントです。
| エンドポイント | 役割 | 通信の向き |
|---|---|---|
| インバウンドエンドポイント | オンプレからAWS側の名前解決を受け付ける | オンプレ → AWS |
| アウトバウンドエンドポイント | AWSからオンプレのDNSへ問い合わせを転送する | AWS → オンプレ |
アウトバウンドエンドポイントは、Resolver ルール と組み合わせて使います。「特定のドメイン(例 corp.example.internal)への問い合わせは、オンプレのDNSサーバーに転送する」というルールをVPCに関連付けることで、AWS上のアプリケーションがオンプレの社内システムを名前で解決できるようになります。
flowchart LR
subgraph OnPrem["オンプレミス"]
ODNS["社内DNSサーバー"]
end
subgraph VPC["VPC"]
IN["インバウンド<br/>エンドポイント"]
OUT["アウトバウンド<br/>エンドポイント"]
APP["AWS上のアプリ"]
end
ODNS -- "AWS側の名前を問い合わせ" --> IN
APP -- "corp.example.internal?" --> OUT
OUT -- 転送 --> ODNS
複数VPC・複数アカウントで同じResolverルールを使い回したい場合は、Resource Access Manager(RAM) でルールを共有するか、TGW経由でDNSクエリを中継する構成が一般的です。
具体例
ネットワークとVPNはつながったのに、アプリが「相手の名前を引けない」というハイブリッドの最後の壁を、Route 53 Resolverで解消します。ある会社の2つの困りごと:
- AWS上の新アプリが、オンプレの社内システム
db.corp.example.internalを名前で呼びたい … VPC内蔵のリゾルバはこの社内ドメインを知らない。→ アウトバウンドエンドポイント+Resolverルール「corp.example.internalへの問い合わせはオンプレDNSへ転送」を設定。AWS → オンプレの向き。 - 逆に、オンプレの既存システムが、AWS上のプライベートホストゾーンの名前を引きたい … → インバウンドエンドポイントを置き、オンプレDNSからの問い合わせをAWS側で受け付ける。オンプレ → AWSの向き。
これで両方向の名前解決が通り、ハイブリッド構成が完成します。混同しやすいので矢印の向きで覚えます——「オンプレからAWSへ入ってくる=インバウンド」「AWSからオンプレへ出ていく=アウトバウンド」。複数VPCで同じルールを使い回すならRAMで共有します。
読んでみよう
「オンプレとAWSの両方のリソースを、名前で相互に解決したい」という要件は、ハイブリッド構成の総仕上げとして頻出です。「オンプレ→AWSはインバウンド」「AWS→オンプレはアウトバウンド」という向きの対応関係を混同しないように、矢印の向きとセットで覚えてください。