Unit 5: Resiliency, Monitoring, and Automation

I. Foundations of Cloud Resiliency

Cloud resiliency is the ability of a workload to withstand infrastructure or service disruptions and recover while continuing to meet availability and performance requirements. AWS supports resiliency through observability, redundancy, elastic capacity, traffic distribution, controlled routing, and repeatable infrastructure automation.

• Resiliency: A resilient system anticipates failures and limits their impact through fault isolation, redundancy, automated recovery, and tested recovery procedures.
• High availability: Resources are distributed across independent Availability Zones so that the failure of one location does not stop the entire service.
• Fault tolerance: A fault-tolerant system continues operating despite component failure, often requiring redundant active resources and automatic failover.
• Elasticity: Capacity increases or decreases according to demand; this differs from scalability, which is the broader ability to handle growth.
• Observability: Metrics, logs, traces, events, dashboards, and alarms provide evidence about system health and behavior.
• Automation: Infrastructure and deployment processes are expressed as version-controlled definitions, reducing manual errors and configuration differences.
• Shared responsibility: AWS maintains resilience of the cloud, while customers design resilience in the cloud through architecture, configuration, monitoring, and recovery planning.
• Recovery objectives:
  • Recovery Time Objective (RTO): Maximum acceptable time for restoring a service.
  • Recovery Point Objective (RPO): Maximum acceptable amount of data loss measured in time.

II. Amazon CloudWatch — Resource Observability and Operational Response

A. Monitoring AWS resources with CloudWatch

Amazon CloudWatch collects operational data and turns it into metrics, logs, visualizations, alarms, and automated responses.

• Metrics: Time-ordered numerical measurements are organized by namespace, metric name, dimensions, and timestamp. Examples include EC2 CPUUtilization, Application Load Balancer RequestCount, and Lambda Errors.
  • Standard EC2 monitoring generally publishes at five-minute intervals.
  • Detailed EC2 monitoring provides one-minute intervals.
  • High-resolution custom metrics can use one-second storage resolution.
• Dimensions: Name-value pairs identify a metric resource, such as InstanceId=i-1234567890abcdef0; dimensions create distinct metric series.
• CloudWatch agent: The agent sends operating-system information not included in standard EC2 metrics, such as memory usage, disk usage, and selected log files.
• CloudWatch Logs: Log groups contain log streams, while retention settings determine how long events remain stored. Logs Insights runs queries across log data.
• Alarms: An alarm evaluates a metric or metric-math expression over specified periods and enters OK, ALARM, or INSUFFICIENT_DATA.
  • Actions can notify an Amazon SNS topic, invoke scaling behavior, or perform supported EC2 actions.
  • Composite alarms combine other alarms and reduce repetitive notifications.
• Dashboards: Regional or cross-account dashboards display graphs, alarm states, numbers, and log-query results in one operational view.
• Application monitoring: CloudWatch Application Signals, service-level objectives, and related tracing integrations help identify latency, errors, and dependencies.
• Event response: Amazon EventBridge can match AWS service events and route them to targets such as Lambda, SNS, or Systems Manager Automation.

B. Applications and Limitations

CloudWatch is most effective when monitoring is designed around user-visible service objectives rather than isolated resource statistics.

• Actionable monitoring: Alarm on symptoms such as error rate, request latency, and unavailable capacity, then use component metrics for diagnosis.
• Metric math: Derived values can represent rates or percentages; for example:

ErrorRate = 100 * Errors / Requests

• Errors is the number of failed requests.
• Requests is the total number of requests in the same period.
• ErrorRate is the percentage of failed requests.
  • Limitations: Costs depend on features and data volume, while poorly selected thresholds can produce alarm fatigue. CloudWatch does not automatically correct an application-level design flaw.

III. EC2 Auto Scaling — Elastic Compute Capacity

A. Scaling compute resources using Auto Scaling

Amazon EC2 Auto Scaling maintains a collection of instances in an Auto Scaling group and adjusts its size within defined capacity boundaries.

