Lesson 170 · AWS Learning Path

AWS 170: Configure DNS, TLS, caching, health, and controlled failover

· Published · 10 min read

Labelled process diagram for AWS 170: Owned DNS name and certificate to CloudFront behavior and origin to Health-controlled Route 53 answer to TLS, cache, and failover evidence, with decision, proof and rejection...

Why this lesson matters

Integrate a learner-owned domain, ACM certificate, CloudFront cache, Route 53 records, and health controls, with supplied evidence available during registration or validation delays.

This lab proves five separate systems: public delegation resolves the intended name, ACM validates and issues the correct certificate, CloudFront terminates viewer TLS and applies a safe cache key, an origin is inaccessible except through the approved path, and controlled DNS/health changes recover without inventing zero-downtime or zero-data-loss claims.

What you will be able to do

By the end, you can:

  • explain configure dns, tls, caching, health, and controlled failover in plain language;
  • locate the current service controls in the AWS Management Console;
  • run the matching CloudShell or AWS CLI queries and explain every important field;
  • draw the identity, network, data, failure, and monitoring path;
  • choose the service from requirements and reject it when those requirements are absent;
  • diagnose a failed or misleading result from evidence;
  • state the cost owner and prove cleanup or a no-create result.

Before you start

  • Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
  • CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
  • The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
  • Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
  • Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
  • This lesson has an optional live path. Check current prices, obtain the account owner's approval, set a hard timer, use course tags, and complete the stated cleanup. The evidence path is a complete alternative.
  • Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

QuestionWhat it means in this lesson
PurposeIntegrate a learner-owned domain, ACM certificate, CloudFront cache, Route 53 records, and health controls, with supplied evidence available during registration or validation delays.
Scope and boundaryThe learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for DNS, TLS, caching, health, and failover lab.
Evidence of successSuccess means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for DNS, TLS, caching, health, and failover lab.
Cost modelHosted zone, health check, CloudFront requests and transfer, logs, origins, certificates outside ACM-integrated use, and retained resources must be reviewed.
Safe rejection ruleAvoid using a domain the learner does not control, deleting shared zone records, inventing certificate validation, or leaving distributions and health checks running.

How the request flows

+----------------------------------+
|  Owned DNS name and certificate  |
+----------------------------------+
                 |
                 v
+----------------------------------+
|  CloudFront behavior and origin  |
+----------------------------------+
                 |
                 v
+-------------------------------------+
|  Health-controlled Route 53 answer  |
+-------------------------------------+
                  |
                  v
+-------------------------------------+
|  TLS, cache, and failover evidence  |
+-------------------------------------+

For DNS, TLS, caching, health, and failover lab, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for DNS, TLS, caching, health, and failover lab. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for DNS, TLS, caching, health, and failover lab. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.

Architecture decision table

SituationDirectionReason
Requirement matchesUse the live track with a learner-owned or delegated domain, current-price approval, exact rollback values, and a short timer.Select only after scope, behavior, security, recovery, operations, and price evidence agree.
Requirement does not matchAvoid using a domain the learner does not control, deleting shared zone records, inventing certificate validation, or leaving distributions and health checks running.Rejecting an attractive service is a valid architecture result.
No create permission or cost approvalUse supplied evidence and local design workLearning does not depend on creating an hourly resource.
Existing resource is unknown or unownedInspect only, then stopNever change or delete a resource merely because it resembles a course example.

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

  1. Use the Console service search and open Route 53, ACM, CloudFront, and health checks using only an owned domain; confirm the account and Region before reading the page.
  2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
  3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
  4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws route53 list-hosted-zones --output table
aws acm list-certificates --region us-east-1 --query 'CertificateSummaryList[].{Domain:DomainName,Status:Status,Arn:CertificateArn}' --output table
aws cloudfront list-distributions --query 'DistributionList.Items[].{Id:Id,Status:Status,Domain:DomainName,Aliases:Aliases.Items}' --output json
aws route53 list-health-checks --output table

Expected interpretation

The live pass requires correct authoritative DNS, ISSUED certificate in the resource-required Region, deployed distribution, tested cache hit and miss, controlled health change, rollback, and empty temporary inventory.

Practical work

Complete p05-edge-lab-evidence.md. The normal live track uses a learner-owned domain or delegated subdomain. The learner may register a course domain after approving registration and renewal cost. A supplied-evidence track covers registration or validation delays.

Learner-owned domain lab

The normal live track uses a learner-owned domain or a delegated subdomain. The learner may register a course domain when the registration fee, renewal price, contact-data handling, auto-renew setting, and long-term owner have been approved. Domain registration is not a temporary resource that can always be refunded or deleted, so record it as retained state.

Phase 0: change record and preflight

Create p05-edge-lab-evidence.md before mutation. Record owner, account, Route 53 and us-east-1 Regions, domain/subdomain, current registrar/NS/DS, every existing record/TTL, origin/distribution identifiers, current price estimate, timer, rollback values and delegated-domain retention owner. Never transfer or replace a production zone. Prefer a delegated course subdomain from an owner-controlled parent.

Use public resolvers and authoritative servers to capture baseline:

set -euo pipefail
export LAB_NAME="edge-lab.example.invalid"
dig +trace "$LAB_NAME" A
dig "$LAB_NAME" A +noall +answer +authority
dig "$LAB_NAME" AAAA +noall +answer +authority

Replace .invalid only with an approved owned public name. Do not expect .invalid to resolve. Lower a cutover TTL one old-TTL interval before changing traffic; if that waiting period did not occur, document that rollback can be delayed.

