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.
Resumen
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
valuereturned 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
Archivos 12 archivos
- SKILL.mdMarkdown
- references/blocking-malicious-domains.mdMarkdown
- references/centralizing-dns-firewall.mdMarkdown
- references/configuring-failover-routing.mdMarkdown
- references/configuring-route53-profiles.mdMarkdown
- references/creating-a-public-dns-record.mdMarkdown
- references/identifying-the-effective-dns-firewall-rule.mdMarkdown
- references/resolving-private-dns-for-hybrid-networks.mdMarkdown
- references/running-route53-resolver-on-outposts.mdMarkdown
- references/setting-up-a-route53-health-check.mdMarkdown
- references/setting-up-route53-global-resolver.mdMarkdown
- references/splitting-traffic-with-weighted-routing.mdMarkdown
Instálala a mano
Deska ejecuta esto por ti, para cada agente que elijas. Para ejecutarlo tú en una terminal:
npx skills add aws/agent-toolkit-for-aws --skill route53Más de aws
- aws-iamawsProvides verified corrections for IAM behaviors that AI agents frequently get wrong — policy evaluation edge cases, trust policy gotchas, STS session limits, Organizations quirks, and SAML/MFA specifics. Also provides structured workflows for IAM role management and baseline policy generation from application source code or a Terraform plan JSON. Covers condition operator safety (ForAnyValue/ForAllValues with Null checks), bucket policy deny patterns (VPC endpoint restrictions, org paths), confused deputy protection, and service role creation for AWS services (Glue, CloudTrail, Lambda, ECS, etc.) with aws:SourceAccount/aws:SourceArn trust conditions. Applies when creating IAM roles, writing IAM or bucket policies, generating policies from application source code or a Terraform plan JSON, working with STS, Organizations, or condition operators, or any task needing a service or execution role. Does not cover non-IAM authorization like Cognito user-pool policies or app-level RBAC.9,200 instalaciones en skills.sh0
- aws-serverlessawsBuilds, deploys, manages, debugs, configures, and optimizes serverless applications on AWS using Lambda, API Gateway, Step Functions, EventBridge, and SAM/CDK. Covers cold starts, CORS debugging, event source mappings, troubleshooting, concurrency, SnapStart, Powertools, function URLs, EventBridge Scheduler, Lambda layers, and production readiness. Triggers on mentions of Lambda, API Gateway, Step Functions, SAM templates, CDK serverless stacks, DynamoDB stream triggers, SQS event sources, cold starts, timeouts, 502/504 errors, throttling, concurrency, CORS, Powertools, or any event-driven architecture on AWS, even without the word "serverless." Does not apply to EC2, ECS/Fargate containers, or Amplify hosting.9,000 instalaciones en skills.sh0
- aws-observabilityawsBuilds, configures, debugs, and optimizes AWS observability - operator-symptom questions and detecting Omni vs classic CloudWatch. CloudWatch on an already-reporting service: Log Insights, metric/composite/anomaly alarms, custom metrics/EMF, dashboards, X-Ray/ADOT tracing, canaries, CloudTrail, Dynamic Instrumentation (live breakpoints/snapshots), the Application Signals service map, and fleet health views. CloudWatch Omni on an existing Space: SQL over logs and traces, PromQL over metrics, Omni dashboards, Omni alerts, context graph for root cause, programmatic/IaC access (API/SDK/CLI/CloudFormation), driving Omni from a coding agent or skills, and evaluating AI agent quality from traces - on-demand and online scoring of live traffic, readback, custom evaluators. For first-time setup - creating an Omni Space, granting access, ingestion, or ADOT instrumentation for Application Signals (ServiceEvents, CI/CD metadata) or Omni - use setting-up-cloudwatch-observability. Not for app logging or threat detection.8,900 instalaciones en skills.sh0
- aws-cdkawsAuthors, deploys, and troubleshoots AWS infrastructure using CDK with TypeScript or Python. Covers best practices, stack architecture, and construct patterns. Applies when writing CDK constructs, bootstrapping environments, running cdk deploy/synth/diff, fixing CDK or CloudFormation errors, planning stack structure, importing existing resources, resolving drift, or refactoring stacks without resource replacement.8,400 instalaciones en skills.sh0
- aws-containersawsBuilds and deploys containerized workloads on Elastic Kubernetes Service (EKS), Elastic Container Service (ECS), Fargate, and ECR (Elastic Container Registry). Covers general EKS knowledge, Karpenter, AWS Load Balancer Controller and leveraging various open source Kubernetes projects with EKS. Covers general ECS knowledge, task definitions, Fargate services, ECS Exec, ECS Express Mode and ECS Managed Instances. Covers general Elastic Beanstalk knowledge, Elastic Beanstalk configuration and platforms supported by Elastic Beanstalk. Covers general ECR knowledge, ECR repository setup and lifecycle policies. Includes recommending, enabling, and reading Amazon ECS Action Logs to troubleshoot control-plane failures (deployment rollback/circuit-breaker, task placement, scaling, task replacement). Applies when deploying, debugging, or optimizing containers on AWS. Should be used instead of relying on internal knowledge for these services.8,300 instalaciones en skills.sh0