What resilience and HA actually mean

High availability (HA) means minimising downtime; resilience means the system recovers automatically from failure. In the SAA-C03 exam these ideas run through nearly every domain, so learn the AWS-native patterns rather than generic theory.

Multi-AZ vs Multi-Region

An Availability Zone (AZ) is one or more discrete data centres with independent power, cooling and networking, connected by low-latency links. A Region has a minimum of 3 AZs (most have 3, some have more). Spreading resources across at least 2 AZs protects against a single data-centre failure; multi-Region protects against a full Region outage but adds latency and data-transfer cost, and needs a replication strategy (e.g. S3 Cross-Region Replication, DynamoDB Global Tables, Aurora Global Database).

Compute resilience

• Use an Auto Scaling Group (ASG) across multiple AZs with a minimum, desired and maximum capacity, plus health checks (EC2 or ELB) so unhealthy instances are replaced automatically.
• Put an Elastic Load Balancer (ALB/NLB) in front — it distributes traffic and stops routing to failed targets.
• For stateless resilience, never store session state on the instance; use ElastiCache, DynamoDB or sticky sessions only as a last resort.

Database resilience

• RDS Multi-AZ gives a synchronous standby in a second AZ with automatic failover (typically 60-120 seconds) — this is for availability, not read scaling.
• RDS Read Replicas (up to 15 for Aurora, 5 for most other engines) give read scaling and can be promoted manually to standalone if the primary fails — that is disaster recovery, not automatic HA.
• Aurora Global Database replicates across Regions with typically under 1 second lag and enables fast Regional disaster recovery.
• DynamoDB is multi-AZ by default within a Region at no extra design effort; Global Tables extend this multi-Region with active-active writes.

Storage and DNS

• S3 is designed for 99.999999999% (11 nines) durability and stores data redundantly across at least 3 AZs by default.
• Route 53 supports failover, weighted, latency and multi-value routing policies with health checks — failover routing is the classic HA/DR exam answer.
• CloudFront plus S3 or multiple origins improves both performance and resilience by serving from edge locations.

Disaster Recovery (DR) strategies — know all four

1. Backup and Restore — cheapest, slowest (hours), highest RPO/RTO.

2. Pilot Light — minimal core infrastructure running, scale up on failover.

3. Warm Standby — a scaled-down but fully functional copy always running.

4. Multi-Site Active-Active — full production capacity in two+ Regions, lowest RPO/RTO, highest cost.

Common exam traps

• RDS Multi-AZ is NOT for read scaling — that's Read Replicas.
• Read Replica promotion is manual and is a DR action, not automatic failover.
• 'Highly available' answers usually mean 'span AZs'; 'disaster recovery' answers usually mean 'span Regions'.
• Loose coupling (SQS, SNS, EventBridge) between components improves resilience by preventing one failure cascading.

IAM basics

IAM is global, not regional. It controls who (authentication) can do what (authorisation) on AWS resources.

• Root user should never be used day-to-day — lock it down with MFA and avoid its access keys.
• Users, groups and roles are IAM identities. Groups cannot be nested and cannot be logged into.
• Roles are the secure way to grant temporary access — used by EC2 instances, Lambda, cross-account access, and federated users (via STS, Security Token Service).
• Policies are JSON documents attached to identities or resources. Evaluation logic: explicit Deny always wins, then explicit Allow, then implicit Deny (default with no Allow).
• Use the principle of least privilege — grant only the permissions needed.
• IAM Policy Simulator and Access Analyzer help test and audit permissions before deploying.

Policy types

• Identity-based policies attach to users/groups/roles.
• Resource-based policies attach to resources (e.g. S3 bucket policies, KMS key policies) and can grant cross-account access without a role.
• Permissions boundaries set the maximum permissions an identity can ever have — a guardrail, not a grant.
• Service Control Policies (SCPs) live in AWS Organizations and cap permissions across whole accounts — even the root user in a member account cannot exceed an SCP.

Common exam mistake

Don't confuse permissions boundaries (per-identity ceiling) with SCPs (per-account/OU ceiling) — both are 'maximum' controls, neither grants access on its own; you still need an Allow.