Phase 1: origin and CloudFront

Use only synthetic static objects in a dedicated S3 bucket. Enable Block Public Access, versioning, default encryption and an exact lifecycle/cleanup owner. Create a CloudFront distribution with the S3 REST origin and OAC; bucket policy permits s3:GetObject only to the distribution source ARN. Default behavior allows GET/HEAD, redirects HTTP to HTTPS, compresses, and uses a managed/custom cache policy whose key is documented. Do not use the public S3 website endpoint when OAC is required.

Upload version.txt containing a random lab marker. Prove direct unauthenticated S3 request is denied and CloudFront returns it. Request twice and record Age, X-Cache, Via, ETag and request ID. Upload a new version under version-v2.txt to demonstrate versioned filenames; use one exact-path invalidation only as a separate exercise.

Phase 2: ACM and alternate name

Request a public ACM certificate in us-east-1 for the exact lab name. Create the ACM-provided CNAME validation record without changing its name/value, wait with a bounded timer and record PENDING_VALIDATION or ISSUED honestly. ACM DNS validation CNAME may remain to support renewal. Attach only after issuance, add alternate domain, deploy, then create a Route 53 alias A and, if distribution/name design supports it, AAAA to CloudFront.

Validate from outside the owner account:

dig "$LAB_NAME" A +noall +answer
openssl s_client -connect "${LAB_NAME}:443" -servername "$LAB_NAME" -verify_return_error </dev/null
curl -fsS -D - "https://${LAB_NAME}/version.txt" -o /dev/null

Inspect SAN, issuer, chain, validation, not-before/not-after and hostname. Never use -k/--insecure as a fix.

Phase 3: controlled health and failover

CloudFront already has global edge resilience; adding Route 53 endpoint health to one CloudFront name is not automatically meaningful. Use supplied evidence or two approved Regional application endpoints for the failover exercise. Define primary/secondary matching record sets, a public endpoint check or supported evaluate-target-health, and a low planned TTL. Prove secondary data/certificate/capacity before fault injection.

Block only the lab health path or use a controlled CloudWatch alarm. Record fault time, checker transition, authoritative answer, recursive-cache expiry, first secondary success and achieved RTO/RPO. Restore primary, require a stability window, then fail back with approval. Never stop/delete an unowned production endpoint to demonstrate failover.

Complete no-create evidence path

The supplied pack must include registrar delegation, authoritative/recursive answers over time, ACM validation and certificate chain, CloudFront distribution/OAC/bucket policy, hit/miss headers, origin denial, WAF/health events and failover timeline. The learner must diagnose at least one intentionally mismatched hostname, stale resolver and origin 403, propose exact repairs, and produce the same cleanup/retention ledger. Screenshots alone do not pass.

Create or delegate a dedicated course subdomain and export any existing record values before changing them. Use ACM in us-east-1 for a CloudFront viewer certificate, complete real DNS validation, wait for ISSUED, attach it to the distribution, and test with dig, openssl s_client, and curl -I. Record Age, Via, X-Cache, certificate names and dates, DNS TTL, and the health timeline. Restore the approved DNS state before deleting temporary health checks and the distribution. CloudFront deletion requires disabling the distribution and waiting for deployment first. If registration or public validation is delayed, the supplied evidence track remains available so the lesson can continue without inventing a successful result.

Diagnose this topic from its own evidence

SymptomFirst evidenceCorrect boundary
name does not resolvedig +trace, parent NS/DS and authoritative answerregistration/delegation/record, not CloudFront cache
ACM remains pendingACM validation CNAME queried from public authoritative DNSwrong zone/name/value, CAA/delegation or propagation
TLS name/chain failsSNI openssl, distribution aliases/certificate/statuscertificate Region/SAN/attachment/deployment
CloudFront 403request ID, WAF/signed access, behavior/origin, S3 policy/OACisolate edge policy versus origin authorization
old contentcache key, Age/TTL/ETag/object version and browser cachefreshness/versioning/invalidation, not DNS
failover is slowchecker timeline, authoritative answer, recursive TTL/connection reusedetection plus cache/application behavior

Change one layer only. Preserve the failing query/header/request ID and retest from the same and an independent resolver/client.

Cost and cleanup

Hosted zone, health check, CloudFront requests and transfer, logs, origins, certificates outside ACM-integrated use, and retained resources must be reviewed.

Knowledge check

  1. What operational purpose is this lesson solving?

Expected direction: Integrate a learner-owned domain, ACM certificate, CloudFront cache, Route 53 records, and health controls, with supplied evidence available during registration or validation delays.

  1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for DNS, TLS, caching, health, and failover lab.

  1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for DNS, TLS, caching, health, and failover lab.

  1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid using a domain the learner does not control, deleting shared zone records, inventing certificate validation, or leaving distributions and health checks running.

  1. Which cost dimensions and retained resources need an owner?

Expected direction: Hosted zone, health check, CloudFront requests and transfer, logs, origins, certificates outside ACM-integrated use, and retained resources must be reviewed.

Lesson acceptance

Pass when baseline/change/rollback values exist; public delegation, certificate hostname/chain, private origin, cache hit/miss and controlled failover are independently proven; the UTC timeline calculates recovery; and no unsafe public bucket, insecure TLS or false zero-loss claim appears. Final evidence must show distribution disabled/deleted if temporary, health checks removed, S3 versions/delete markers removed, temporary records restored/deleted, ACM certificate deleted only if unreferenced, and the registered/delegated domain's renewal/retention owner. A delayed billing review is mandatory.

Official sources

Advertisement