2026年6月11日
AWS Route 53 Resolver は、コンソールを使わずに AWS CLI の aws route53resolver コマンドや SDK（Python なら boto3 の route53resolver クライアント）から操作できます。API で扱うときに押さえる点は、「作成系の呼び出しには重複防止用の ID を付ける」「エンドポイントは作成直後には使えないので状態を待つ」「削除は関連付けを外してから逆順に行う」の3つです。
この記事では、権限の準備から、現状の棚卸し、エンドポイントと転送ルールの作成、転送先の変更、クエリログと DNS Firewall の設定、削除までを、CLI と boto3 の例で順に説明します。AWS のコマンドや引数は更新されるため（2026年10月現在）、実行前に aws route53resolver help や公式の API リファレンスで確認してください。本番の VPC で試す前に、検証用の VPC で一通り動かしておくことを勧めます。
前提: Route 53 と Route 53 Resolver の API は別
Route 53 のホストゾーンやレコードを操作する API（CLI では aws route53）と、Resolver を操作する API（aws route53resolver）は別のサービスとして扱われます。プライベートホストゾーンのレコードを追加したい場合は aws route53 側、VPC からの転送やエンドポイントを扱う場合は aws route53resolver 側です。IAM のアクション名も route53: と route53resolver: に分かれています。
また Route 53 本体の API がグローバルなのに対し、Resolver の API はリージョンごとです。エンドポイントやルールは作成したリージョンにしか存在しないため、CLI では --region を明示するか、プロファイルのリージョンを確認してから実行してください。
手順1: 権限を用意する
操作する IAM ロール（またはユーザー）には、必要な route53resolver: のアクションを許可します。読み取りだけなら List* と Get* で足ります。エンドポイントを作成・削除する場合は、Resolver が VPC 内にネットワークインターフェースを作るため、EC2 側のネットワークインターフェースやサブネット、セキュリティグループを参照・作成する権限も必要になります。必要なアクションの一覧は公式ドキュメントの Resolver の権限のページで確認し、最初は検証環境で最小限の権限から試してください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ResolverReadOnly",
"Effect": "Allow",
"Action": [
"route53resolver:List*",
"route53resolver:Get*"
],
"Resource": "*"
}
]
}アクセスキーをスクリプトに直接書くのは避け、EC2 のインスタンスロールや AWS IAM Identity Center（SSO）のプロファイルなど、一時的な認証情報で実行する形にします。
手順2: 現状を棚卸しする
変更の前に、今あるエンドポイント、ルール、関連付けを確認します。変更前の状態を JSON で保存しておくと、作業後の比較や、誤って変更したときの戻し先になります。
REGION=ap-northeast-1
# エンドポイントの一覧（ID・向き・状態）
aws route53resolver list-resolver-endpoints --region "$REGION" \
--query "ResolverEndpoints[].[Id,Name,Direction,Status]" --output table
# 転送ルールの一覧
aws route53resolver list-resolver-rules --region "$REGION" \
--query "ResolverRules[].[Id,Name,DomainName,RuleType]" --output table
# ルールと VPC の関連付け
aws route53resolver list-resolver-rule-associations --region "$REGION" \
--query "ResolverRuleAssociations[].[ResolverRuleId,VPCId,Status]" --output table
# 作業前の状態を保存
aws route53resolver list-resolver-rules --region "$REGION" > rules-before.jsonルールの一覧には、AWS が自動で作る種類（RuleType が SYSTEM や RECURSIVE のもの）も含まれます。自分で作った転送ルールは FORWARD です。自動で作られたルールは削除や変更の対象にしないでください。
手順3: アウトバウンドエンドポイントを作る
ここからは、VPC からの corp.example.com の問い合わせを社内 DNS（10.10.0.10 と 10.10.0.11）へ転送する例で進めます。まず出口となるアウトバウンドエンドポイントを作ります。
aws route53resolver create-resolver-endpoint --region "$REGION" \
--name outbound-corp \
--creator-request-id outbound-corp-2026-10-01 \
--direction OUTBOUND \
--security-group-ids sg-0123456789abcdef0 \
--ip-addresses SubnetId=subnet-aaaa1111 SubnetId=subnet-bbbb2222--creator-request-id は、同じ作成要求が重複して実行されたときに、二重にリソースが作られるのを防ぐための値です。再実行で同じ ID を使えば、新しいエンドポイントは作られません。作業ごとに一意な値（日付や作業番号を含めるなど）を付けます。
エンドポイントには2つ以上の IP アドレスが必要です。別々のアベイラビリティーゾーンのサブネットを指定すると、1つの AZ の障害で転送が止まるのを避けられます。セキュリティグループでは、転送先の DNS サーバーへの UDP と TCP の 53 番ポートの送信を許可しておきます。
作成完了を待つ
作成直後のエンドポイントは CREATING の状態で、まだ使えません。OPERATIONAL になるまで待ってから次の手順へ進みます。
EP_ID=rslvr-out-0123456789abcdef0 # 作成時の出力にある Id に置き換え
for i in $(seq 1 30); do
STATUS=$(aws route53resolver get-resolver-endpoint --region "$REGION" \
--resolver-endpoint-id "$EP_ID" --query "ResolverEndpoint.Status" --output text)
echo "status: $STATUS"
[ "$STATUS" = "OPERATIONAL" ] && break
sleep 20
doneACTION_NEEDED などの状態で止まった場合は、StatusMessage に理由が出ます。サブネットの空き IP 不足やセキュリティグループの指定誤りが多い原因です。
手順4: 転送ルールを作り、VPC に関連付ける
# 転送ルールの作成
aws route53resolver create-resolver-rule --region "$REGION" \
--name forward-corp \
--creator-request-id forward-corp-2026-10-01 \
--rule-type FORWARD \
--domain-name corp.example.com \
--resolver-endpoint-id "$EP_ID" \
--target-ips "Ip=10.10.0.10,Port=53" "Ip=10.10.0.11,Port=53"
# VPC への関連付け（ルールIDは作成時の出力から）
aws route53resolver associate-resolver-rule --region "$REGION" \
--resolver-rule-id rslvr-rr-0123456789abcdef0 \
--vpc-id vpc-0123456789abcdef0 \
--name forward-corp-main-vpcルールは作っただけでは効かず、VPC に関連付けて初めて、その VPC からの問い合わせが転送されます。関連付けも作成直後は処理中の状態になるため、list-resolver-rule-associations で状態が完了になったことを確認します。
確認は、関連付けた VPC 内の EC2 から行います。
dig +short host1.corp.example.com A手順5: 転送先を変更する
社内 DNS の IP が変わった場合は、ルールを作り直さずに update-resolver-rule で転送先を変更できます。引数は JSON ファイルで渡すと、書き間違いを減らせます。
{
"TargetIps": [
{ "Ip": "10.10.0.20", "Port": 53 },
{ "Ip": "10.10.0.21", "Port": 53 }
]
}aws route53resolver update-resolver-rule --region "$REGION" \
--resolver-rule-id rslvr-rr-0123456789abcdef0 \
--config file://rule-config.jsonTargetIps は追加ではなく置き換えになります。残したい転送先も含めて、全体を書いてください。変更前に新しい転送先が VPC から到達可能か（ルーティング、VPN、ファイアウォール）を確認しておくと、変更直後に名前解決が止まる事態を防げます。
手順6: クエリログと DNS Firewall を設定する
VPC からの問い合わせを記録するには、クエリログの設定を作って VPC に関連付けます。出力先には CloudWatch Logs のロググループ、S3 バケット、Data Firehose などを指定できます。
aws route53resolver create-resolver-query-log-config --region "$REGION" \
--name vpc-main-querylog \
--creator-request-id querylog-2026-10-01 \
--destination-arn arn:aws:logs:ap-northeast-1:111122223333:log-group:/resolver/vpc-main
aws route53resolver associate-resolver-query-log-config --region "$REGION" \
--resolver-query-log-config-id rslvr-rqlc-0123456789abcdef0 \
--resource-id vpc-0123456789abcdef0クエリログには VPC 内のサーバーがどこへアクセスしようとしたかが記録されるため、ログの保存期間と閲覧権限を決めておきます。量が多い VPC では、保存費用にも注意が要ります。
DNS Firewall は、ドメインリスト、ルールグループ、ルール、VPC への関連付けの順に作ります。
# 1. ドメインリストを作り、ドメインを追加
aws route53resolver create-firewall-domain-list --region "$REGION" \
--name blocked-domains --creator-request-id fdl-2026-10-01
aws route53resolver update-firewall-domains --region "$REGION" \
--firewall-domain-list-id rslvr-fdl-0123456789abcdef0 \
--operation ADD --domains "bad.example.net" "*.bad.example.net"
# 2. ルールグループを作り、ブロックするルールを追加
aws route53resolver create-firewall-rule-group --region "$REGION" \
--name main-firewall --creator-request-id frg-2026-10-01
aws route53resolver create-firewall-rule --region "$REGION" \
--creator-request-id fr-2026-10-01 \
--firewall-rule-group-id rslvr-frg-0123456789abcdef0 \
--firewall-domain-list-id rslvr-fdl-0123456789abcdef0 \
--name block-bad --priority 100 --action BLOCK --block-response NXDOMAIN
# 3. VPC に関連付け
aws route53resolver associate-firewall-rule-group --region "$REGION" \
--creator-request-id frga-2026-10-01 \
--firewall-rule-group-id rslvr-frg-0123456789abcdef0 \
--vpc-id vpc-0123456789abcdef0 \
--name main-firewall-assoc --priority 101いきなり BLOCK にすると、業務に必要な通信まで止めてしまうことがあります。最初は --action ALERT で記録だけ行い、ログで影響を確認してから BLOCK に切り替える進め方が安全です。
boto3 から操作する例
スクリプトで棚卸しを自動化する場合は boto3 を使います。一覧系の API は結果が複数ページに分かれることがあるため、ページネーターを使って全件を取得します。
import boto3
from botocore.exceptions import ClientError
client = boto3.client("route53resolver", region_name="ap-northeast-1")
# 転送ルールを全件取得し、FORWARD のものだけ表示する
paginator = client.get_paginator("list_resolver_rules")
for page in paginator.paginate():
for rule in page["ResolverRules"]:
if rule["RuleType"] != "FORWARD":
continue
targets = ", ".join(t["Ip"] for t in rule.get("TargetIps", []))
print(rule["Id"], rule["DomainName"], targets)
# 関連付けの例（VPCId の綴りに注意）
try:
client.associate_resolver_rule(
ResolverRuleId="rslvr-rr-0123456789abcdef0",
VPCId="vpc-0123456789abcdef0",
Name="forward-corp-main-vpc",
)
except ClientError as e:
print("failed:", e.response["Error"]["Code"], e.response["Error"]["Message"])boto3 の引数名は API の名前そのままなので、CLI の --vpc-id が boto3 では VPCId になるなど、綴りが異なるものがあります。エラー時は Error.Code を見て、同じ名前のリソースがある、上限に達している、呼び出しが多すぎる（スロットリング）などの原因を切り分けます。スロットリングの場合は、間隔を空けて再試行します。
削除は逆順で行う
Resolver のリソースは、関連付けや参照が残っていると削除できません。作成と逆の順番で外していきます。
- ルールと VPC の関連付けを外す（
disassociate-resolver-rule） - 転送ルールを削除する（
delete-resolver-rule） - どのルールからも使われなくなったアウトバウンドエンドポイントを削除する（
delete-resolver-endpoint）
クエリログや DNS Firewall も同様に、VPC との関連付けを外してから本体を削除します。削除の前に手順2の棚卸しを再度行い、ほかの VPC や他アカウントと共有しているルールでないかを確認してください。共有中のルールを削除すると、共有先の名前解決も止まります。
まとめ
- Route 53 Resolver の API は Route 53 本体とは別で、リージョンごとに操作します。CLI では
aws route53resolver、boto3 ではroute53resolverクライアントを使います。 - 作成系の呼び出しには
--creator-request-idを付け、再実行で二重に作られないようにします。 - エンドポイントは
OPERATIONALになるまで待ち、ルールは VPC に関連付けて初めて効きます。 - 転送先の変更は
update-resolver-ruleで行い、TargetIpsは全体の置き換えになる点に注意します。 - DNS Firewall は
ALERTで影響を確認してからBLOCKに切り替え、削除は関連付けを外してから逆順に行います。