KMS (Key Management Service)

KMS manages encryption keys for data at rest across AWS services (S3, EBS, RDS, etc).

• Customer Master Keys (CMKs), now called KMS keys, never leave the KMS service unencrypted.
• AWS-managed keys (aws/service-name) are free and rotate automatically every year; you cannot control their policy.
• Customer-managed keys give full control over the key policy and rotation, and can be rotated automatically every year or on demand.
• Envelope encryption is how KMS handles large data: a data key encrypts the actual data, and the KMS key encrypts the data key.
• Symmetric KMS keys are used for most encrypt/decrypt use cases; asymmetric keys support signing or encryption where the public key must be shared.
• KMS API calls (Encrypt, Decrypt, GenerateDataKey) are logged to CloudTrail, giving an audit trail of key use.
• Key policies are the primary access-control mechanism for KMS keys — even with an IAM Allow, the key policy must also permit the action (or delegate to IAM via 'enable IAM policies').

Common exam mistake

Remember KMS keys are regional, unlike IAM. A key created in eu-west-2 cannot be used to decrypt data in us-east-1 directly — you'd need cross-region key replication (multi-Region keys) or re-encryption.

EC2 instance types and purchasing

EC2 gives you full control over the OS. Choose instance families by workload: T (burstable, general-purpose, cheap), M (balanced), C (compute-optimised, high CPU), R (memory-optimised), I/D (storage-optimised). Purchasing options matter for cost questions: On-Demand for unpredictable short-term work, Reserved/Savings Plans (1 or 3 year, up to ~72% off) for steady-state predictable workloads, Spot Instances (up to 90% off) for fault-tolerant flexible workloads that can handle interruption with a 2-minute warning, and Dedicated Hosts for licensing/compliance needs where you must control the physical server.

Auto Scaling and Elastic Load Balancing

Auto Scaling Groups (ASGs) keep the right number of EC2 instances running using a launch template, min/max/desired capacity, and scaling policies (target tracking is the recommended default, e.g. keep average CPU at 50%). ASGs work across multiple Availability Zones for resilience. Elastic Load Balancers spread traffic: Application Load Balancer (ALB) works at Layer 7 for HTTP/HTTPS and supports path/host-based routing, Network Load Balancer (NLB) works at Layer 4 for extreme performance and static IPs, Gateway Load Balancer is for third-party virtual appliances.

Lambda essentials

Lambda is serverless compute, billed per millisecond of execution and memory used, with no servers to patch. Key numbers to memorise: default timeout is 3 seconds, maximum timeout is 15 minutes, memory is configurable from 128 MB to 10,240 MB, and CPU scales automatically with memory. Deployment package size limits: 50 MB zipped direct upload, 250 MB unzipped including layers, or up to 10 GB using container images. Concurrency: default account concurrent execution limit is 1,000 (soft limit, raisable), and Provisioned Concurrency removes cold starts for latency-sensitive apps. Lambda is ideal for short, event-driven, stateless tasks triggered by S3, API Gateway, DynamoDB Streams, EventBridge, or SQS.

ECS and container choices

ECS (Elastic Container Service) runs Docker containers using Task Definitions (the blueprint: image, CPU, memory, ports) and Services (which keep a desired number of tasks running, often behind an ALB). Two launch types: EC2 launch type means you manage the underlying EC2 instances yourself (more control, more admin); Fargate is serverless — AWS manages the infrastructure, you just define CPU/memory per task. EKS is AWS's managed Kubernetes alternative for teams already standardised on Kubernetes tooling.

Common exam traps

• Don't pick Lambda for anything needing more than 15 minutes runtime or heavy persistent state — use ECS/EC2 instead.
• Spot Instances can be terminated with only 2 minutes' notice — never use for stateful, non-interruptible jobs.
• Fargate removes server management entirely; EC2 launch type is chosen only when you need OS-level control or GPU/specialised instances.
• Target tracking scaling policies are simpler and usually the better answer than step scaling unless the question specifies complex thresholds.

S3 storage classes

S3 is object storage, unlimited scale, 11 nines durability across all classes.

