ACM certificates are regional. Your us-east-1 cert is not your us-west-2 cert.
If you only renew the one CloudFront uses, the regional ALB cert silently expires.
AWS agencies running EC2 / ECS behind ALB with CloudFront and Route53 deal with ACM certs being regional and easy to forget duplicating, CloudFront-to-S3 SNI mismatches that cache the wrong response forever after a custom CNAME is added, and ACM auto-renewal silently stopping when DNS migrates off Route53. Merlonix monitors SSL and DNS so the regional ALB cert doesn't expire while the CloudFront copy looks healthy.
No credit card for the trial. Cancel any time.
- Check cadence (Agency)
- 5 min
- SSL pre-expiry alert
- 30 days
- Independent DNS resolvers
- 3
- Vendors watched
- 11
Where AWS agencies get caught out
Three failure modes specific to AWS deployments with ACM-managed certs across multiple regions, CloudFront-to-S3 origin SSL, and Route53 DNS migrations to other providers.
AWS agencies deal with ACM certs being regional and silent when the us-east-1 (CloudFront) copy renews but the us-west-2 (ALB) copy fails because validation CNAMEs were never set up, CloudFront-to-S3 SNI mismatches that cache the wrong response forever after a custom CNAME is added (cached old content works perfectly, invalidations fail), and ACM auto-renewal silently stopping when DNS migrates off Route53 because the _acm-validations CNAMEs got deleted during zone import.
ACM certificates are REGIONAL — a cert provisioned in us-east-1 (the only region CloudFront can use) is a separate ACM resource from a cert in us-west-2 (where your ALB lives). Agencies provision both at launch but only renew the us-east-1 copy because that's the one CloudFront references in the dashboard. The us-west-2 ALB cert silently expires while CloudFront keeps showing healthy
An AWS agency builds a client SaaS in us-west-2 with an ALB-fronted ECS service at api.client.com, plus a CloudFront distribution at app.client.com that uses a separate ACM cert in us-east-1. Both certs are provisioned at launch with auto-renewal enabled. A year later, the us-east-1 cert renews automatically — the agency confirms via the CloudFront dashboard. The us-west-2 cert ALSO needed Route53 validation CNAMEs, which were never set up because the engineer assumed the auto-renewal flag handled it. The us-west-2 ALB cert expires; ALB starts serving the previous cert until forced to rotate
An AWS agency builds a client B2B SaaS deployed to us-west-2 with an ECS service behind an ALB at api.client.com and static assets fronted by CloudFront at app.client.com. The agency provisions two ACM certificates at launch: one in us-east-1 (the only region CloudFront accepts certs from) for app.client.com, and a second in us-west-2 for the ALB at api.client.com. Both certs are configured with DNS validation against Route53 records. Auto-renewal is enabled on both. Twelve months pass. The us-east-1 cert renews cleanly — Route53 validation CNAMEs are present in the zone, ACM completes the renewal. The us-west-2 cert renewal attempts to validate against the SAME Route53 zone — but the engineer who set up the us-east-1 cert added the validation CNAME for that cert only, and the us-west-2 cert had different CNAMEs that were never created. The us-west-2 renewal fails silently. ACM eventually marks the cert as expired. The ALB continues to serve the old cert from cache for several days; once the cert expires, browsers and SDKs hit api.client.com with cert errors. The agency engineer logs into the AWS console, sees CloudFront's app.client.com cert is healthy and current, and assumes the issue is in ECS or ALB config rather than the ACM cert duplication. Discovery takes most of a day.
CloudFront origin connections to S3 over HTTPS break when an agency uses a custom CNAME on the CloudFront distribution but configures the S3 origin by bucket name. CloudFront forwards the Host header to the S3 origin, S3 attempts to serve the cert for cdn.client.com, but S3 only has its own *.s3.amazonaws.com cert. The TLS handshake fails. The first cached response (from initial setup before the CNAME was added) serves forever; subsequent invalidations can't fetch new content
An AWS agency creates a CloudFront distribution to serve client static assets from an S3 bucket. The distribution is initially configured without a custom domain — it serves from <distribution-id>.cloudfront.net. After QA, the agency adds cdn.client.com as an alternate domain name and configures Route53 to CNAME cdn.client.com → <distribution-id>.cloudfront.net. The agency forgets to update the S3 origin's Host header policy. CloudFront forwards cdn.client.com as the Host header to S3; S3 returns its s3.amazonaws.com cert; the TLS handshake fails. Cached content from before the CNAME continues to serve correctly; new content invalidations fail silently
An AWS agency builds a client e-commerce product where product images are served from S3 via CloudFront. The CloudFront distribution is created with the S3 bucket as origin, origin protocol policy set to "HTTPS Only" (security best practice). Initial QA tests against the .cloudfront.net distribution URL pass — TLS handshake to S3 origin works because CloudFront forwards the bucket's S3 hostname as the Host header, and S3 returns the matching *.s3.amazonaws.com cert. After QA, the agency adds the alternate domain cdn.client.com to the distribution and configures Route53 to point cdn.client.com at the .cloudfront.net distribution. Initial requests work because CloudFront serves from cache. The agency invalidates the cache for a content update; CloudFront tries to fetch new content from the S3 origin and forwards cdn.client.com as the Host header (because the distribution-level forwarding policy was never adjusted to use the bucket's actual hostname). S3 attempts to present a cert for cdn.client.com, finds none, returns its default *.s3.amazonaws.com cert. The TLS handshake fails. CloudFront returns 502 to clients trying to fetch invalidated content. Cached old content still serves perfectly. The agency engineer assumes the issue is the invalidation system and submits a ticket to AWS support; the actual fix is configuring the origin to use the S3 bucket hostname (not the distribution's alternate domain) as the forwarded Host.
ACM cert auto-renewal requires the original DNS validation CNAMEs to remain in the zone. When an agency moves DNS off Route53 (cost savings, vendor consolidation, or migration to Cloudflare for caching/security), the ACM validation CNAMEs go with the zone export — and the agency typically does not re-create them in the new DNS provider because they look like noise. ACM's next renewal attempt fails silently and the cert expires up to 60 days later
An AWS agency moves a client's DNS from Route53 to Cloudflare to add WAF and bot protection. The agency exports the Route53 zone, imports it into Cloudflare, and updates the registrar nameservers. The export captures all A, CNAME, and MX records — but the agency engineer reviewing the import deletes the "_acm-validations" CNAME records because they look like setup noise. ACM's next auto-renewal attempt 60 days later fails to validate; the cert expires. ALB starts serving the expired cert
An AWS agency operates a client product with DNS on Route53 and ACM-issued certs for both api.client.com (us-west-2 ALB) and app.client.com (us-east-1 CloudFront). The client requests adding Cloudflare in front for WAF rules and DDoS protection. The agency moves DNS to Cloudflare: exports the Route53 zone via the AWS CLI, imports the records into Cloudflare via the dashboard's zone import, updates the registrar to point at Cloudflare's nameservers. Both ACM-related "_acm-validations.<id>" CNAME records are present in the export, but the agency engineer reviewing the Cloudflare import deletes them — they look like leftover setup records that don't serve any obvious purpose. The migration completes successfully. Two months later, ACM's renewal cycle runs against api.client.com's cert. Validation requires querying the _acm-validations CNAMEs that were deleted. The renewal fails. The cert expires. The ALB continues serving the expired cert from cache; once cache expires, mobile apps and SDKs hit api.client.com with cert errors. The agency engineer doesn't connect the DNS migration to the cert expiry for several hours; once they do, re-creating the validation CNAMEs requires re-issuing the ACM cert (which requires NEW validation CNAMEs because the old ones are no longer linked).
How it works
SSL and DNS monitoring for AWS agencies across regional ACM certificate duplication, CloudFront-to-S3 origin SNI handshakes, and Route53 to Cloudflare DNS migrations.
Merlonix monitors SSL expiry and CNAME integrity across every AWS-attached subdomain — app.* (CloudFront), api.* (ALB), cdn.* (CloudFront + S3 origin), plus per-region ALB endpoints — and catches renewal failures caused by regional ACM cert duplication where us-east-1 (CloudFront) renews cleanly but us-west-2 (ALB) silently fails, CloudFront-to-S3 origin SNI mismatches that cache the wrong response forever after a custom CNAME is added, and DNS migration off Route53 that strips _acm-validations CNAMEs and breaks ACM auto-renewal — before the regional ALB cert expires while the CloudFront copy looks healthy in the AWS console.
01
Add AWS application domains — apex, www.*, app.*, api.*, cdn.*, plus per-region ALB endpoints — with DNS TXT record verification
Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — app.* (CloudFront-fronted), api.* (ALB-backed), cdn.* (CloudFront + S3 origin), plus any per-region ALB endpoints — are added without additional verification. Monitoring every AWS-attached subdomain catches the regional ACM cert duplication problem (us-east-1 CloudFront cert renewal succeeding while us-west-2 ALB cert renewal silently fails) by validating each cert independently rather than trusting the AWS console's region-scoped view. Under two minutes per client.
02
CNAME and A record monitoring across CloudFront aliases, ALB DNS names, S3 bucket origins, and Route53 vs Cloudflare DNS migrations that strip _acm-validations CNAMEs
Three independent DNS resolvers check every CNAME delegation on every monitoring interval. When a client moves DNS off Route53 to Cloudflare or another provider, the registrar nameserver change is logged immediately — alongside any missing _acm-validations CNAMEs that an aggressive zone-import cleanup may have removed. The ACM auto-renewal failure two months later has a clear root cause from the audit log rather than appearing as a mysterious "ACM cert expired" event with no obvious trigger.
03
SSL monitoring 30 days before expiry across us-east-1 ACM certs (CloudFront), per-region ACM certs (ALB), CloudFront-to-S3 origin SNI handshakes, and full chain validation across multi-region deployments
Full SSL chain validation on every AWS-attached subdomain — apex, app.*, api.*, cdn.*. Independent checks per-region catch the duplicated-ACM-cert renewal divergence pattern where the us-east-1 CloudFront cert renews cleanly but the us-west-2 ALB cert renewal silently fails because validation CNAMEs were never set up. CloudFront-to-S3 origin SSL is checked end-to-end so SNI mismatches that break invalidations (while serving cached old content perfectly) are caught before the next content update fails. An expiry alert fires 30 days before the certificate expires — enough lead time to identify whether the failure is a regional ACM cert without renewal CNAMEs, a CloudFront-to-S3 origin Host header mismatch, or DNS migration that stripped _acm-validations records.
04
Vendor status for AWS (per-region status pages — us-east-1, us-west-2, eu-west-1), CloudFront, Route53, and Cloudflare to distinguish AWS regional incidents from AWS-account-specific SSL configuration failures
Merlonix monitors AWS's per-region status pages, CloudFront, Route53, and Cloudflare alongside client SSL and DNS. When a us-east-1 ACM regional incident causes cert provisioning failures across multiple client accounts simultaneously, you see the vendor event — not a cluster of individual SSL alerts that each require separate investigation to determine whether the root cause is a us-east-1 ACM regional outage, a CloudFront-to-S3 SNI mismatch from a recent CNAME addition, or DNS migration that stripped _acm-validations CNAMEs.
What the numbers mean for AWS agencies
Monitoring built for AWS agencies where one client product means a CloudFront distribution at app.* (us-east-1 ACM cert), an ALB-fronted ECS service at api.* (us-west-2 ACM cert), and a CloudFront-to-S3 origin pipeline at cdn.* — each with independent cert lifecycles and independent failure modes.
AWS agencies managing ACM cert renewal across multi-region deployments, CloudFront-to-S3 origin SNI configurations across multi-CNAME distributions, and Route53 to Cloudflare DNS migrations across multi-client portfolios need monitoring that covers every AWS-attached subdomain — because a regional ACM cert renewal failure is silent until the cert expires up to 60 days later, and the AWS console shows the CloudFront copy as healthy while the regional ALB cert is silently failing.
< 10 min
Time from DNS change to alert — catches Route53-to-Cloudflare DNS migrations that strip _acm-validations CNAMEs, CloudFront alternate-domain CNAME flips that cause SNI mismatch on S3 origins, and per-region ALB DNS endpoint changes during multi-region failover
30 days
SSL expiry warning lead time — enough time to identify a regional ACM cert without renewal CNAMEs (the us-east-1 CloudFront copy renewed cleanly but us-west-2 ALB silently failed), a CloudFront-to-S3 origin Host header mismatch breaking invalidations, or a DNS migration that stripped _acm-validations records — and correct it before regional ALB serves an expired cert
11 vendors
Upstream services monitored — AWS per-region status pages (us-east-1, us-west-2, eu-west-1), CloudFront, Route53, and Cloudflare included to distinguish AWS regional incidents from account-specific SSL configuration failures
200 assets
Maximum monitored domains on the Agency plan — covers AWS app.* (CloudFront), api.* (per-region ALB), cdn.* (CloudFront + S3 origin), plus per-region ALB endpoints across a full AWS client portfolio
Pricing
Flat monthly fee. Every AWS region, every CloudFront distribution, every ALB endpoint included.
No per-region charges. No per-distribution fees. Pick the tier that fits your AWS client and per-region cert count and monitor every CloudFront, ALB, and CloudFront-to-S3 origin SSL surface without billing surprises.
Starter
For individual AWS developers managing a small client portfolio with single-region ACM certs and CloudFront distributions.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For AWS agencies managing multi-region ACM cert deployments with separate CloudFront, ALB, and S3 origin SSL surfaces.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full AWS client roster including multi-region ALB endpoints, multi-distribution CloudFront, and per-tenant subdomain SSL.
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when a regional ACM cert is about to expire while the CloudFront copy looks healthy.
Add your first AWS client domain in under two minutes. CloudFront, ALB, and CloudFront-to-S3 origin SSL across every region for that client are monitored from the same dashboard. 14-day trial, no card required.