Unit 5: The DNS and Network Routing; The Reliability Pillar

I. Orientation: DNS, Routing, and the Reliability Pillar

The Domain Name System translates human-readable names (example.com) into IP addresses (192.0.2.1), and the AWS Well-Architected Reliability Pillar ensures a workload performs its intended function correctly and consistently. This unit links the two: resilient naming and routing underpin available applications.

• DNS role: acts as the internet's distributed phone book; a resolver walks the hierarchy root → TLD (.com) → authoritative server to resolve a name.
• Reliability definition: the probability a system works over a given interval; measured as availability (uptime fraction).
• Core AWS services: Route 53 (DNS + routing), CloudFront (CDN edge delivery), EC2 Auto Scaling (elastic capacity), EFS/EBS (durable storage).
• Guiding assumption: everything fails eventually — design for redundancy across Availability Zones (AZs) and Regions, automate recovery, and avoid single points of failure.

II. Amazon Route 53 — Managed DNS and Traffic Routing

Route 53 is AWS's highly available, authoritative DNS service, named for TCP/UDP port 53, with a 100% availability SLA.

A. Introduction to Domain Name System (AWS)

Route 53 answers DNS queries using globally distributed authoritative name servers.

• Record types: A (IPv4), AAAA (IPv6), CNAME (alias to another name), MX (mail), TXT (verification), NS, SOA.
• Alias records: AWS-specific extension mapping a name directly to AWS resources (ELB, CloudFront, S3) at the zone apex, where CNAME is illegal; free of query charges.
• TTL: time-to-live in seconds controls how long resolvers cache an answer; low TTL (e.g., 60s) speeds failover but raises query volume.

B. Domain Registration

Route 53 can act as a domain registrar, buying and holding domain names.

• Process: search availability → register (annual fee varies by TLD, e.g., .com) → Route 53 auto-creates a hosted zone with four NS records.
• Management: auto-renewal, transfer locks, and WHOIS privacy protection are configurable; registration and DNS hosting can be decoupled (register elsewhere, host here).

C. DNS Management

Hosted zones hold the record sets Route 53 serves for a domain.

• Public hosted zone: resolves names on the open internet.
• Private hosted zone: resolves names only inside associated VPCs — used for internal service discovery.
• Record set: a name + type + value + routing policy; edits propagate within seconds across Route 53's fleet.

D. Availability Monitoring

Health checks let Route 53 route only to healthy endpoints.

• Endpoint check: periodic HTTP/HTTPS/TCP probe from multiple global checkers; endpoint deemed healthy if a configured fraction report success.
• Calculated health check: combines child checks with AND/OR logic.
• CloudWatch alarm check: marks unhealthy when a metric breaches a threshold.
• DNS failover: when a primary check fails, Route 53 stops returning that record and serves the secondary.

E. Routing Policies

A routing policy decides which record value Route 53 returns per query.

1. Simple vs. Weighted: Simple returns one static answer; Weighted splits traffic by assigned integers (e.g., 70/30) for A/B testing or gradual rollout.
2. Latency vs. Geolocation: Latency routes to the Region giving the lowest measured latency; Geolocation routes by the user's continent/country, useful for compliance or localized content.
   • Failover: returns primary unless its health check fails, then secondary.
   • Multivalue answer: returns up to eight healthy records at random, giving simple client-side load spreading.
   • Geoproximity: routes by geographic distance, adjustable with a bias to expand or shrink a resource's reach.

F. Traffic Flow

Traffic Flow is a visual editor for composing routing policies into one managed configuration.

• Policy records: nest latency, weighted, and failover rules into a tree applied to a DNS name.
• Versioning: each policy is versioned, enabling rollback to a prior routing configuration.

G. Route 53 Resolver

The Resolver answers DNS queries for resources inside and across VPCs.

• Default resolution: every VPC has a resolver at the .2 address (base CIDR + 2) handling AWS-internal names.
• Inbound endpoint: lets on-premises systems resolve AWS private names.
• Outbound endpoint + rules: forward specified domains from a VPC to on-premises DNS over Direct Connect or VPN — enabling hybrid name resolution.

III. Amazon CloudFront — Content Delivery Network

CloudFront caches content at global edge locations to cut latency and offload origins.

A. Distribution and Edge Caching

A distribution defines how content is served from an origin to edge caches.

