Route 53 の費用を下げる近道は、やみくもに設定を変えることではなく、請求の内訳を「ホストゾーン」「DNS クエリ」「ヘルスチェック」「Resolver」のどれが占めているかで分け、大きい項目から手を付けることです。この記事では、Cost Explorer と AWS CLI で内訳と棚卸しをしてから、使っていないホストゾーンの削除、エイリアスレコードへの置き換え、TTL の見直し、ヘルスチェックと Resolver エンドポイントの整理を、安全な順番で進める方法を説明します。
具体的な単価は改定されることがあり、リージョンや利用量の段階によっても変わるため、この記事では金額を書きません。課金の仕組みと見直しの考え方に絞りますので、金額は AWS 公式の Route 53 料金ページで確認してください。説明する課金の仕組みは執筆時点（2026年10月現在）のものです。
Route 53 の費用はどこから発生するか
Route 53 の請求は、おおむね次の要素の合計です。
- ホストゾーン: パブリック・プライベートを問わず、ゾーン1つごとに月額がかかります。ゾーンの数が多いほど効いてきます。
- DNS クエリ: 権威 DNS として答えた問い合わせの件数に応じた料金です。通常のレコードより、レイテンシー・位置情報・IP ベースなどのルーティングポリシーを使ったレコードのほうが単価が高く設定されています。
- ヘルスチェック: 1件ごとの月額で、監視対象が AWS 内か外か、HTTPS・文字列照合・短い間隔などのオプションを付けるかで金額が変わります。
- Route 53 Resolver: VPC とオンプレミスなどを結ぶインバウンド・アウトバウンドのエンドポイントは、割り当てた IP アドレス（ネットワークインターフェイス）ごとの時間課金です。DNS Firewall やクエリ量にも別の料金があります。
- その他: ドメイン登録・更新の年額、トラフィックフローのポリシーレコード、クエリログの保存先（CloudWatch Logs など）の料金、DNSSEC で使う KMS キーの料金などです。
一方で、CloudFront・Elastic Load Balancing・S3 の静的ウェブサイトなど、特定の AWS リソースを指すエイリアスレコードへのクエリは追加料金がかからない扱いになっています。対象のリソースは公式の料金ページに一覧があるので、置き換えを検討する前に確認してください。
WordPress を1サイト運用している程度なら、Route 53 の費用はホストゾーン1つとクエリ料金がほとんどで、それほど大きくなりません。費用が気になるのは、検証用のゾーンが溜まっている、ヘルスチェックを多数張っている、Resolver エンドポイントを複数の VPC やリージョンに置いている、といったケースです。
手順1：Cost Explorer で内訳を確かめる
最初に、何にいくらかかっているかを確かめます。Cost Explorer の画面で、サービスを Route 53 に絞り、グループ化の条件に「使用タイプ」を選ぶと、ホストゾーン・クエリ・ヘルスチェック・Resolver などの内訳が並びます。CLI でも同じことができます。
# 前月の Route 53 の費用を使用タイプ別に表示する（期間は自分の確認したい月に変える）
aws ce get-cost-and-usage \
--time-period Start=2026-09-01,End=2026-10-01 \
--granularity MONTHLY \
--metrics UnblendedCost UsageQuantity \
--filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Route 53"]}}' \
--group-by Type=DIMENSION,Key=USAGE_TYPE使用タイプの表記はリージョンの接頭辞が付くなど変わることがあるので、名前の細部にこだわらず「どの種類が大きいか」を読み取ってください。なお、Cost Explorer の API 呼び出しにはリクエストごとの料金がかかるため、高頻度に呼ぶのは避けます。複数アカウントを使っている場合は、アカウント別に分けて見ると、どの環境が費用を押し上げているかが分かります。
手順2：ホストゾーンを棚卸しする
ホストゾーンは作ったまま忘れられやすい項目です。次のコマンドで一覧と件数を出します。
# ホストゾーンの総数
aws route53 get-hosted-zone-count
# ID・ゾーン名・プライベートかどうか・レコード数の一覧
aws route53 list-hosted-zones \
--query 'HostedZones[].[Id,Name,Config.PrivateZone,ResourceRecordSetCount]' \
--output table見るべきポイントは三つです。
- レコード数が2のゾーン: NS と SOA しかない、つまり何も登録されていないゾーンです。検証で作ったまま残っている可能性があります。
- 同じ名前のゾーンが複数ある: Route 53 でドメインを登録したときに自動で作られたゾーンと、後から手で作ったゾーンが並んでいることがあります。実際に使われているのは、レジストラに登録されているネームサーバーと一致する片方だけです。
- 終了したプロジェクトのゾーン: サイトを閉じた後も、ドメインの契約とゾーンだけが残っているケースです。
同じ名前のゾーンがある場合は、どちらが委任されているかを次のように照合します。
# 公開されている委任先（レジストラに登録されている NS）
dig +short example.com NS
# 各ホストゾーンに割り当てられたネームサーバー（ゾーン ID は一覧の値に置き換える）
aws route53 get-hosted-zone --id Z0123456789EXAMPLE \
--query 'DelegationSet.NameServers'委任されていない側のゾーンは、外部から引かれることがないので削除の候補になります。ただし、プライベートホストゾーンは外から dig しても見えないため、関連付けられている VPC と、そのゾーンを参照しているアプリケーションを確認してから判断してください。
削除する前には、ゾーンのレコードを書き出して保存しておきます。ホストゾーンを削除するには NS と SOA 以外のレコードを先に消す必要があり、いったん消すと元に戻すには作り直すしかありません。また、新しく作り直したゾーンには別のネームサーバーが割り当てられることがあり、そのゾーンを委任していた場合はレジストラ側の登録も変える必要が出ます。
# 削除前にレコードを JSON で保存する
aws route53 list-resource-record-sets --hosted-zone-id Z0123456789EXAMPLE \
> backup-Z0123456789EXAMPLE.jsonホストゾーンの月額は月の途中で削除しても日割りにならない扱いで、作成から短時間（12時間以内）で削除したゾーンは課金されない、と公式に案内されています。検証のためにゾーンを作るなら、その日のうちに片付ける運用にすると無駄が出ません。細かな条件は料金ページの記載で確かめてください。
手順3：クエリ料金を減らす
クエリ料金が大きい場合は、まずどの名前に問い合わせが集中しているかを確かめます。パブリックホストゾーンでは、CloudWatch の AWS/Route53 名前空間に、ホストゾーン単位のクエリ数のメトリクスが米国東部（バージニア北部）リージョンで提供されています。名前ごとの内訳まで見たい場合は、クエリログを一時的に有効にして CloudWatch Logs に出力します。ログの保存にも料金がかかるので、調査期間だけ有効にし、保持期間を短く設定しておきます。
内訳が分かったら、次の対策を検討します。
CNAME をエイリアスレコードに置き換える
CloudFront やロードバランサーを CNAME で指している場合、そのクエリは課金対象です。同じ先をエイリアスレコード（A / AAAA）で指せば、対象リソースへのエイリアスクエリは無料になり、ドメインの頂点（example.com そのもの）にも設定できます。WordPress を CloudFront 経由で配信している構成では、頂点と www の両方をエイリアスにしておくと扱いやすくなります。
同じ名前に CNAME とほかのレコードは同時に置けないため、置き換えは「CNAME の削除とエイリアスの作成」を1回の変更バッチとして送ると、名前が引けない時間を作らずに済みます。
TTL を用途に合わせて長くする
キャッシュ DNS は TTL の間は答えを保持するため、TTL が短いほど権威 DNS への問い合わせが増えます。めったに変えない MX や TXT、固定の IP を指す A レコードを 60 秒のまま運用しているなら、数時間程度に延ばすとクエリが減ります。
ただし TTL を延ばすと、値を変えたときに古い答えが残る時間も延びます。サーバー移転や切り替えを予定しているレコードは、作業の前に短く戻す前提で設定してください。また、エイリアスレコードの TTL は指す先のリソース側で決まり、自分では設定できません。エイリアスのクエリはもともと無料になる対象が多いので、TTL の見直しは通常のレコードを中心に行います。
ルーティングポリシーが本当に必要かを見直す
位置情報やレイテンシーベースのルーティングは、単価が高めのクエリになります。リージョンを1つに統合した、海外向けの振り分けをやめた、といった経緯で役目を終えたポリシーが残っていないかを確認し、不要ならシンプルなレコードに戻します。
手順4：ヘルスチェックを整理する
ヘルスチェックは、監視先のサーバーを廃止した後も残りがちです。一覧を出して、今も存在するエンドポイントを見ているか、フェイルオーバーやアラームで実際に使われているかを確認します。
aws route53 list-health-checks \
--query 'HealthChecks[].[Id,HealthCheckConfig.Type,HealthCheckConfig.FullyQualifiedDomainName,HealthCheckConfig.IPAddress]' \
--output table見直しの観点は次のとおりです。
- 廃止済みのサーバーを見ているものは、関連するレコードからの参照を外してから削除します。
- HTTPS、文字列照合、短い間隔（高速）、レイテンシー計測などのオプションは、それぞれ追加の料金になります。単純な死活監視で足りるなら、オプションを外すことも検討します。
- 単にサイトが落ちたことを知りたいだけで、DNS の切り替えまでは不要な場合は、ほかの監視サービスで足りることもあります。フェイルオーバーに組み込まれているものを消すと障害時に切り替わらなくなるため、参照元のレコードを確認してから判断します。
手順5：Resolver エンドポイントを見直す
Route 53 Resolver のインバウンド・アウトバウンドエンドポイントは、冗長化のために最低2つの IP アドレスを割り当てる仕組みで、その IP ごとに時間課金されます。使っていなくても存在するだけで費用が発生するため、検証環境で作ったまま残っていると、Route 53 の費用の中で大きな割合を占めることがあります。Resolver はリージョン単位のサービスなので、使っているリージョンごとに確認します。
aws route53resolver list-resolver-endpoints --region ap-northeast-1 \
--query 'ResolverEndpoints[].[Id,Name,Direction,IpAddressCount,HostVPCId]' \
--output table複数の VPC やアカウントでそれぞれアウトバウンドエンドポイントを作っている場合は、1か所にまとめ、転送ルールを AWS RAM で共有する構成にすると、エンドポイントの数を減らせます。ただし、ネットワーク経路やセキュリティグループの設計が変わるので、本番環境の前に検証環境で名前解決ができることを確認してから切り替えてください。
削除や変更の前に守ること
費用を減らす作業は、どれも「消す」「変える」操作です。次の点を守ると、節約のつもりがサイトやメールの停止につながる事態を避けられます。
- ゾーンのレコードは削除前に書き出して保存する。
- 削除の候補は、すぐに消さず、まず参照元（レジストラの NS、VPC の関連付け、ヘルスチェックを参照するレコード）を確認する。
- 変更は1つずつ行い、その都度 dig やアプリケーションの動作で確認する。
- AWS Budgets などで、Route 53 を含むアカウント全体の予算アラートを設定し、想定外の増加に早く気付けるようにする。
まとめ
- Route 53 の費用は、ホストゾーン・DNS クエリ・ヘルスチェック・Resolver・その他に分かれます。まず Cost Explorer で使用タイプ別の内訳を見て、大きい項目から見直します。
- ホストゾーンは、レコードが NS と SOA だけのもの、同じ名前で重複しているもの、終了したプロジェクトのものを棚卸しし、レコードを保存してから削除します。
- クエリ料金は、CNAME をエイリアスレコードに置き換える、変更の少ないレコードの TTL を延ばす、不要なルーティングポリシーを戻す、の順に効果を確かめます。
- ヘルスチェックと Resolver エンドポイントは、作ったまま残りやすい項目です。参照元を確認してから整理します。
- 単価や無料の対象は変わることがあるため、作業前に公式の料金ページで最新の条件を確認してください。