--- title: "AWS Cloud Mapとは？サービスディスカバリの仕組み・名前空間・料金とECS連携を実装目線で解説" url: "https://www.issoh.co.jp/tech/details/15498/" published: 2026-07-22 updated: 2026-09-27 categories: ["AWS"] publisher: "株式会社一創" --- # AWS Cloud Mapとは？サービスディスカバリの仕組み・名前空間・料金とECS連携を実装目線で解説 AWS Cloud Mapは、アプリケーションが依存するバックエンドの資源に「論理名」を割り当てて管理する、マネージドなサービスレジストリです。ECSタスクやEC2上のサービス、DynamoDBテーブル、SQSキューといった資源を名前で登録しておくと、呼び出し側は物理的なIPやエンドポイントを知らなくても、名前を手がかりに接続先を引き当てられます。しかも返ってくるのは正常な資源だけなので、落ちたインスタンスへ誤って接続する事故を減らせます。 マイクロサービスやコンテナ構成ではタスクの入れ替わりでIPが動的に変わるため、接続先を静的に書き込む設計は破綻しがちです。この「場所を解決する層」を担うのがCloud Mapで、ECSのサービスディスカバリ機能もこれを土台に動きます。この記事では、構成要素・場所の解決方式・ヘルスチェック・ECS連携・料金・採用判断までを実装者の解像度で整理します。 ## まとめ：AWS Cloud Mapの要点を先に押さえる - Cloud Mapは、サービスやDB・キューなどの資源に論理名を割り当て、**正常なものだけを返す**マネージドなサービスレジストリである。 - 場所の解決はDNSクエリとDiscoverInstances APIの2系統。名前空間は「公開DNS」「VPC内の私設DNS」「API専用のHTTP」の3種から選ぶ。 - ECSのサービスディスカバリとService ConnectはどちらもCloud Mapの名前空間を土台にする。EKS・EC2・Lambdaからも呼べる。 - 料金は登録リソース従量とAPI呼び出し従量が主体。DNS名前空間ではRoute 53のホストゾーンとクエリ課金が別に乗る。 - IPが動的に変わるマイクロサービス構成なら採用価値が高い。少数の静的構成や、既にサービスメッシュで配信済みの場合は見送りも判断に入る。 ## AWS Cloud Mapとは：論理名でバックエンド資源を探す仕組み Cloud Mapの中核は「名前と場所の対応表」を一元管理し、アプリからその表を問い合わせられるようにする点にあります。従来はロードバランサーのDNS名を環境変数に埋め込んだり、設定ファイルに接続先を列挙したりして接続先を固定していました。この方式は、資源が増減するたびに設定の更新と再デプロイを迫られます。 Cloud Mapを挟むと、資源を追加したコードが`RegisterInstance`で自らを登録し、呼び出し側は名前で問い合わせるだけで最新の接続先を受け取れます。接続先の解決はAWS SDK、RESTful APIコール、DNSクエリのいずれからでも行えます。落ちている資源はヘルスチェックの結果で除外され、応答に並ぶのは健全なものだけです。マイクロサービスやジョブワーカーのように構成が動く前提のシステムほど、この間接層の効き目が出ます。 ## AWS Cloud Mapを構成する名前空間とサービスとインスタンス Cloud Mapは3つの階層で構成されます。まず**名前空間（Namespace）**は、あるアプリのサービス群をまとめる入れ物で、名前の解決方式（DiscoverInstances API、VPC内の私設DNS、公開DNS）をここで決めるのが起点です。次に**サービス（Service）**は、資源の種類ごとに作るテンプレートで、DNSレコードの型やヘルスチェックの有無を保持します。たとえばWebサーバー用とDBサーバー用に別々のサービスを切ります。 最後に**サービスインスタンス（Service instance）**は、実体の資源1つ1つを表します。アプリが資源を追加したタイミングで`RegisterInstance`を呼び、IPアドレスやポートなどの属性を登録する流れです。呼び出し側は名前空間名とサービス名を指定して問い合わせると、その時点で健全なインスタンスの一覧が返ります。この3層を意識すると、どこにヘルスチェックを紐づけ、どの粒度でサービスを分けるかの設計判断がしやすくなります。 ## DNSクエリとDiscoverInstances APIによる資源探索の違い 場所の解決には2つの経路があり、名前空間の種類でどちらが使えるかが決まります。DNS経由は既存のDNSクライアントがそのまま使える一方、TTLに引きずられて情報が古くなりやすいのが弱点です。DiscoverInstances API経由は、その瞬間の健全なインスタンスを直接引けるため鮮度が高く、属性でのフィルタリングも効きます。名前空間の型と特徴を並べると次のとおりです。 | 名前空間の種類 | 解決方法 | 主な用途 | | --------- | ----------- | ----------- | | 公開DNS名前空間 | DNS＋API | 外部公開の名前解決 | | 私設DNS名前空間 | VPC内DNS＋API | VPC内サービス間通信 | | HTTP名前空間 | APIのみ | DNS不要のAPI探索 | 設計の勘所は、DNSキャッシュの都合とAPI呼び出しの鮮度・課金を天秤にかけることです。DNSに依存しないHTTP名前空間はもっとも軽量ですが、探索のたびにDiscoverInstancesを叩くため呼び出し回数の見積もりが要ります。逆にレガシーなクライアントを収容するなら私設DNS名前空間が扱いやすいでしょう。 ## ヘルスチェックの2つの選択肢と正常なインスタンスだけを返す設計 Cloud Mapが「健全なものだけ」を返せるのは、ヘルスチェックを内包しているからです。方式は2系統あります。1つはAmazon Route 53のヘルスチェックで、公開IPを持つ資源に対してAWS側が定期的に到達性を確かめる仕組みです。もう1つはカスタムヘルスチェックで、アプリやサイドカーが`UpdateInstanceCustomHealthStatus`で健全・不健全を明示的に報告します。VPC内の到達不能な資源やコンテナ内部の状態を反映したい場合は、後者が向きます。 どちらを選んでも、探索の応答からは不健全なインスタンスが外れます。ここを設計に組み込むと、ローリングデプロイ中に切り替わる古いタスクへ流量が向かうのを抑えられます。なお、Route 53ヘルスチェックを使う場合は後述のとおり別途の課金が発生する点に注意してください。 ## ECSサービスディスカバリとService Connectでの利用 実務でCloud Mapを最初に触るのは、たいていECSの経由です。ECSのサービスディスカバリを有効にすると、ECSがCloud Mapのサービスを作り、起動したタスクをインスタンスとして自動で登録・登録解除します。呼び出し側は`web.myapp.local`のような名前で相手を引けるようになり、タスクの入れ替わりを意識せずに通信できるのが利点です。より新しいService Connectも、内部的にCloud Mapの名前空間を利用しつつ、管理されたプロキシで再試行やメトリクスまで面倒を見てくれます。 ECSやFargate、EKS、EC2、Lambdaのいずれからも利用でき、DynamoDBのようにIPを持たない資源も属性付きで登録できます。手前で構成要素を掴んでおくと、ECS側の設定が何を裏で作っているのかが見通せるはずです。ECSそのものの起動タイプや料金は[AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い](https://www.issoh.co.jp/tech/details/3870/)、サーバー管理を手放す実行基盤としては[AWS Fargateとは？EC2との違い・料金をわかりやすく解説](https://www.issoh.co.jp/tech/details/3304/)を併せて確認すると設計判断が固まります。名前空間とサービスをCLIで作る流れは次のように書けます。 ``` aws servicediscovery create-http-namespace --name myapp-namespace aws servicediscovery create-service --name web --namespace-id ns-xxxxxxxx aws servicediscovery register-instance --service-id srv-xxxxxxxx --instance-id web-1 --attributes AWS_INSTANCE_IPV4=10.0.0.10 aws servicediscovery discover-instances --namespace-name myapp-namespace --service-name web ``` ## AWS Cloud Mapの料金：登録リソースとAPI呼び出し課金 Cloud Mapの課金は「レジストリに登録した資源」と「探索のAPI呼び出し」の従量が基本で、初期費用はありません。DNSベースの解決やRoute 53ヘルスチェックを有効にすると、Cloud Map本体とは別にRoute 53側の課金が乗ります。2026年7月時点で公開されている料金の目安は次のとおりで、実運用ではAWS公式の料金ページで最新値を確かめてください。 | 課金対象 | 料金の目安 | | ------------- | --------------------- | | 登録リソース | 1リソース月0.10ドル | | Discovery API | 100万回1.00ドル | | DNSクエリ | 100万回0.40ドル（Route 53） | | DNSホストゾーン | 1ゾーン月0.50ドル | 見積もりの勘所は、HTTP名前空間はホストゾーン課金が不要な代わりにAPI呼び出しが積み上がる点です。AWS公式の例では、75台のEC2と10のDynamoDBをHTTP探索で回す構成が概ね月21ドル台、10台のEC2をDNSで解決する小規模構成が概ね月1ドル台とされています。呼び出し頻度の高いサービスほどAPI課金の設計が効いてくるため、クライアント側のキャッシュ戦略と併せて費用を適正化しましょう。 ## AWS Cloud Mapを採用すべき条件と見送るべき場面の判断 採用を勧められるのは、次の条件が揃うときです。第一に、ECSやEKSでタスクが頻繁に入れ替わり、IPが動的に変わる構成であること。第二に、複数のサービスが名前でお互いを呼び合い、接続先の一覧を中央で管理したいこと。第三に、DynamoDBやSQSのようなマネージド資源まで含めて論理名で束ねたいことです。これらに当てはまるなら、ECSサービスディスカバリの有効化から入るのが実装コストの小さい入り口になります。判断の全体像は[コンテナオーケストレーションとは？自社に必要かの判断](https://www.issoh.co.jp/column/details/13003/)で俯瞰し、なぜサービス分割で場所の解決が要るのかは[モノリスとマイクロサービスの違い](https://www.issoh.co.jp/column/details/2910/)で押さえると位置づけが明確になります。 一方で見送りが妥当な場面もあります。サービスが少数で接続先が静的なら、ロードバランサー1枚とDNS名で足りることが多く、レジストリを挟む複雑さに見合いません。既にIstioやApp Meshといったサービスメッシュでエンドポイント配信を担っているなら、Cloud Mapと役割が重なるため二重管理になりがちです。EKSでKubernetes標準のServiceとCoreDNSに寄せる方針なら、そちらで解決が完結する構成も選べるでしょう。自社の構成がどちらに寄るか迷う段階なら、要件整理から設計まで[AWSインフラ構築の支援サービス](https://www.issoh.co.jp/service/system/aws/)で相談し、サービスディスカバリの必要性そのものを見極めるのが近道です。 ## よくある質問 ### AWS Cloud MapとRoute 53の違いは何ですか？ Route 53はDNSサービスで、ドメイン名をIPに変換する役割が中心です。Cloud Mapはその上位にあるサービスレジストリで、資源を論理名で登録し、ヘルスチェックで健全なものだけをDNSまたはAPIで返します。DNS名前空間を使うとCloud Mapは裏でRoute 53のホストゾーンを利用するため、両者は競合ではなく組み合わせて動きます。 ### ECSのサービスディスカバリとService Connectはどちらを使うべき？ 新規構成なら再試行やメトリクスまで内包するService Connectが扱いやすく、既存のサービスディスカバリ構成を運用中ならそのまま維持する選択もあります。どちらもCloud Mapの名前空間を土台にするため、後からの移行余地は残ります。要件が接続先の解決だけならサービスディスカバリで十分です。 ### AWS Cloud Mapに追加料金はどのくらいかかりますか？ 登録リソースが1つ月0.10ドル、探索APIが100万回1.00ドルが基本です。DNS解決やRoute 53ヘルスチェックを使うと、ホストゾーンやクエリのRoute 53課金が別途加わります。呼び出し頻度が高い構成ではAPI課金が主因になりやすいので、クライアント側のキャッシュで回数を抑えると費用を適正化できます。 ### DNS名前空間とHTTP名前空間はどう選び分けますか？ 既存のDNSクライアントをそのまま収容したいならDNS名前空間、DNSに依存せず最新の健全インスタンスをAPIで引きたいならHTTP名前空間が向きます。HTTP名前空間はホストゾーン課金が不要な反面、探索のたびにAPIを呼ぶため回数の見積もりが要ります。 ### Kubernetes（EKS）でもAWS Cloud Mapは使えますか？ 使えます。ただしEKSではKubernetes標準のServiceとCoreDNSでサービス間解決が完結することも多く、その場合はCloud Mapと役割が重なります。VPCをまたぐ資源やマネージドサービスまで論理名で束ねたいときに、Cloud Mapを併用する構成が現実的です。 ## 関連記事 - [AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い](https://www.issoh.co.jp/tech/details/3870/) - [AWS Fargateとは？EC2との違い・料金をわかりやすく解説](https://www.issoh.co.jp/tech/details/3304/) - [コンテナオーケストレーションとは？自社に必要かの判断](https://www.issoh.co.jp/column/details/13003/) - [モノリスとは？マイクロサービスとの違いを整理](https://www.issoh.co.jp/column/details/2910/) --- 出典: [AWS Cloud Mapとは？サービスディスカバリの仕組み・名前空間・料金とECS連携を実装目線で解説]()（株式会社一創）