Unit 5: The DNS and Network Routing; The Reliability Pillar - Subjective Questions

The Domain Name System (DNS) is a hierarchical, distributed naming system that translates human-readable domain names (e.g., www.example.com) into machine-readable IP addresses (e.g., 192.0.2.1).

Role in AWS:

• Acts as the phonebook of the internet, resolving names to IP addresses so users can reach resources.
• In AWS, DNS is primarily delivered through Amazon Route 53, a highly available and scalable DNS web service.
• Supports IPv4 (A records) and IPv6 (AAAA records) resolution.
• Enables routing of end-user requests to AWS resources such as EC2 instances, Elastic Load Balancers, S3 buckets, and CloudFront distributions.

Key DNS concepts:

• Recursive resolver: Receives queries from clients and resolves them.
• Authoritative name server: Holds the actual DNS records for a domain.
• TTL (Time To Live): Controls how long records are cached.

DNS is critical for availability and performance because it determines which endpoint a user connects to.

Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service designed to give developers and businesses a reliable way to route end users to internet applications.

Three main functions:

1. Domain Registration

   • Allows users to register new domain names (e.g., .com, .net, .org).
   • Manages domain renewals and transfers.

2. DNS Management (Routing)

   • Translates domain names into IP addresses.
   • Supports record types such as A, AAAA, CNAME, MX, TXT, NS, SOA.
   • Offers multiple routing policies (simple, weighted, latency-based, failover, geolocation, geoproximity, multivalue).

3. Health Checking / Availability Monitoring

   • Monitors the health and performance of applications and endpoints.
   • Can automatically reroute traffic away from unhealthy resources.

Key benefits:

• 100% availability SLA for the DNS service.
• Deep integration with other AWS services.
• Global network of DNS servers for low-latency resolution.

Amazon Route 53 provides several routing policies to control how DNS queries are answered:

• Simple Routing: Routes traffic to a single resource. No health checks. Used for a single server/endpoint.

• Weighted Routing: Distributes traffic across multiple resources based on assigned weights (e.g., 70/30 split). Useful for A/B testing and gradual rollouts.

• Latency-Based Routing: Routes users to the AWS region that provides the lowest latency, improving performance.

• Failover Routing: Routes traffic to a primary resource, and automatically to a secondary (standby) resource if the primary fails a health check. Used for active-passive setups.

• Geolocation Routing: Routes based on the geographic location of the user (continent, country, or state). Useful for localization and compliance.

• Geoproximity Routing: Routes based on the geographic location of resources, with the ability to bias traffic toward certain regions (requires Traffic Flow).

• Multivalue Answer Routing: Returns multiple healthy IP addresses in response to DNS queries, providing a simple form of load balancing with health checks.

Each policy supports health checks (except simple) to improve availability.

Both Launch Configurations and Launch Templates define the configuration that EC2 Auto Scaling uses to launch instances, but they differ significantly.

Launch Configuration:

• A template that specifies AMI, instance type, key pair, security groups, and block device mappings.
• Immutable — any change requires creating a new configuration.

Launch Template:

• More flexible and feature-rich.
• Supports versioning, allowing you to track changes and roll back.
• Can be used by Auto Scaling, Spot Fleet, and EC2 directly.

Recommendation: AWS recommends using Launch Templates as Launch Configurations are being phased out.

EC2 Auto Scaling is an AWS service that automatically adjusts the number of EC2 instances in an Auto Scaling Group (ASG) to maintain application availability and match demand.

Benefits:

• Better fault tolerance — replaces unhealthy instances.
• Better availability — ensures the right capacity is always running.
• Better cost management — scales in during low demand.

Scaling Options:

1. Manual Scaling

   • Manually change the desired capacity of the ASG.

2. Scheduled Scaling

   • Scale based on predictable time-based patterns (e.g., scale up every weekday at 9 AM).

3. Dynamic Scaling (reactive)

   • Target Tracking Scaling: Maintains a target metric (e.g., keep CPU at 50%).
   • Step Scaling: Scales in defined steps based on alarm thresholds.
   • Simple Scaling: Single scaling adjustment based on a single alarm.

4. Predictive Scaling

   • Uses machine learning to forecast future traffic and provision capacity in advance.

Key components: Minimum capacity, Maximum capacity, and Desired capacity define the scaling boundaries.

Availability is the percentage of time a system is operational and accessible.

Basic formula:

Alternatively using MTBF and MTTR:

where MTBF = Mean Time Between Failures and MTTR = Mean Time To Repair.

Components in Series (hard dependencies):

Total availability is the product of individual availabilities:

Example: Two components each with 99% availability in series:

Series dependencies reduce overall availability.

Components in Parallel (redundancy):

Example: Two components each with 99% availability in parallel:

