AWSで名前解決する技術〜WebサービスでのRoute 53の構成一覧〜

AWSで名前解決する技術 〜WebサービスでのRoute 53の構成一覧〜 NW-JAWS #15 〜改めて振り返るRoute 53〜 村田亜弥 アクセンチュア株式会社

0.自己紹介 村田 亜弥（alichan） 仕事：AWSを用いた公共サービスやメディアサービスの基盤刷新やPoC開発で アプリケーションエンジニア/クラウドエンジニアとして仕事しています。 好きなこと：個人でAWSを用いた個人開発や技術記事執筆/登壇、イベントの 開催等を行なっています。AWSとプログラミングが好きです！ 個人ではalichanという名前で活動しています。 資格：Solutions Architect - Professional ：https://github.com/alichan-69 ：https://zenn.dev/alichan ：https://x.com/alichan0609 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

• https://github.com/alichan-69
• https://zenn.dev/alichan
• https://x.com/alichan0609

1.概要 AWSで名前解決と言えばRoute 53 example.com Route 53 グローバルに分散されたDNSサー バーによる可用性 エイリアスレコードによるAWSサービス へのルーティングの容易性 ドメイン購入、レコード管理、リソース のヘルスチェックを一つのサービスで行 える網羅性 WebサービスでのRoute 53構成パターンを紹介 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

1.概要 Route 53振り返り パブリックホストゾーン 購入したドメイン名と同じパブリックホ ストゾーンが自動で作成される AWS内外へのリソースへのルーティン グや証明書情報等を含んだレコード を登録することができる物 レコード AWS内外へのリソースへのルーティン グや証明書情報等ドメインやサブドメ インへのルーティングに必要な情報を 登録する物 今回使用するのはこちら NSレコード ホストゾーンに割り振られた4つのネー ムサーバー情報が格納されたレコード SOAレコード ドメインに設定されたDNS情報が格 納されたレコード CNAMEレコード あるドメインに対するクエリを別のドメ インにルーティングするレコード エイリアスレコード AWSリソースへのルーティングを簡単 に登録/管理できるレコード Aレコードとして登録される

2.構成パターン一覧 Webサービス構成パターン一覧 ※エイリアスレコードに対応しているサービスを中心に構成 1. Route 53＋CloudFront＋S3、Route 53＋ (CloudFront)＋API Gateway＋Lambda リクエスト 従量課金 ＋ カスタマイズ性 ＝ 2. Route 53＋CloudFront＋API Gateway＋ A サーバーレス ＋ B サーバーレス ＋ リクエスト 従量課金 ＋ C サーバーレス ＋ 時間 従量課金 ＋ D サーバーレス ＋ 時間 従量課金 カスタマイズ性 ＋ ＝ 低 E 時間 従量課金 カスタマイズ性 1. Route53＋(CloudFront)＋Elasitc Beanstalk ＝ ＋ 高 2. Route53＋(CloudFront)＋ALB/NLB＋EC2 サーバー 管理あり ＋ 高 Lambda with Lambda Web Adapter カスタマイズ性 ＝ 1. Route 53＋Amplify 低 2. Route 53＋App Sync カスタマイズ性 53＋（CloudFront）＋ALB/NLB＋ ＝ 1. Route ECS/EKS 高 1. Route 53＋（CloudFront）＋AppRunner

A-1.サーバーレス＋リクエスト従量課金＋カスタマイズ性高の構成パターン Route 53論点：￥ 構成パターン論点： Route 53＋CloudFront＋S3 Route 53＋(CloudFront)＋API Gateway＋Lambda エイリアスレコード1つ API Gateway パブリックホストゾーン Route 53 エイリアスレコード CloudFront Lambda ディストリビューション ディストリビューション分割論点 • ログ分離の必要性 エイリアスレコード２つ • キャッシュの扱いの慎重度…etc S3 API Gatewayへの直接ルーティングもあり • 頻繁なデータ更新によりキャッシュし辛い • AWS WAFのネイティブサポートがある パブリックホストゾーン Route 53 エイリアスレコード エイリアスレコード CloudFront ディストリビューション API Gateway ディストリビューション This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied. S3 Lambda

Route 53論点：￥ A-2.サーバーレス＋リクエスト従量課金＋カスタマイズ性高の構成パターン 構成パターン論点： Route 53＋CloudFront＋API Gateway＋Lambda with Lambda Web Adapter Webフレームワーク製Webサー ビス モノレポ構成の場合の考慮点 • レスポンスに静的資源と動的レスポンスが入り混じる のでCDNキャッシュの設定に慎重さが必要 パブリックホストゾーン Route 53 エイリアスレコード CloudFront ディストリビューション API Gatewayへの直接ルーティングの考慮点 • 静的資源キャッシュのためAPI Gatewayへの直接 ルーティングは要考慮 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied. API Gateway Lambda with Lambda Web Adapter

Route 53論点：￥ B-1.サーバーレス＋リクエスト従量課金＋カスタマイズ性低の構成パターン 構成パターン論点： Route 53＋Amplify Amplify Amplify利用時の考慮点 • 各サービスがAmplify内で管理されるので構成がブラックボックス化しや すい • 最近はWAFのネイティブ統合もされ利用しやすくなってきている パブリックホストゾーン フロントエンド特化Webフレーム ワーク製Webサービス CloudFront Route 53 エイリアスレコード ディストリビューション Amplifyでの名前解決の実装 1. Route 53で購入したドメインをカスタムドメインとしてAmplifyに登録 2. AmplifyがパブリックホストゾーンにAmplify管理下のCloudFront ディストリビューションエイリアスレコードを発行 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