• Origin: source of truth — S3 bucket, ELB, or custom HTTP server.
• Edge location: hundreds of global PoPs serving cached objects near users; a cache miss fetches from the origin and stores the object for its TTL.
• Behaviors: path patterns (e.g., /images/*) map to origins with distinct cache/TTL rules.

B. Security and Resilience Role

CloudFront improves both availability and protection.

• TLS/HTTPS: terminates TLS at the edge with ACM certificates.
• Origin Shield + AWS Shield: absorb DDoS traffic and reduce origin load, raising effective availability.

IV. The Reliability Pillar — Measuring and Designing Availability

A. Calculating Availability

Availability quantifies the fraction of time a system is operational.

Availability = Uptime / (Uptime + Downtime)
Annual downtime = (1 - Availability) × 525,600 min

• "Nines": 99.9% ("three nines") ≈ 8.76 h/yr downtime; 99.99% ≈ 52.6 min/yr.
• Series (hard dependency): multiply — two 99.9% components in series give 0.999 × 0.999 = 99.8%.
• Parallel (redundancy): 1 − (1 − A)^n — two 99% components in parallel give 1 − 0.01² = 99.99%.

B. Cloud-Native Application

Cloud-native apps are built to exploit elastic, managed, resilient cloud infrastructure.

• Statelessness: instances hold no session state, so any can serve any request and failed ones are replaceable.
• Microservices + managed services: decompose into independently scalable units backed by services like SQS, DynamoDB, and Lambda.
• Automation: infrastructure as code (CloudFormation) and auto-recovery remove manual intervention.

C. Designing for Availability

Target availability drives architecture choices and cost.

• Low (99%): single AZ, backups, manual recovery — tolerant workloads.
• Mid (99.9%): multi-AZ with automated failover and health checks.
• High (99.99%+): multi-Region, active-active, automated everything; cost rises sharply with each nine.
• Principle: match the nines to business need — over-engineering wastes cost.

V. EC2 Auto Scaling — Elastic Capacity

Auto Scaling adjusts the number of EC2 instances to match demand, replacing failed instances automatically.

A. Launch Configuration

A launch configuration is the legacy template defining how instances launch.

• Fields: AMI, instance type, key pair, security groups, user data.
• Limitation: immutable — must create a new one to change settings; superseded by launch templates.

B. Launch Templates

Launch templates are the modern, versioned replacement.

• Versioning: multiple versions per template; set a default or latest.
• Extra features: mixed instance types, Spot/On-Demand mix, T2/T3 unlimited, placement groups — unsupported by launch configurations.

C. Auto Scaling Groups

An Auto Scaling Group (ASG) manages a fleet across multiple AZs.

• Size parameters: minimum, desired, and maximum capacity bound the fleet.
• AZ spread: distributes instances across AZs for fault tolerance; replaces instances failing health checks (EC2 or ELB).

D. Auto Scaling Options

Scaling policies decide when to add or remove instances.

1. Dynamic vs. Scheduled: Dynamic reacts to metrics (CPU, request count); Scheduled changes capacity at known times (e.g., 9 a.m. peak).
2. Target tracking vs. Step scaling: Target tracking holds a metric at a value (e.g., 50% CPU); Step scaling adds instances in tiers per alarm breach. Predictive scaling uses ML on historical load to pre-provision.

VI. Data Durability — Backup, Storage, and Resiliency

A. Data Backup and Recovery

Backups protect against loss and define recovery targets.

• RPO: Recovery Point Objective — maximum tolerable data loss (time since last backup).
• RTO: Recovery Time Objective — maximum tolerable restore time.
• AWS Backup: centralized, policy-driven backups across EBS, EFS, RDS, DynamoDB.

B. Elastic File System

EFS is a managed, elastic NFS file system shared by many instances.

• Shared access: mounted concurrently across instances and AZs via mount targets.
• Durability: data stored redundantly across multiple AZs; scales automatically, pay per GB used.

C. Elastic Block Storage

EBS provides block volumes attached to a single EC2 instance.

• Volume types: gp3/gp2 (general SSD), io2 (high IOPS), st1/sc1 (throughput HDD).
• Snapshots: incremental, stored in S3, used to back up and clone volumes; replicated within a Region.
• Scope: AZ-bound — a volume lives in one AZ, restorable elsewhere via snapshot.

D. Data Resiliency

Resiliency ensures data survives component and site failures.

• Replication: S3 stores objects across ≥3 AZs (11 nines durability); cross-Region replication guards against Regional loss.
• Versioning + lifecycle: retain prior object versions; transition to Glacier for cost-efficient archival.

VII. Resilient Networking and Connectivity

A. Creating Resilient Network

A resilient VPC spans multiple AZs with redundant paths.

• Multi-AZ subnets: place subnets and NAT gateways in each AZ to survive an AZ outage.
• Load balancing: an ELB spreads traffic across healthy targets in all AZs.
• Redundant gateways: multiple internet/NAT gateways avoid single egress failure.

B. External Connecting

Hybrid links join on-premises networks to AWS.

1. VPN vs. Direct Connect: Site-to-Site VPN runs over the internet (fast to set up, variable latency); Direct Connect is a dedicated private line (consistent latency, higher throughput).
   • Redundancy: pair Direct Connect with a VPN backup, or use two Direct Connect links in different locations for resilient external connectivity.