Redundancy increases availability.

The "Nines":

Higher nines mean greater reliability but higher cost.

Amazon CloudFront is a fast Content Delivery Network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds.

How it works:

• Uses a global network of Edge Locations and Regional Edge Caches.
• Content is cached at edge locations close to users.
• When a user requests content, CloudFront serves it from the nearest edge location, reducing latency.

How it improves availability:

• Offloads traffic from origin servers, reducing load.
• Provides redundancy — if one edge location fails, requests route to another.
• Integrates with AWS Shield and AWS WAF for DDoS protection.
• Can serve cached content even if the origin is temporarily unavailable.

How it improves performance:

• Reduces latency by serving content geographically closer to users.
• Reduces origin load through caching.
• Supports persistent connections and compression.

Origins can be S3 buckets, EC2 instances, Elastic Load Balancers, or custom HTTP servers.

Both EBS and EFS provide storage for AWS workloads but serve different use cases.

Amazon EBS (Elastic Block Store):

• Provides persistent block-level storage volumes for EC2 instances.
• Volume types include gp3/gp2 (SSD), io2/io1 (Provisioned IOPS), st1 (throughput HDD), sc1 (cold HDD).
• Supports snapshots stored in S3 for backup.
• Tied to a single Availability Zone.

Amazon EFS (Elastic File System):

• Fully managed, shared file system that can be mounted by many instances concurrently.
• Automatically grows and shrinks as files are added/removed.
• Spans multiple Availability Zones for high availability.
• Ideal for shared workloads, web serving, and content repositories.

Data Backup and Recovery refers to the strategies and services used to protect data from loss and to restore it after a failure or disaster.

AWS Backup Services:

• EBS Snapshots: Point-in-time backups of EBS volumes stored in S3.
• AWS Backup: Centralized, policy-based backup across services (EBS, EFS, RDS, DynamoDB).
• S3 Versioning & Cross-Region Replication: Protects objects.
• RDS Automated Backups and Snapshots.

Key Recovery Metrics:

• RPO (Recovery Point Objective):

  • The maximum acceptable amount of data loss measured in time.
  • Example: An RPO of 1 hour means you can tolerate losing up to 1 hour of data.
  • Determines backup frequency.

• RTO (Recovery Time Objective):

  • The maximum acceptable downtime — how quickly you must recover.
  • Example: An RTO of 2 hours means the system must be restored within 2 hours.

Disaster Recovery Strategies (by increasing cost/decreasing RTO/RPO):

1. Backup & Restore — lowest cost, highest RTO.
2. Pilot Light — minimal core running.
3. Warm Standby — scaled-down full environment.
4. Multi-Site Active-Active — highest cost, near-zero RTO/RPO.

A Cloud-Native Application is an application specifically designed and built to run in the cloud, taking full advantage of cloud computing models to deliver scalability, resilience, and agility.

Key Characteristics:

• Microservices Architecture

  • Applications are broken into small, independent, loosely coupled services.
  • Each service can be deployed and scaled independently.

• Containerization

  • Services are packaged in containers (e.g., Docker) orchestrated by Kubernetes (EKS) or ECS.

• Dynamic Scalability (Elasticity)

  • Automatically scales up/down based on demand using services like EC2 Auto Scaling.

• Resilience and Fault Tolerance

  • Designed to handle failures gracefully with redundancy across multiple Availability Zones.

• DevOps and Automation (CI/CD)

  • Uses automated pipelines for continuous integration and delivery.

• Managed/Serverless Services

  • Leverages services like AWS Lambda, DynamoDB, S3 to reduce operational overhead.

• Statelessness

  • Components are designed to be stateless where possible, improving scalability.

Benefits: Faster time to market, improved scalability, better resource utilization, and higher resilience.

Amazon Route 53 Resolver is a regional DNS service that provides recursive DNS resolution for workloads running inside a VPC and for hybrid environments connecting on-premises networks to AWS.

Default behavior:

• Every VPC includes a default DNS resolver (the Amazon-provided DNS, often called the .2 resolver or VPC+2 address).
• Resolves domain names for AWS resources and public internet names.

Two types of resolver endpoints (for hybrid DNS):

1. Inbound Endpoint

   • Allows on-premises DNS resolvers to forward queries to Route 53 Resolver in the VPC.
   • Enables on-premises systems to resolve AWS private hosted zone records.

2. Outbound Endpoint

   • Allows Route 53 Resolver to forward queries from the VPC to on-premises DNS resolvers.
   • Uses Resolver Rules to specify which domains to forward.

Benefits:

• Enables seamless hybrid DNS resolution between on-premises and AWS.
• Supports DNS query logging and DNS Firewall for security.