Route 53論点：￥ B-2.サーバーレス＋リクエスト従量課金＋カスタマイズ性低の構成パターン 構成パターン論点： Route 53＋AppSync AppSync利用時の考慮点 • Lambdaを挟まなくてもAppSync内でのスキーマ定義やリゾルバー定義の みでWeb APIを構成可能 • WAFのネイティブ統合もされている • 反面、レスポンスを柔軟に変更しやすいのでCDNキャッシュの扱いを要考慮 AppSync GraphQL GraphQLとサブスクリプション 機能で構成されるWebAPI パブリックホストゾーン CloudFront Route 53 エイリアスレコード ディストリビューション GraphQLエンドポイント リアルタイムエンドポイント AppSyncでの名前解決の実装 1. Route 53で購入したドメインをカスタムドメインとしてAppSyncに登録 2. マネジメントコンソールでRoute53パブリックホストゾーンでAppSync管理 下のCloudFrontディストリビューションにエイリアスレコードを発行 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

C-1.サーバーレス＋時間従量課金＋カスタマイズ性高の構成パターン Route 53論点：￥ 構成パターン論点： Route 53＋（CloudFront）＋ALB/NLB＋ECS/EKS ターゲットをCloudFrontにする場合 • 静的資源を返すフロントエンドサーバーやオブジェ クトストレージが立っている場合、CloudFront ディストリビューションへルーティングを行う ターゲットがCloudFront パブリックホストゾーン Route 53 エイリアスレコード CloudFront ディストリビューション ALB ターゲットがALB パブリックホストゾーン Route 53 エイリアスレコード ターゲットがNLB ECS EKS ALB パブリックホストゾーン NLB ECS ターゲットをALBにする場合 • 基本Webサービスで必要になるURLやリクエス トヘッダでのターゲット切り替え機能やHTTPリク エストのログ取得を行えるALBを使用する ターゲットをALBにする場合 • リクエスト元のIPアドレスを常に固定したい、突 発的な負荷増加の際に暖気運転を行いたくな いといった際にNLBを使用する ECS Route 53 エイリアスレコード EKS EKS This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

D-1.サーバーレス＋時間従量課金＋カスタマイズ性低の構成パターン Route 53＋(CloudFront)＋App Runner AppRunner Route 53論点：￥ 構成パターン論点： App Runner利用時の考慮点 • コンテナがApp Runner内で管理されるので構成がブラックボックス化 しやすい、コンテナカスタマイズやログカスタマイズがしにくい • パイプラインの構成や細かなコンテナ管理をする必要性が無い、WAF のネイティブ統合があるので気軽にコンテナを動かす際には便利 パブリックホストゾーン Dockerコンテナ製Webサービス Route 53 エイリアスレコード AppRunner所有ドメイン App Runnerでの名前解決の実装 1. Route 53で購入したドメインをカスタムドメインとしてApp Runnerに登録し、エイリアスレコード を発行するように設定 2. App RunnerがパブリックホストゾーンにApp Runner所有ドメインのエイリアスレコードを発行 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

Route 53論点：￥ E-1.サーバー管理あり＋時間従量課金＋カスタマイズ性高の構成パターン 構成パターン論点： Route53＋(CloudFront)＋Elastic Beanstalk Elastic Beanstalk利用時の考慮点 • 最近はECS等のコンテナオーケストレーションツールでコンテナ管 理してアプリケーションを動かすことが主流になっている Elastic Beanstalk • クラウドリフト&シフトの文脈でDockerコンテナ化されていない Webサービスを一度EC2上に移動して管理する際に便利 パブリックホストゾーン Application Route 53 エイリアスレコード 仮想サーバー上Web サービス Elastic Beanstalk所有 ドメイン ・・・ Elastic Beanstalkでの名前解決の実装 1. Elastic Beanstalkでアプリケーションを作成後Elastic Beanstalk所有ド メインが発行 2. Route 53からElastic Beanstalkに対してエイリアスレコードが発行される This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

Route 53論点：￥ E-2.サーバー管理あり＋時間従量課金＋カスタマイズ性高の構成パターン 構成パターン論点： Route53＋(CloudFront)＋ALB/NLB＋EC2 EC2 パブリックホストゾーン Route 53 EC2利用時の考慮点 • セキュリティパッチ適用、デプロイプロセス構築やバック アッププロセス構築を自前で行う必要性がある • カスタマイズ性は高く、クラウドリフト&シフトの際に現行 環境の再現を行うのに最適 仮想サーバー上Webサービス Auto Scaling Group エイリアスレコード ALB ・・・・・・ EC2での名前解決の実装 1. Auto Scaling GroupやEC2の前段にALBを配置 2. Route 53がALBに対してエイリアスレコードを発行 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.

7.まとめ Route53の可能性は無限大 • グローバルに分散されたDNSサーバーにより可用性が高い、視覚 的に分かりやすいUIにより入門ハードルの高いDNSの構造が分 かりやすい、ルーティングターゲットへのヘルスチェック完備と安心し て利用できる • エイリアスレコード対応サービスは続々と増えており、他AWSサー ビスと連携がし易く、構成パターンも豊富に考えられる • インターネット公開DNSサーバーとしてではなくプライベートDNS サーバーとしても使用でき、オンプレミスとの親和性も高い ⇒これからもAWSサービスの主力の一つであり続ける