CloudMapとServiceConnectの名前解決を⽐較してみた 津⾕拓郎 

⽬次 2 ● ⾃⼰紹介(30秒） ● CloudMapとServiceConnectの名前解決を⽐較する ○ CloudMapとは？（1分） ○ CloudMapの名前解決の仕組みは？（2分） ○ ServiceConnectとは？(1分） ○ ServiceConnectの名前解決の仕組みは？（2分） ○ まとめ（30秒） 

⾃⼰紹介 3 ● 2023年4⽉ 独⽴系Slerに新卒⼊社  AWS、Azure、GCPを使ったWebアプリのインフラ 基盤の構築⽀援  【当時の⾃分】   クラウドの⾯⽩さを知る。   家でひたすらAWSコンソールを触る。   TerraformやAnsibleなどのIaCツールを齧る。 ● 2025年7⽉ クラスメソッド株式会社に中途⼊社 AWSのコンサル⽀援‧構築⽀援を担当  【今の⾃分】  より、モダンな構成を実装したい。   (コンテナ‧CICD‧サーバレス）   ブログ執筆とかAIを使ったIaC開発楽しい。 ● 所属 ○ クラスメソッド株式会社 ● 名前（ニックネーム） ○ 津⾕拓郎（つやたく） ● 出⾝‧住まい ○ 東京都⼤⽥区 ● 好きな技術 ○ AWS‧GCP‧Terraform ● 趣味 ○ 社交ダンス‧サウナ‧ポケモン 

CloudMapとは？ 4 CloudMapとは、アプリケーションが依存するバックエンドサービスと リソースに論理名をマッピングするAWSのフルマネージドサービスです。 ん？？よくわからない。 つまり、、、 サービス間の通信を⾏うために、通信先のAWSサービスに ⼀意の名前をつけることでリソースの情報を取得し、管理するサービスです。 

実際に触ってみる 

CloudMapの名前解決の仕組みは？ 6 ECSへの通信を例に考えてみます。 稼働しているコンテナに名前解決する場合、スケーリングを考慮する必要があります。 直接IPで名前解決するにはDNSにレコードを登録する必要があります。 スケールのタイミングに合わせて、DNS切り替えを対応するのは難しいですね。 例えばコンテナ1がスケールインして、新たにコンテナ4がスケールアウトした場合を考えます。 接続元が古いDNS情報を参照したり、新しいDNS情報を参照したいのにレコード登録されてな かったりなど、マイクロシステムならではの運⽤課題も発⽣します。 

CloudMapの名前解決の仕組みは？ 7 そんな時に「CloudMap」です。 DNSクエリでの名前解決も、API（HTTPS)での名前解決も可能です。 今回はDNSクエリでの名前解決を使ってみます。 CloudMapの「名前空間」を作成すると裏ではRoute53のプライベートホスト ゾーンが作成され、「サービス」を登録することで動的にコンテナのIPをマッ ピングし、ホストゾーンにレコード登録を⾏います。 

CloudMapの名前解決の仕組みは？ 8 名前空間の作成で「backend.local」を指定しま す。これが、そのままホストゾーン名になりま す。DNSクエリができるように設定を⾏い、ホ ストゾーンを関連付けるVPCを指定します。 CloudMapはサービスレジストリを参照し、リ ソースの最新情報（IPなど）を取得し、DNSに 反映します。 サービスレジストリはCloudMapが参照するリ ソース情報の格納庫で、「サービス」を名前空 間に登録することで機能します。 

CloudMapの名前解決の仕組みは？ 9 サービスを作成することで、実際にECSサービ スを名前空間に紐づけることができます。サー ビス名を「api」にしているのでサブドメイン名 は「api.backend.local」になります。 DNSのルーティングポリシーを複数値回答にす ることで、スケールされたコンテナのプライ ベートIPを動的にマッピングすることができま す。レコードタイプはA（IPを返す）にしていま す。 

CloudMapの名前解決の仕組みは？ 10 ECSのコンソール（サービス作成画⾯）でサービス検出のオプションがあるので、 ECSのサービス名を「api」と指定することで、作成した名前空間上でコンテナのNIC情報を検 出し、DNSホストゾーンにマッピングしてくれるようになります。 

CloudMapの名前解決の仕組みは？ 11 複数値回答で、⽴ち上がっているコン テナのIPをすべて検出しています。 まとめると、CloudMapではクライア ントがDNSクエリをする前に、関連付 けたVPC内のリソースをCloudMapが 検知し、ホストゾーンを⾃動更新して くれるという仕組みになっています。 

Service Connectとは？ 12 Service ConnectはECSに特化したマイクロシステム間の通信設定の管理サービスです。 通信設定を⾃動化してくれるという観点では、CloudMapと機能は似ているように思いま すが通信の仕⽅は異なります。 CloudMapみたいに、サービスを⾃動検出し て、DNSクエリでクライアントから名前解決す るんじゃないの? Service ConnectはDNSクエリによる名前解決はしません。サービスの短縮名を作成し、 そのサービス名を使ってそのまま通信させることができます。 それだと、CloudMapの機能と変わらないので は？DNSクエリ以外でどうやって通信を成功さ せるの？ 

Service Connectとは？ 13 同⼀タスク内にEnvoyプロキシコンテナを⽴て、各サービス内のプロキシ同⼠でネットワークトラ フィックをやり取りします。（サービスメッシュ型）名前解決部分や、トラフィック分散や通信の 暗号化（TLS）、リトライ機能、ヘルスチェック、サービス情報の検出（CloudMapとの連携）等を Envoyプロキシが⾃動で⾏っているのでサービス間通信のセキュリティ⾯や可⽤⾯をクライアント 側が意識して設定する必要はありません。 公式の図を参照（https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-connect.html） Envoyを挟んでいるのはわかったけど、具体的 にDNSクエリをつかっていないってどういうこ と？ 実際にECSコンテナにSSM経由でログ イン（ECS Exec)して、名前解決の仕 ⽅を確認しようと思います。 

実際に触ってみる 

Service Connectの名前解決の仕組みは？ 15 frontend→backendに名前解決するた めにクラスターを２つ作りました。 ‧test-frontend ‧test-backend Service Connectの設定は、サービス検出（Service Discovery)同様、ECSサービスの設定画⾯から⾏うこ とができます。CloudMapの名前空間は事前に登録しておきます。 frontend backend backendは、frontendからの通信を待ち受けるために、「ポートエイリアス」「検出」「DNS」を登録 する必要があります。 