This bidirectional resolution is essential for hybrid cloud architectures.

An Auto Scaling Group (ASG) is a logical collection of EC2 instances managed together for the purposes of automatic scaling and management.

Key Components / Settings:

• Launch Template / Launch Configuration: Defines the instance configuration (AMI, instance type, etc.).

• Capacity settings:

  • Minimum capacity: The lowest number of instances to maintain.
  • Desired capacity: The target number of instances.
  • Maximum capacity: The upper limit of instances.

• Availability Zones / Subnets: Instances are distributed across multiple AZs for fault tolerance.

• Scaling Policies: Define how and when to scale (target tracking, step, scheduled, predictive).

• Load Balancer attachment: Distributes traffic across instances.

Health Checks:

• EC2 Health Checks: Monitor the status of the EC2 instance (system/instance status).
• ELB Health Checks: Monitor application-level health via the load balancer.
• Custom Health Checks: Based on custom metrics.

How they maintain reliability:

• If an instance is marked unhealthy, the ASG automatically terminates it and launches a replacement.
• This ensures the application always runs at the desired capacity with healthy instances, providing self-healing behavior.

Route 53 Traffic Flow is a visual tool and routing management feature that makes it easy to create and manage complex routing configurations by combining multiple routing policies.

Key Features:

• Visual Editor: A graphical interface to build routing decisions as a flowchart/tree.

• Combining Policies: Allows chaining of multiple routing policies (e.g., geolocation → latency → weighted → failover) in a single configuration.

• Traffic Policies: Reusable configurations that define how traffic is routed.

• Traffic Policy Versions: Supports versioning and rollback of routing configurations.

• Policy Records: Apply a traffic policy to a specific DNS name in a hosted zone.

How it simplifies configuration:

• Without Traffic Flow, combining several routing policies requires manually chaining many individual records, which is complex and error-prone.
• Traffic Flow lets you visually design sophisticated routing (e.g., route by region, then by latency, with failover) in one place.
• Supports geoproximity routing with bias, which is only available through Traffic Flow.

Example use case: Route European users to EU servers using the lowest-latency endpoint, with automatic failover to a backup region if the primary is unhealthy.

Data Resiliency is the ability of data and data systems to recover quickly and continue operating despite failures, corruption, or disasters. It ensures data remains available, durable, and intact.

Techniques to Achieve Data Resiliency in AWS:

• Redundancy / Replication

  • S3 automatically stores data redundantly across multiple AZs (11 nines of durability — ).
  • Cross-Region Replication (CRR) copies data to another region.

• Multi-AZ Deployments

  • Services like RDS Multi-AZ maintain synchronous standby replicas in a different AZ.

• Backups and Snapshots

  • EBS Snapshots and AWS Backup provide point-in-time recovery.

• Versioning

  • S3 Versioning protects against accidental deletions and overwrites.

• EFS and EBS durability features

  • EFS stores data across multiple AZs; EBS provides replication within an AZ.

• Disaster Recovery Strategies

  • Backup & Restore, Pilot Light, Warm Standby, Multi-Site.

Benefits:

• Protection against hardware failure, data corruption, accidental deletion, and regional outages.
• Ensures compliance with RPO and RTO objectives.

A resilient network is designed to withstand failures and maintain connectivity and performance. In AWS, this is achieved through redundancy, distribution, and automation.

Key Design Elements:

• Multiple Availability Zones (AZs)

  • Deploy resources (subnets, instances) across at least two AZs to tolerate the failure of a single AZ.

• Multiple Regions

  • For the highest resilience, replicate across regions to survive regional outages.

• Elastic Load Balancing (ELB)

  • Distributes traffic across healthy instances in multiple AZs and performs health checks.

• Auto Scaling

  • Automatically replaces failed instances and scales to meet demand.

• Redundant Connectivity

  • Use multiple NAT Gateways (one per AZ).
  • Use redundant VPN connections and multiple Direct Connect links.

• Route 53 with Health Checks and Failover Routing

  • Reroutes traffic away from unhealthy endpoints.

• CloudFront

  • Provides edge caching and DDoS resilience.

Best Practices:

• Avoid single points of failure.
• Distribute resources geographically.
• Automate recovery and scaling.
• Monitor continuously with CloudWatch.

External Connecting refers to the methods used to connect on-premises data centers, offices, or other networks to AWS, forming hybrid architectures.

Main Connectivity Options:

1. AWS Site-to-Site VPN

   • Creates an encrypted IPsec tunnel over the public internet between on-premises and a VPC.
   • Quick to set up, lower cost.
   • Subject to internet variability and latency.
   • Supports redundant tunnels for high availability.