• Standard: frequent access, millisecond retrieval, spread across 3+ AZs.
• Intelligent-Tiering: automatically moves objects between tiers based on access patterns, no retrieval fee, small monitoring fee per object.
• Standard-IA and One Zone-IA: infrequent access, lower storage cost but a per-GB retrieval fee; One Zone-IA lives in a single AZ so it is cheaper but not resilient to AZ loss.
• Glacier Instant Retrieval: archive with millisecond access, for data read once a quarter.
• Glacier Flexible Retrieval: minutes to hours retrieval, cheaper archive.
• Glacier Deep Archive: cheapest tier, 12 hour standard retrieval, for 7-10 year compliance retention.

Lifecycle rules

Lifecycle policies transition or expire objects automatically by age (days since creation), e.g. Standard to Standard-IA at 30 days, then Glacier at 90 days, then delete at 365 days. Objects must sit in Standard-IA or One Zone-IA a minimum of 30 days before transitioning further. Versioned buckets can expire noncurrent versions separately.

EBS volume types

EBS is block storage attached to one EC2 instance at a time (except io1/io2 Multi-Attach). Types: gp3 (general purpose SSD, baseline 3,000 IOPS and 125 MiB/s independent of size, cheapest default), gp2 (older, IOPS tied to volume size, 3 IOPS/GB), io1/io2 (provisioned IOPS, up to 64,000 IOPS, for latency-sensitive databases), st1 (throughput-optimised HDD, big sequential workloads like big data), sc1 (cold HDD, cheapest, infrequent access). EBS snapshots are incremental and stored in S3; snapshots can be copied cross-region for DR.

EFS

EFS is a fully managed NFS file system that many EC2 instances (and Lambda, across AZs) can mount concurrently. It is regional, scales automatically, and has Standard and Infrequent Access storage classes with lifecycle management to move files automatically after a set number of days of no access. Use EFS for shared Linux workloads like content management or web serving; EBS cannot be shared across instances the way EFS can.

Common exam traps

• Mixing up EBS (single instance, AZ-bound) with EFS (multi-instance, regional, NFS).
• Forgetting One Zone-IA has no AZ resilience — never use it for data you cannot recreate.
• Assuming Glacier retrieval is instant — only Instant Retrieval tier is millisecond; the others need minutes to hours (Flexible) or up to 12 hours (Deep Archive).
• Forgetting lifecycle transitions need the 30 day minimum before moving out of an IA tier.
• Choosing gp2 when the question wants predictable performance independent of size — that is gp3.

VPC basics

A VPC is your private network in AWS, split into subnets across Availability Zones.

Each subnet lives in exactly one AZ and gets a CIDR block carved from the VPC's CIDR.

AWS reserves 5 IP addresses in every subnet: network address, VPC router, DNS, future use, and broadcast address - so a /28 only gives you 11 usable IPs.

A subnet is 'public' only if it has a route to an Internet Gateway (IGW) in its route table AND instances have public IPs.

Private subnets route outbound traffic via a NAT Gateway (in a public subnet) - NAT Gateways are AZ-scoped, so put one per AZ for high availability.

Connecting VPCs and on-prem

VPC Peering links two VPCs 1:1 but is NOT transitive - A peered to B and B peered to C does not let A talk to C.

Transit Gateway solves that: a hub-and-spoke that connects many VPCs and on-prem networks, and does support transitive routing.

Site-to-Site VPN goes over the public internet (encrypted); Direct Connect is a dedicated private line - faster, more consistent, but takes weeks to provision.

VPC Endpoints let you reach AWS services privately without going over the internet: Gateway endpoints are free and cover only S3 and DynamoDB; Interface endpoints (powered by PrivateLink) cost money and cover most other services.

Security layers - the classic exam trap

Security Groups are stateful (return traffic auto-allowed) and only support ALLOW rules - they act at the instance/ENI level.

NACLs are stateless (you must allow both inbound and outbound explicitly) and act at the subnet level, supporting both ALLOW and DENY rules - useful for blocking a specific malicious IP.

NACL rules are evaluated in order by rule number, lowest first, and the first match wins.

Route 53

