Setting Up DNS-01 Validation with AWS Route 53

If your domain's DNS is hosted on AWS Route 53, automating DNS-01 validation for a wildcard certificate means giving your ACME client permission to create and delete TXT records in your hosted zone — narrowly, not broad AWS account access.

1. Create a scoped IAM policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "route53:GetChange",
      "Resource": "arn:aws:route53:::change/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets"
      ],
      "Resource": "arn:aws:route53:::hostedzone/YOUR_ZONE_ID"
    },
    {
      "Effect": "Allow",
      "Action": "route53:ListHostedZonesByName",
      "Resource": "*"
    }
  ]
}

Scoping the record-editing permission to your specific hosted zone ID, rather than granting it across every zone on the account, means a leaked credential can only affect the one domain — find your zone ID in the Route 53 console under Hosted Zones.

2. Create an IAM user with this policy attached

Create a dedicated IAM user for this specific purpose (not your own root or admin credentials), attach the policy above, and generate an access key pair for it. Using a purpose-specific IAM user rather than broader existing credentials keeps this automation's permissions auditable and independently revocable if you ever need to rotate or disable it without affecting anything else.

3. Configure Certbot's Route 53 plugin

pip install certbot-dns-route53 --break-system-packages

export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key

certbot certonly \
  --dns-route53 \
  -d "*.yourdomain.com" -d "yourdomain.com"

Certbot's Route 53 plugin uses the standard AWS credential chain, so the environment variables above work, as would a configured ~/.aws/credentials file or an EC2 instance role if you're running this from an AWS-hosted server — in which case an instance role is generally the better option, since it avoids storing long-lived credentials on disk entirely.

Using an EC2 instance role instead of static credentials

If your renewal automation runs on an EC2 instance already, attaching an IAM role with the same policy to that instance, rather than using static access keys, is the more secure option — the AWS SDK Certbot's plugin relies on automatically picks up instance role credentials with no configuration needed, and there's no long-lived secret to leak or rotate at all.

Confirming it works before relying on it

certbot renew --dry-run

Route 53 propagates changes quickly in most cases, but Certbot's plugin includes its own propagation wait by default — if you're seeing intermittent validation failures, the same kind of increased-wait flag covered for other DNS providers applies here too, worth checking Certbot's Route 53 plugin documentation for the exact current flag name.