• Group capacity: minimum, desired, and maximum capacity define the permitted range. If desired capacity is 4, the group attempts to maintain four healthy instances.
• Launch template: Specifies instance configuration such as AMI, instance type, security groups, storage, IAM role, and user data.
• Availability: Instances can span multiple Availability Zones; unhealthy instances are replaced automatically according to configured health checks.
• Target tracking: Capacity changes to keep a metric near a target, such as average CPU utilization of 50%.
• Step scaling: Different capacity adjustments occur according to alarm severity; CPU above 70% might add two instances, while CPU above 90% adds four.
• Scheduled scaling: Capacity changes at known times, such as increasing desired capacity before a daily traffic peak.
• Predictive scaling: Historical patterns are analyzed to forecast demand and schedule capacity proactively.
• Instance warmup: Scaling policies can exclude newly launched instances from aggregated metrics until they are ready to serve normal traffic.
• Termination policy: When scaling in, the group selects instances for termination while considering Availability Zone balance and launch-template versions.

B. Design Considerations and Limitations

Effective scaling requires a demand metric that changes predictably with workload pressure.

• Horizontal scaling: Adding instances improves availability and elasticity when application nodes are stateless or store shared state externally.
• Scaling delay: Boot time, application initialization, health checks, and connection draining mean that capacity is not immediately usable.
• Data protection: Scale-in can terminate instances; persistent business data should therefore use services such as Amazon RDS, DynamoDB, EFS, or S3.
• Capacity risk: Maximum capacity, service quotas, unavailable instance types, or insufficient subnet addresses can prevent required expansion.

IV. Elastic Load Balancing — Highly Available Traffic Distribution

A. Using load balancers for high availability

Elastic Load Balancing distributes incoming connections across healthy targets and multiple Availability Zones, removing failed targets from normal routing.

• Application Load Balancer (ALB): Operates at Layer 7 for HTTP and HTTPS, supporting host-based, path-based, header, query-string, and method routing.
• Network Load Balancer (NLB): Operates at Layer 4 for TCP, UDP, and TLS workloads requiring high performance, low latency, or static IP-related capabilities.
• Gateway Load Balancer (GWLB): Distributes traffic through virtual network appliances such as firewalls and intrusion-prevention systems.
• Listeners: A listener checks connection requests on a protocol and port, such as HTTPS on port 443.
• Target groups: Requests are sent to registered targets such as EC2 instances, IP addresses, or supported Lambda functions.
• Health checks: The load balancer periodically tests targets and routes normal traffic only to those considered healthy.
• TLS termination: Certificates from AWS Certificate Manager can be associated with secure listeners, centralizing certificate handling.
• Multi-AZ operation: Enabling appropriate subnets allows load-balancer nodes and targets to operate across Availability Zones.

B. Availability Design and Limitations

A load balancer improves availability only when healthy application capacity exists in more than one failure domain.

• Redundant targets: Each enabled Availability Zone should contain sufficient capacity to absorb an instance or zone-level disruption.
• Connection draining: Deregistration delay lets in-flight requests finish before a target is removed during deployment or scale-in.
• Session state: Sticky sessions can bind users to targets, but external session stores generally allow more reliable scaling and failover.
• Scope: A regional load balancer does not independently provide cross-Region failover; Route 53 or a global traffic service is needed.

V. Amazon Route 53 — DNS Routing and Endpoint Failover

A. DNS-based routing with Amazon Route 53

Amazon Route 53 is an authoritative Domain Name System service that maps domain names to endpoints and applies routing policies to DNS responses.

• Hosted zones: Public hosted zones answer internet DNS queries, while private hosted zones resolve names within associated VPCs.
• Record types: Common records include A, AAAA, CNAME, MX, and TXT.
• Alias records: AWS-specific alias records can route zone-apex names to resources such as load balancers or CloudFront distributions without using a CNAME.
• Simple routing: Returns one or more values when no specialized routing behavior is required.
• Weighted routing: Splits responses according to assigned weights, supporting gradual releases such as 90 units to version A and 10 to version B.
• Latency-based routing: Directs users toward the AWS Region expected to provide the lowest latency.
• Failover routing: Returns a primary endpoint when healthy and a secondary endpoint when the primary is unhealthy.
• Geolocation routing: Selects responses according to the geographic origin of the DNS query.
• Geoproximity routing: Routes according to resource and user locations, with optional bias to expand or contract a resource’s traffic area.
• Multi-value answer routing: Returns multiple healthy records and provides basic DNS-level distribution.

B. Health, Caching, and Limitations

Route 53 health checks enable DNS-level traffic decisions, but DNS caching prevents instantaneous and perfectly controlled failover.