Supports routing policies: Simple, Weighted (percentage split), Latency-based, Failover, Geolocation, Geoproximity, and Multivalue answer.

Health checks combined with Failover routing give automatic DR failover to a standby endpoint.

Alias records are Route 53's free, AWS-only extension of CNAME - they can point at the zone apex (naked domain) and target ELBs, CloudFront, or S3 website endpoints for free.

CloudFront

CloudFront is AWS's CDN: caches content at edge locations close to users, cutting latency and load on the origin.

Origins can be S3 (use Origin Access Control, OAC, to keep the bucket private and force traffic through CloudFront only), an ALB, or any custom HTTP origin.

Signed URLs/Cookies restrict access to private content; Field-Level Encryption adds extra protection for sensitive fields like card numbers, encrypted end-to-end.

Use Cache Behaviors to route different path patterns to different origins or TTL settings within one distribution.

Common mistakes

Confusing NACL (stateless, subnet) with Security Group (stateful, instance).

Forgetting NAT Gateways are per-AZ, not automatically HA across AZs.

Assuming VPC Peering is transitive - it is not, use Transit Gateway.

Using Gateway endpoints when the service isn't S3 or DynamoDB - need Interface endpoints instead.

Why cost and performance sit together

SAA-C03 loves questions where the 'right' answer is the cheapest one that still meets the performance and durability requirement. Always match the workload pattern to the pricing model and storage/compute tier - overpaying for unused headroom is treated as a wrong answer, same as underprovisioning.

Compute purchasing options

• On-Demand: pay per second/hour, no commitment, use for short-term or unpredictable spiky workloads.
• Reserved Instances / Savings Plans: up to 72% off for steady-state, predictable workloads with a 1 or 3 year term.
• Spot Instances: up to 90% off, for fault-tolerant, flexible, interruptible workloads (batch, CI, stateless web tiers) - never for workloads that cannot handle a 2-minute interruption warning.
• Compute Savings Plans are more flexible than EC2 Instance Savings Plans (cover Fargate/Lambda too), but EC2 Instance Savings Plans give the bigger discount if you know the instance family.

Auto Scaling and right-sizing

• Use Auto Scaling Groups with target tracking to match capacity to demand instead of running fixed oversized fleets.
• Use AWS Compute Optimizer and Cost Explorer to spot over-provisioned resources.
• Use Trusted Advisor (cost optimisation checks need Business/Enterprise support) to flag idle load balancers, low-utilisation EC2, unattached EBS volumes.

Storage cost tiers

• S3 Standard for frequently accessed data; S3 Standard-IA and One Zone-IA for infrequent access (IA = minimum 30-day storage, retrieval fee applies).
• S3 Intelligent-Tiering automatically moves objects between tiers based on access patterns with no performance impact or retrieval fee - the exam's go-to answer when access patterns are unknown or unpredictable.
• S3 Glacier Instant Retrieval, Flexible Retrieval, and Deep Archive for archival - Deep Archive is cheapest but retrieval takes up to 12 hours (or 48 with bulk).
• Use S3 Lifecycle policies to automate transitions and expirations.

High-performing design levers

• CloudFront caches content at edge locations - reduces latency and origin load, and cuts data transfer costs.
• ElastiCache (Redis/Memcached) offloads read-heavy database traffic and slashes response times.
• Read Replicas (RDS/Aurora) scale read throughput horizontally without touching the primary's write capacity.
• Multi-AZ is for availability/failover, NOT read scaling - a very common exam trap; use Read Replicas for that instead.
• Placement groups: cluster (low latency, same AZ), spread (max 7 instances per AZ, isolate critical instances), partition (large distributed workloads like Hadoop/Cassandra).

Common mistakes to avoid

• Choosing Reserved/Savings Plans for spiky or short-lived workloads (wrong - use On-Demand or Spot).
• Picking Multi-AZ RDS when the requirement is read scalability (wrong - pick Read Replicas).
• Forgetting that NAT Gateways and cross-AZ/cross-region data transfer both carry ongoing cost - consolidate AZs or use VPC endpoints to cut this.
• Ignoring S3 Transfer Acceleration and CloudFront for global latency-sensitive delivery.