Amplify domain association stuck in AWAITING_APP_CNAME after the ACM certificate has already been issued - will it still auto-renew?

Question

My certificate is already ISSUED and serving traffic. What has not completed is Amplify's subdomain verification. I want to know whether the certificate will still auto-renew if the domain association never reaches AVAILABLE.

I am aware of the 24-48 hour propagation window and am not asking whether to wait. This is distinct from the usual ACM validation failures, because ACM validation succeeded.

**Environment**
- App ID: d1fez1b1fdztir
- Region: ca-central-1
- DNS provider: Cloudflare, DNS only (grey cloud) on every record

**Current state**

`aws amplify get-domain-association`

domainStatus: AWAITING_APP_CNAME
    subDomains[0] (apex): verified false, expects CNAME .cloudfront.net
    subDomains[1] (www):  verified false, expects CNAME .cloudfront.net
    certificate.type: AMPLIFY_MANAGED

Both apex and www serve correctly over HTTPS. Browser shows the Amplify-managed certificate: `*.`, issued by Amazon RSA 2048 M03, valid 2 Sep 2026 to 19 Mar 2027. Amplify's "SSL creation" step completed successfully.

**DNS verification**

Apex uses Cloudflare CNAME flattening, which the AWS Cloudflare documentation presents as the supported approach for the apex. Flattening returns A records where Amplify's expected record is a CNAME:

dig @  A
      four CloudFront edge IPs

dig @8.8.8.8  A
      four different CloudFront edge IPs, as expected for a geo-distributed distribution

www resolves as a CNAME to the CloudFront target from both the authoritative Cloudflare nameservers and 1.1.1.1. The ACM validation CNAME resolves correctly to its acm-validations.aws target.

**Already ruled out**
- No CAA records on the domain
- DNSSEC not enabled (AD flag false on validating resolvers)
- No competing TXT or A records at the validation record name
- No doubled domain suffix on any record name
- DNS records added within minutes of creating the association
- Nothing proxied through Cloudflare at any point

**History**

Two earlier associations timed out with AmplifyWaitTimeout while DNS was hosted at a previous provider. DNS was then migrated to Cloudflare and the association recreated once, cleanly. I have not deleted and recreated since, having seen other threads where repeated recreation produced CloudFront alias conflicts.

**Questions**

1. If the association never reaches AVAILABLE, will the Amplify-managed certificate still auto-renew before it expires? This is the only thing that concerns me, as the site is serving correctly today.

2. Does Cloudflare's CNAME flattening at the apex prevent Amplify's subdomain verification, given Amplify expects a CNAME and flattening returns A records? The AWS Cloudflare documentation recommends flattening, so if this is a known incompatibility it would be worth documenting.

3. Is there a supported way to resolve this without deleting and recreating the association? Recreating would take a live production site offline, and I understand certificate verification cannot be manually triggered.

Takahiro Nozaki · Answer

One thing in your own data cuts against your leading hypothesis, and I think it's the most useful place to start.

## The www subdomain disproves the flattening theory (Q2)

You report that `www` resolves as a proper CNAME to the CloudFront target from both Cloudflare's authoritative nameservers and 1.1.1.1 — and yet `subDomains[1] (www)` is still `verified: false`.

Flattening only applies at the apex. If flattening were the cause, `www` should have verified and only the apex would be stuck. Both being unverified means something upstream of the DNS shape is wrong.

Two things worth checking before anything else:

**The CNAME target must match exactly.** Each Amplify app gets its own CloudFront distribution. Compare the `dnsRecord` value from `get-domain-association` character-by-character against what's actually in Cloudflare. A stale target from one of the two earlier timed-out associations would produce exactly this symptom — the site serves fine (the old distribution may still answer), but Amplify's check against *its* expected target fails.

**Check `statusReason`.** Your paste omits it. This field exists specifically to describe why the association sits in its current state, and it often names the actual blocker.

```bash
aws amplify get-domain-association --app-id d1fez1b1fdztir \
  --domain-name  --region ca-central-1 \
  --query 'domainAssociation.[statusReason,updateStatus,certificate]'
```

If `statusReason` is empty and the targets match exactly, then this is genuinely stuck state on Amplify's side rather than a DNS problem, and support is the path.

## Q1: renewal

The honest answer is that I can't give you a guarantee here, and the available evidence points in two directions.

The mechanical view is reassuring: ACM DNS-validated renewal depends on the `_` → `.acm-validations.aws` CNAME remaining resolvable, which you've confirmed it is. Renewal typically begins around 60 days before expiry — mid-January 2027 for your 19 Mar 2027 cert.

The concerning view comes from AWS's own guidance on expired Amplify-managed certificates: the stated remedy when renewal fails is to delete and re-add the domain in the Amplify console. That phrasing implies renewal is driven through the domain association, not purely by ACM in isolation. The documented failure mode is a modified or deleted verification record — which isn't your situation — but it does suggest the association is part of the renewal path.

I'd treat this as unresolved rather than safe. You have roughly four months before renewal would start, which is enough runway to get a definitive answer from support rather than discovering the outcome in January.

## Q3: resolving without delete/recreate

`update-domain-association` is the supported non-destructive lever. It's a distinct operation with its own `updateStatus` field, and it can re-drive the state machine without tearing down the association:

```bash
aws amplify update-domain-association --app-id d1fez1b1fdztir \
  --domain-name  --region ca-central-1 \
  --sub-domain-settings prefix="",branchName= \
                        prefix=www,branchName=
```

Then watch `updateStatus` separately from `domainStatus`.

Your instinct to avoid delete/recreate is right, and for a reason beyond downtime: repeated recreation is what produces the orphaned CloudFront alias conflicts you've seen in other threads, where the alias gets stranded in an AWS-managed account that you can't reach. Given you already have two timed-out associations in this domain's history, you're closer to that failure mode than most.

## Suggested order

1. Pull `statusReason` and diff the expected `dnsRecord` against Cloudflare, exactly
2. If they match, try `update-domain-association` before anything destructive
3. Open a support case on the renewal question specifically — frame it as "will an Amplify-managed certificate renew while the association is in AWAITING_APP_CNAME," not as a general stuck-domain ticket, so it reaches someone who can answer definitively

If step 1 turns up a target mismatch, that likely explains the whole thing and Q1 becomes moot once the association reaches AVAILABLE.

whci98 · Answer

**Resolved.**

Status went to AVAILABLE roughly 3 hours after adding the CNAME records, with no intervention. Note that the apex subdomain still shows verified: false while www shows true - that appears to be Cloudflare's CNAME flattening returning A records where Amplify's per-subdomain check expects a CNAME. It does not block the overall association, which reaches AVAILABLE anyway, and the certificate issues and serves correctly. If you're stuck in AWAITING_APP_CNAME with correct DNS, wait rather than recreating the association.

Amplify domain association stuck in AWAITING_APP_CNAME after the ACM certificate has already been issued - will it still auto-renew?

The www subdomain disproves the flattening theory (Q2)

Q1: renewal

Q3: resolving without delete/recreate

Suggested order

Add your answer

Relevant content