2. AWS Direct Connect (DX)

   • A dedicated, private physical network connection between on-premises and AWS.
   • Provides consistent low latency, higher bandwidth, and reliability.
   • Does not traverse the public internet.
   • Can be combined with a VPN for encryption and redundancy.

3. AWS Transit Gateway

   • Acts as a central hub to interconnect multiple VPCs and on-premises networks.
   • Simplifies complex, large-scale network topologies.

4. AWS VPN CloudHub

   • Connects multiple remote sites using a hub-and-spoke model.

For Resilience: Combine Direct Connect + VPN backup, or use multiple Direct Connect connections across different locations to eliminate single points of failure.

Designing for Availability means architecting systems so they remain operational and accessible even when components fail. The Reliability Pillar of the AWS Well-Architected Framework guides this.

Core Principles of the Reliability Pillar:

• Automatically recover from failure

  • Monitor systems (CloudWatch) and trigger automated recovery (Auto Scaling, health checks).

• Test recovery procedures

  • Simulate failures to validate recovery (chaos engineering).

• Scale horizontally to increase aggregate availability

  • Replace one large resource with multiple smaller ones to reduce the impact of a single failure.

• Stop guessing capacity

  • Use Auto Scaling to match supply with demand automatically.

• Manage change through automation

  • Use Infrastructure as Code (CloudFormation).

Availability Design Tiers (based on required nines):

• Choose redundancy level based on target availability (e.g., Multi-AZ for 99.99%, Multi-Region for higher).

Key Strategies:

• Eliminate single points of failure through redundancy.
• Distribute across multiple AZs/Regions.
• Use loosely coupled, stateless components.
• Implement health checks and automatic failover (Route 53).
• Back up data and plan for disaster recovery (define RPO/RTO).

Higher availability generally requires more redundancy and higher cost, so design should balance business requirements against cost.

Domain Registration in Route 53 is the process of registering and managing domain names directly through AWS.

Domain Registration features:

• Register new domains across many Top-Level Domains (TLDs) like .com, .org, .io.
• Transfer existing domains to Route 53.
• Auto-renewal to prevent accidental expiration.
• Privacy protection to hide registrant contact info from WHOIS.
• Automatically creates a hosted zone for the registered domain.

DNS Management:

• Hosted Zone: A container for DNS records for a specific domain.
  • Public Hosted Zone: Routes internet traffic to resources.
  • Private Hosted Zone: Routes traffic within one or more VPCs.

Common DNS Record Types:

• A Record: Maps a domain to an IPv4 address.
• AAAA Record: Maps a domain to an IPv6 address.
• CNAME: Maps a domain to another domain name (alias).
• MX: Specifies mail servers.
• TXT: Holds text data (SPF, verification).
• NS: Lists the name servers for the zone.
• SOA: Start of Authority — contains administrative info.
• Alias Record (AWS-specific): Points to AWS resources (ELB, CloudFront, S3) without extra cost and can map to the zone apex.

Availability Monitoring in Route 53 is performed using Health Checks, which continuously monitor the health and performance of application endpoints.

Types of Health Checks:

1. Endpoint Health Checks

   • Monitor a specified endpoint (IP or domain) by sending requests over HTTP, HTTPS, or TCP.
   • Checks for a valid response within a timeout.

2. Calculated Health Checks

   • Combine the results of multiple other health checks using logical rules (e.g., healthy if at least 2 of 3 are healthy).

3. CloudWatch Alarm Health Checks

   • Base health status on the state of a CloudWatch alarm (e.g., high error rate or latency).

How Health Checks work:

• Route 53 health checkers located globally send requests at configured intervals.
• An endpoint is marked unhealthy after a configured number of consecutive failures.

Enabling Automatic Failover:

• When combined with Failover Routing Policy, Route 53 automatically:
  • Routes traffic to the primary resource while it is healthy.
  • Redirects traffic to a secondary/standby resource when the primary fails.
• Can also trigger notifications via Amazon SNS/CloudWatch.

This ensures users are always directed to healthy resources, improving overall availability.

We analyze availability using series and parallel formulas.

Given:

• Web tier availability:
• Database tier availability (single):

Before redundancy (both tiers in series):

Series availability is the product:

After adding a redundant database (two DBs in parallel):

Parallel availability of the database tier:

Now the web tier is in series with the parallel database tier:

Interpretation of improvement:

• Before: 99.85% availability → roughly 13.14 hours of downtime per year.
• After: ~99.95% availability → roughly 4.38 hours of downtime per year.

Explanation:

• Adding a parallel (redundant) database dramatically increased the database tier's availability from 99.9% to 99.9999%.
• The overall system availability is now limited mainly by the web tier, which is the weakest link.
• Key insight: To further improve availability, the web tier should also be made redundant, since in a series system the overall availability can never exceed that of the least available component.