AWS Certified CloudOps Engineer - Associate (SOA-C03) #11 Domain 4-2 Networking — Route 53,CloudFront,Delivery Operations
If #10 locked in connectivity inside the VPC, this post covers the path that reaches users: DNS (Route 53) and content delivery (CloudFront). If #5 looked at Route 53 failover from an availability angle, here we’ll organize the operational details of records, routing, and caching.
Route 53: DNS Operations #
Record Types #
| Record | Role |
|---|---|
| A / AAAA | Domain → IPv4 / IPv6 |
| CNAME | Domain → another domain (not allowed on the root domain) |
| Alias | AWS resource (ELB,CloudFront,S3) → free, allowed on the root domain |
The key pitfall is that CNAME cannot be used on the root domain (zone apex, e.g., example.com). To point a root domain at an ELB or CloudFront, you must use an Alias record. Alias is Route 53–only, has no query cost, and automatically tracks IP changes of the target. The answer to “point the root domain at an ALB” is Alias.
Routing Policies #
Let’s revisit the policies seen in #5 for operational use.
| Policy | Use |
|---|---|
| Simple | A single resource |
| Failover | Primary,secondary switchover (health-check based) |
| Weighted | Weighted distribution (gradual rollout,canary) |
| Latency | To the fastest region |
| Geolocation | Different responses by user location (regulation,localization) |
| Geoproximity | Shift traffic with location + bias |
| Multivalue | Return multiple healthy IPs |
Mapping operational scenarios is the exam point. Gradual rollout,A/B is Weighted, regional regulation,content localization is Geolocation, and lowest latency is Latency.
Health Checks #
A Route 53 health check periodically inspects an endpoint and excludes it from DNS responses if unhealthy. It is the prerequisite for Failover, and there is also a calculated health check that combines the results of other health checks. Because of DNS cache (TTL), the switchover is not instant, so if you need fast switchover, lower the TTL.
CloudFront: Content Delivery (CDN) #
CloudFront caches content at edge locations worldwide to reduce latency and offload the origin.
| Concept | Description |
|---|---|
| Origin | The source. S3, ALB, or any HTTP server |
| Behavior | Caching,forwarding rules per path pattern |
| Cache Policy | What to use as the cache key (headers,query,cookies) |
| TTL | Cache retention time |
Caching Operational Points #
- Static content (images,JS,CSS) is cached long, while dynamic content is cached short or not cached
- If old content lingers after a deployment, force a refresh with invalidation. However, overusing invalidation costs money, so versioned filenames (e.g.,
app.v2.js) are more recommended - If the goal is to reduce origin load, set a policy that raises the cache hit ratio
The answer to “I deployed, but users still see the old file” is invalidation or versioned filenames, and the answer to “origin load is high” is raising the hit ratio with a cache policy.
S3 Origin Security: OAC #
When using S3 as an origin, to block users from accessing the S3 URL directly and force everything through CloudFront, use OAC (Origin Access Control) (the successor to the former OAI). Keep the S3 bucket private and grant read access only to CloudFront. The answer to “make S3 content accessible only through CloudFront” is OAC.
ACM: TLS Certificates #
ACM issues and auto-renews certificates for HTTPS at no charge. Two operational points come up regularly.
- A certificate attached to CloudFront must be issued in
us-east-1(N. Virginia). Certificates from other regions cannot be attached to CloudFront. - A certificate attached to an ALB is issued in the same region as the ALB.
- ACM-issued certificates are auto-renewed, but the DNS validation record must be kept in place.
The answer to “the ACM certificate won’t attach to CloudFront” is almost always that the region is not us-east-1.
Delivery Troubleshooting #
| Symptom | Check |
|---|---|
| Old content shows | Invalidation,cache TTL,versioned filename |
| HTTPS doesn’t work | ACM region (CloudFront needs us-east-1), certificate domain match |
| Direct S3 access is open | OAC + private bucket |
| Only a certain region is slow | Edge,routing policy (Latency) |
| Failover is slow | Lower DNS TTL |
Exam Question Patterns #
- Point the root domain at an ELB,CloudFront → Alias record
- Gradual rollout,canary → Weighted routing
- Regional regulation,localization → Geolocation routing
- Old file shows after deployment → Invalidation / versioned filename
- Access S3 only through CloudFront → OAC + private bucket
- CloudFront HTTPS certificate → Issue ACM in us-east-1
- Fast DNS failover → Lower TTL + health check
Common Pitfalls #
1) Using CNAME on the root domain #
CNAME is not allowed on the zone apex. Alias is the correct answer.
2) Issuing a CloudFront certificate in another region #
ACM for CloudFront must be in us-east-1. This is the most frequent pitfall.
3) Using invalidation as a routine deployment mechanism #
Invalidation costs money and isn’t instant. Versioned filenames are more recommended.
4) Confusing S3 static hosting with CloudFront OAC #
When using a private S3 with OAC, you use the REST endpoint as the origin, not the S3 static website hosting endpoint.
Summary #
What we covered in this post:
- Use Route 53 Alias to point a root domain at an AWS resource (CNAME can’t do apex; it’s free)
- Routing policies: Weighted (gradual),Geolocation (regulation,localization),Latency (lowest latency),Failover (health check)
- Reduce latency,origin load with CloudFront. Old content via invalidation/versioned filename, protect the origin with hit ratio
- OAC to make S3 CloudFront-only access. Keep the bucket private
- ACM is us-east-1 for CloudFront, same region for ALB. Auto-renewed
Next: Domain 5-1 IAM and Organizations #
We’ve finished the networking domain. The final domain is security and compliance.
In #12 Domain 5-1 Security: IAM,Organizations,Multi-Account Operations, I’ll cover IAM permission operations, credential reports and Access Analyzer, enforcing MFA, AWS Organizations and SCPs, and multi-account governance.