Service Connectの名前解決の仕組みは？ 16 ‧ポートエイリアス…アプリケーションが認識する論理名（タスク定義で指定したポート名を適⽤） ‧検出…CloudMapが認識するサービス名（このサービス名を基にリソース情報を収集します） ‧DNS…実際にEnvoyプロキシが名前解決するDNS名      ⽴ち上がったコンテナを確認すると、frontend、backendのタスク内にアプリコンテナとは 別にEnvoyプロキシコンテナが⽴ち上がっています。 frontendタスク backendタスク 

CloudMapの名前解決の仕組みは？ 17 CloudMapにサービスが正常に登録されているか確認してみました。 CloudMapのコンソールで確認すると、サービス名は「検出」で指定して「mysql-detection」になって ました。 

CloudMapの名前解決の仕組みは？ 18 実際にECS Execでfrontendコンテナに接続して、名前解決の仕⽅を確認していきます。 aws ecs execute-command --cluster test-frontend --task （タスクID）--container wordpress（コンテ ナ名）--interactive --command "/bin/sh" 「/etc/hosts」を確認すると、下記のように表⽰されていました。 mysqlに名前解決するためのエントリが⽤意されていました。 「mysql-dns」は先ほどBackend側のServiceConnectで設定した「dns」名であり、 このホスト名を利⽤して名前解決をしているようです。 「127.255.0.1」がEnvoyプロキシを⽰しており、同じ名前空間にあるリソースへの名前解決は⾃動的に Hostファイルに書き込まれる仕組みのようです。 

CloudMapの名前解決の仕組みは？ 19 おまけで、「etc/resolv.conf」も確認してみました。 AWSが保有する内部プライベートDNSを参照していますね（これはEC2や、他コンピューティングリソー スも同様） つまり、同じ名前空間にあるリソースだけはEnvoyプロキシ経由で参照し、他のリソースはプライベート DNSでホストゾーンなりを作成し、DNSクエリすることも可能ということですね。 

まとめ 20 今回はCloudMapを単体機能として使った場合のAWSサービス間通信、ServiceConnect（CloudMapの 機能を内包）を使った場合の名前解決⽅法を⽐較してみました。 【CloudMap単体】 コンテナ側が、DNSクエリで直接IP情報を取得する 【ServiceConnect】 コンテナ側がホスト情報を参照して、バックエンドの名前解決をプロキシにフォワードしている。 プロキシ側でCloudMapの情報を⾒る（サービスディスカバリ）ことでコンテナ側に名前解決の結果を返 している（裏ではバックエンドのポート、DNSの情報を参照している） 

参考 21 異なるVPC間のコンテナを通信させてみた場合の構 成になります。サービスB側をCloudMapの名前空間 にサービスとして登録すると、CloudMapは登録され たサービスレジストリを参照し、最新のリソース情 報をキャッチします。 その情報をプライベートDNSに反映することで、ク ライアント側はスケールを意識せずに名前解決が可 能となります。 ‧CloudMapを使った別VPC間のECS接続に関しては、  以下の記事にまとめています。 https://dev.classmethod.jp/articles/cloudmap-ecsconnection-forvpcpee ring/ 

参考 22 ‧参照した公式ドキュメント https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-connect.html https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-exec.html https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect-concepts.html ‧参照した記事 https://qiita.com/hikarunakatani/items/2f91cc2b8a57835bcdc4