• Health checks: Checks can monitor endpoints, calculated combinations of other checks, or CloudWatch alarm states.
• Time to live (TTL): A resolver can cache a response for the record’s TTL; a 60-second TTL permits quicker changes than 300 seconds but increases query frequency.
• Failover condition: Health evaluation must be associated correctly with records; otherwise Route 53 can continue returning an unavailable endpoint.
• DNS limitation: Existing connections are not moved after a DNS change, and clients or resolvers may retain records longer than expected.

VI. AWS CloudFormation — Declarative Infrastructure as Code

A. Infrastructure automation with AWS CloudFormation

AWS CloudFormation provisions AWS resources from declarative JSON or YAML templates and manages them collectively as stacks.

• Template sections: Common sections include Parameters, Mappings, Conditions, Resources, and Outputs; only Resources is required.
• Resources: Logical IDs describe desired resources and properties:

Resources:
  AppBucket:
    Type: AWS::S3::Bucket
    Properties:
      VersioningConfiguration:
        Status: Enabled

• Stacks: A stack is a managed collection of resources created, updated, or deleted as one unit.
• Dependencies: CloudFormation infers many dependencies from references; DependsOn declares an explicit creation or deletion order when necessary.
• Change sets: A change set previews proposed stack modifications before execution.
• Rollback: Failed stack operations generally trigger rollback toward the previous stable state, subject to configuration and resource behavior.
• Drift detection: Drift identifies supported resources whose actual configuration differs from the expected template configuration.
• StackSets: A StackSet deploys stacks across multiple AWS accounts and Regions with controlled permissions and concurrency.
• Outputs and exports: Stack outputs expose values, while cross-stack exports allow another stack to import shared information.

B. Benefits and Limitations

CloudFormation makes infrastructure repeatable and reviewable, but production templates still require testing and lifecycle planning.

• Consistency: The same template can create equivalent development, test, and production environments using different parameter values.
• Version control: Template history supports peer review, auditability, rollback planning, and integration with CI/CD pipelines.
• Update behavior: Some property changes cause interruption or resource replacement; change sets must therefore be inspected before execution.
• Resource lifecycle: Deletion policies and update-replace policies can retain critical databases, snapshots, or storage when stacks change.
• Security: Templates should avoid embedded secrets; references to Secrets Manager or Systems Manager Parameter Store are more appropriate.

VII. AWS Quick Starts and Amazon Q Developer — Accelerated Deployment Automation

A. Automating deployments with AWS Quick Starts and Amazon Q Developer

AWS Quick Starts and Amazon Q Developer accelerate automation in different ways: Quick Starts provide tested reference deployments, while Amazon Q Developer assists engineers in creating and maintaining deployment artifacts.

1. AWS Quick Starts:

   • Reference architectures: Quick Starts package architecture guidance, deployment instructions, and automation for established AWS or partner solutions.
   • CloudFormation foundation: Deployments commonly use modular CloudFormation templates to create networking, security, compute, and application resources.
   • Deployment choices: A Quick Start may create a new VPC or deploy into an existing compatible VPC.
   • Customization: Parameters control options such as CIDR ranges, Availability Zones, instance types, and application configuration.

2. Amazon Q Developer:

   • Development assistance: Q Developer can explain code, suggest implementations, generate tests, and help produce or troubleshoot infrastructure-as-code definitions.
   • AWS guidance: It can answer AWS development and architecture questions within supported interfaces such as IDEs and the AWS environment.
   • Workflow support: Generated CloudFormation, scripts, or pipeline configuration can be committed to version control and executed through existing deployment systems.
   • Human control: Q Developer assists with automation but does not replace approvals, security review, testing, or the deployment service that executes changes.

B. Governance and Limitations

Accelerated deployment remains reliable only when generated and reference artifacts are reviewed against current organizational requirements.

• Validation: Templates should be linted, scanned for security issues, tested in a non-production account, and inspected through change sets.
• Customization risk: Modifying a Quick Start can invalidate documented assumptions concerning networking, permissions, scaling, or upgrade behavior.
• Generated code: Amazon Q Developer output must be checked for correct resource types, IAM scope, Region support, costs, and destructive update behavior.
• Operational ownership: Teams remain responsible for patching, monitoring, backup, incident response, compliance, and lifecycle management after deployment.