無料GitHub で公開

route53

Configures Amazon Route 53 DNS: public and private records, traffic-steering routing policies, health checks, DNS Firewall, Route 53 Profiles, VPC Resolver (also known as Route 53 Resolver) for hybrid and Outposts networks, and Global Resolver. Applicable when the customer wants to point a hostname at a target, split or fail over traffic across endpoints, monitor an endpoint, block malicious domains, centralize DNS across accounts, or resolve private DNS across a hybrid network. Routes to the right per-task procedure in references. Does not cover CloudFront-specific setup (see the route53-cloudfront skill) or non-DNS networking.

aws/agent-toolkit-for-aws

インストール方法を見る

含まれるファイル（12）

SKILL.md6.4 KB
references/blocking-malicious-domains.md20.7 KB
references/centralizing-dns-firewall.md17.3 KB
references/configuring-failover-routing.md15.1 KB
references/configuring-route53-profiles.md15.4 KB
references/creating-a-public-dns-record.md12.9 KB
references/identifying-the-effective-dns-firewall-rule.md15.1 KB
references/resolving-private-dns-for-hybrid-networks.md15.3 KB
references/running-route53-resolver-on-outposts.md10.5 KB
references/setting-up-a-route53-health-check.md11.2 KB
references/setting-up-route53-global-resolver.md25.5 KB
references/splitting-traffic-with-weighted-routing.md10.7 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Amazon Route 53

Overview

Domain expertise for configuring Amazon Route 53 DNS across the public and private resolution paths: hosted zone records, traffic-steering routing policies, health checks, DNS Firewall, Route 53 Profiles, VPC Resolver (also known as Route 53 Resolver) for hybrid and Outposts networks, and Global Resolver.

This skill is a router. Each customer task maps to a procedure file under references/. Read the matching reference in full before acting, then follow its constraints and steps. The reference files are self-contained: each carries its own decision tables, constraints, procedure, and troubleshooting.

Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to the AWS CLI otherwise. All Route 53 Domains API calls are made in us-east-1 regardless of where the customer works.

Which Route 53 task do you need?

Goal	Reference
Point a hostname or zone apex at an IP, AWS resource, or hostname	creating a public DNS record
Split traffic across endpoints in a ratio (blue/green, canary, A/B)	splitting traffic with weighted routing
Fail over between two Regions for disaster recovery	configuring failover routing
Monitor whether an endpoint is up and get alerted	setting up a health check
Block malicious domains for a VPC at the resolver	blocking malicious domains
Work out which DNS Firewall rule wins for a domain across multiple rule groups	identifying the effective DNS Firewall rule
Apply one DNS config across many VPCs and accounts	configuring Route 53 Profiles
Fan DNS Firewall out across many accounts org-wide	centralizing DNS Firewall with Profiles
Resolve private DNS both ways across a hybrid network	resolving private DNS for hybrid networks
Run VPC Resolver locally on an AWS Outposts rack	running VPC Resolver on Outposts
Give on-premises and remote clients one anycast DNS endpoint	setting up Global Resolver

Routing notes

Records vs routing policies. A plain hostname-to-target mapping is the public DNS record task. Splitting or steering traffic (weighted, failover) is a separate routing-policy task with its own reference. Start from the customer's intent, not the record type.
Health checks vs failover. A health check monitors an endpoint and raises alarms. The failover routing policy decides where traffic goes when a check fails. They are two references and are often used together: set up the health check, then wire it into failover.
DNS Firewall for one VPC vs many accounts. Authoring rules for a VPC is the blocking reference. Fanning the same protection across accounts with Profiles and Firewall Manager is the centralizing reference.
DNS Firewall authoring vs diagnosis. Creating or changing rules is the blocking reference. Working out which rule already wins for a domain when several rule groups are associated (a read and diagnostic task) is the identifying-the-effective-rule reference.
Profiles, two entry points. General Profile setup (attach resources, share via RAM, cost and visibility tradeoffs) is the configuring-Profiles reference. Using Profiles specifically to scale DNS Firewall org-wide is the centralizing reference.
VPC Resolver, three contexts. In-Region hybrid resolution, the Outposts-local resolver, and the Global Resolver anycast endpoint are three separate references. Match the reference to where the resolver runs.

Cross-service work

Pointing a custom domain at a CloudFront distribution, or failing over between CloudFront distributions, is cross-service work owned by the separate route53-cloudfront skill. Use this skill for the Route 53 side of pure-Route 53 tasks only.

Security Considerations

These apply across the Route 53 tasks below; each reference repeats the ones load-bearing for its workflow.

You SHOULD use least-privilege IAM credentials provisioned through IAM roles (instance profiles, SSO/IAM Identity Center session credentials, or aws sts assume-role) rather than long-lived IAM user access keys, and prefer read-only credentials for inspection steps.
You SHOULD recommend encrypted DNS transport (DoT or DoH) over plaintext Do53 for resolver client populations, since Do53 exposes queried domain names to on-path observers.
You MUST scope resolver-endpoint security group rules on port 53 to the on-premises CIDR ranges or known DNS server IPs, never 0.0.0.0/0.
You MUST encrypt query log and notification destinations at rest: KMS on CloudWatch Logs log groups, SSE-S3/SSE-KMS on S3 buckets, server-side encryption (SSE) on a Data Firehose stream, and SSE on SNS topics, because DNS query logs and health-check notifications can reveal infrastructure topology.
For Global Resolver, you MUST treat access-token value returned at create time as a secret; store it in AWS Secrets Manager rather than in plaintext, and validate which client populations each DNS view authorizes.

Additional Resources

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

agent-advisor

無料

Entry point for AI-agent work on AWS: pick a runtime, plan a migration for existing workloads, and build an executable POC — one phased flow. Triggers on: which runtime for my agent, AgentCore vs ECS vs EKS vs Lambda, AgentCore vs Lambda MicroVMs, deploy an AI agent on AWS, agent architecture on AWS, I have an agent idea what do I build, move/migrate my agents to AWS, agent migration plan, add AgentCore services (memory, gateway, identity, policy, observability) to an agent already on AWS, Temporal on AWS (migrate/run Temporal workers on AWS, a service orchestrated by Temporal, Temporal Cloud vs self-hosted). Temporal Workflow code is never rewritten into Step Functions. Requires at least one agentic component — a purely non-agent system (plain services, batch jobs, HTTP endpoints, non-agent Temporal Activities) is out of scope, redirected to gcp-to-aws / heroku-to-aws / llm-to-bedrock. Not for: compute/data migration with no AI agent; pure LLM SDK rewrite (use llm-to-bedrock); per-model pricing.

日本語の概要は準備中です。原文の説明を表示しています。