Design scalable and loosely coupled architectures.

The Problem: Why Scalability and Loose Coupling Matter

Consider a monolithic web application running on a single server. When traffic doubles, that server runs out of CPU or memory and users get errors. When the payment module needs an update, you must redeploy the entire application. When the order-processing code crashes, it takes the storefront down with it. Scalability solves the capacity problem; loose coupling solves the blast-radius and deployment-dependency problems.

Scalability Fundamentals

Vertical scaling (scaling up) means replacing an instance with a larger one: more CPU, more RAM, more network bandwidth. In AWS, this means stopping an EC2 instance and changing its instance type. Vertical scaling is simple but has a hard ceiling (the largest available instance type) and causes downtime during the resize.

Horizontal scaling (scaling out) means adding more instances of the same size behind a load balancer. There is no theoretical ceiling, and individual instances can be added or removed without downtime. The SAA-C03 exam overwhelmingly favors horizontal scaling as the correct answer for scalable designs.

💡 Exam Trap: When a question mentions "scaling" without qualification, the expected answer almost always involves horizontal scaling (adding instances), not vertical scaling (bigger instances). Vertical scaling is the correct answer only when the workload cannot be distributed, such as a single-threaded legacy database.

Elastic Load Balancing (ELB)

A load balancer is a service that distributes incoming traffic across multiple targets (EC2 instances, containers, IP addresses, Lambda functions). AWS provides Elastic Load Balancing as a managed service, meaning AWS handles the underlying infrastructure, patching, and scaling of the load balancer itself.

ELB comes in multiple types:

Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS). It can route requests based on the URL path, HTTP headers, query strings, or the hostname. It supports WebSockets and HTTP/2. ALB is the correct choice for any web application or microservice that needs content-based routing.

Key ALB features for the exam:

• Path-based routing: /api/* goes to one target group, /images/* goes to another.
• Host-based routing: api.example.com routes differently from www.example.com.
• Target groups: A target group is a logical grouping of targets (instances, IPs, or Lambda functions) that the ALB sends traffic to. Health checks are configured per target group.
• Sticky sessions: ALB can use a generated cookie or an application cookie to send a user's requests to the same target. Duration-based cookies are managed by the ALB; application-based cookies are set by your code.
• Authentication integration: ALB can authenticate users through Amazon Cognito or any OpenID Connect (OIDC) identity provider before forwarding the request.

💡 Exam Trap: ALB does not support static IP addresses natively. If the question requires a static IP (for firewall allowlisting, for example), the answer is either NLB or placing an NLB in front of an ALB via an ALB-type target group.

Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP/TLS). It is designed for extreme performance and low latency. NLB can handle millions of requests per second. It provides a static IP address per Availability Zone and can also be assigned an Elastic IP.

Key NLB features:

• Preserves the source IP address of the client by default when targets are registered by instance ID.
• Supports long-lived TCP connections (useful for databases, IoT, gaming).
• Can terminate TLS at the load balancer.
• Supports AWS PrivateLink: you can expose a service behind an NLB as a VPC endpoint service, allowing other accounts to connect privately.

Gateway Load Balancer (GWLB) operates at Layer 3 (IP packets). It is used to deploy, scale, and manage third-party virtual network appliances such as firewalls, intrusion detection systems, and deep packet inspection tools. GWLB uses the GENEVE protocol on port 6081. If an exam question mentions inline network appliance inspection of all traffic, GWLB is the answer.

💡 Exam Trap: Classic Load Balancer (CLB) is a legacy service. The exam does not test CLB-specific features, but a question might mention it as a distractor. If you see "Classic Load Balancer" in an answer choice alongside ALB or NLB, the CLB option is almost always wrong.

Cross-zone load balancing: When enabled, each load balancer node distributes traffic across all registered targets in all enabled Availability Zones, not just the targets in its own AZ. ALB has cross-zone load balancing enabled by default (and it is always free). NLB and GWLB have it disabled by default, and enabling it may incur data transfer charges.

ELB Health Checks

Each target group performs health checks against its targets. If a target fails the health check threshold (a configurable number of consecutive failures), the load balancer stops sending traffic to it. The target remains registered but is marked as "unhealthy."

Health check parameters:

• Protocol: HTTP, HTTPS, TCP, or gRPC (ALB); TCP, HTTP, HTTPS (NLB).
• Path: For HTTP/HTTPS checks, the URL path the load balancer requests (e.g., /health).
• Interval: Time between checks (default 30 seconds for ALB, 30 seconds for NLB with HTTP/HTTPS, 10 seconds for NLB with TCP).
• Healthy/Unhealthy threshold: Number of consecutive successes/failures before changing the target's status.

💡 Exam Trap: An unhealthy target is not automatically terminated. The load balancer only stops routing traffic to it. Terminating unhealthy instances is the job of an Auto Scaling group, not the load balancer.

Connection Draining (Deregistration Delay)

When a target is being removed from a target group (due to a scale-in event or a failed health check in an Auto Scaling group), the load balancer stops sending new requests to it but allows in-flight requests to complete. This period is called deregistration delay (also known as connection draining). The default is 300 seconds. For short-lived requests, set it lower (e.g., 30 seconds) to speed up scale-in operations.

Auto Scaling

Amazon EC2 Auto Scaling automatically adjusts the number of EC2 instances in an Auto Scaling group (ASG) based on conditions you define. An ASG requires three settings:

1. Minimum size: The lowest number of instances the group will maintain.
2. Desired capacity: The number of instances the group tries to maintain.
3. Maximum size: The upper limit the group will not exceed.

Launch template (replaces the older launch configuration) defines the instance configuration: AMI ID, instance type, key pair, security groups, IAM instance profile, user data script, and block device mappings. Launch templates support versioning and can specify multiple instance types for mixed-instance groups.

💡 Exam Trap: Launch configurations are immutable and cannot be edited after creation. Launch templates support versioning and are the recommended approach. If the exam presents both, choose the launch template answer.

Scaling Policies

Target tracking scaling: You specify a target value for a metric, and ASG creates and manages CloudWatch alarms to keep the metric near that target. Example: "Keep average CPU utilization at 50%." This is the simplest and most common policy type.

Step scaling: You define multiple CloudWatch alarms with thresholds, and each alarm triggers a specific adjustment. Example: add 1 instance when CPU > 60%, add 3 instances when CPU > 80%. Step scaling does not wait for new instances to become healthy before evaluating the next step.

Simple scaling: Similar to step scaling but processes only one adjustment at a time and waits for a cooldown period before responding to additional alarms. Simple scaling is older and less flexible than step scaling.

Scheduled scaling: You define a time-based schedule to change the minimum, maximum, or desired capacity. Example: increase minimum to 10 instances every weekday at 8:00 AM.

Predictive scaling: Uses machine learning to forecast traffic and pre-provisions capacity. It analyzes historical patterns and creates scheduled actions automatically. Predictive scaling is most effective when the workload has recurring patterns.

Scaling Cooldown

After a scaling activity completes, the ASG enters a cooldown period (default 300 seconds) during which it ignores further scaling alarms. This prevents rapid oscillation (thrashing). Target tracking policies manage their own cooldowns automatically. If the exam describes a scenario where instances are being added and removed repeatedly, the fix is often to increase the cooldown period.

Instance Warm-Up

During a scale-out event, new instances need time to bootstrap (install software, pull configuration, warm caches). The instance warm-up setting tells ASG how long to wait before including a new instance's metrics in the aggregate. Without this, a cold instance with 95% CPU could trigger another unnecessary scale-out.

ASG and ELB Integration

An Auto Scaling group can be associated with one or more target groups. When ASG launches a new instance, it automatically registers the instance with the target groups. When ASG terminates an instance, it deregisters it (and the deregistration delay applies). You can configure the ASG health check type to use the ELB health check in addition to the default EC2 status check, so that instances failing the load balancer health check are automatically replaced.

💡 Exam Trap: By default, ASG uses EC2 health checks only. If you want ASG to replace instances that fail the ALB/NLB health check, you must explicitly set the health check type to "ELB" on the Auto Scaling group.

Termination Policies

When scaling in, ASG needs to decide which instance to terminate. The default policy first identifies the AZ with the most instances (to rebalance across AZs), then selects the instance with the oldest launch template or configuration, then selects the instance closest to the next billing hour.

Lifecycle Hooks

Lifecycle hooks let you perform custom actions when an instance is launching or terminating. When a hook is triggered, the instance enters a "Pending:Wait" (launch) or "Terminating:Wait" state. Your code can run setup scripts, drain connections, push logs to S3, or notify external systems. The default wait period is 3600 seconds (1 hour), with a maximum of 172800 seconds (48 hours).

Loose Coupling with Messaging Services

Loose coupling means that components interact through well-defined interfaces rather than direct point-to-point connections. If Component A calls Component B directly (synchronous, tightly coupled), then B's failure causes A to fail. Introducing a queue or event bus between them decouples their availability, scaling, and deployment.

Amazon Simple Queue Service (SQS)

SQS is a fully managed message queuing service. A producer sends a message to a queue; a consumer polls the queue and processes the message.

Standard queues provide at-least-once delivery with best-effort ordering. They support a nearly unlimited number of transactions per second. Messages might be delivered more than once or out of order.

FIFO queues guarantee exactly-once processing and strict ordering. FIFO queues support up to 3,000 messages per second with batching (300 without batching) per API action. FIFO queue names must end with the .fifo suffix.

💡 Exam Trap: If the exam says "messages must be processed exactly once and in order," the answer is SQS FIFO. If it says "highest possible throughput" without ordering requirements, the answer is SQS Standard.

Key SQS settings:

• Visibility timeout: After a consumer receives a message, the message becomes invisible to other consumers for this duration (default 30 seconds, maximum 12 hours). If the consumer finishes processing, it deletes the message. If it does not delete the message before the timeout expires, the message becomes visible again and another consumer can process it. This is how SQS handles consumer failures.
• Message retention period: How long SQS keeps unprocessed messages (default 4 days, minimum 60 seconds, maximum 14 days).
• Maximum message size: 256 KB. For larger payloads, use the SQS Extended Client Library, which stores the body in S3 and sends a pointer through the queue.
• Delay queue: Postpones delivery of new messages to the queue for a specified time (0 seconds to 15 minutes).
• Dead-letter queue (DLQ): A separate queue where messages are sent after failing to be processed a configurable number of times (the maxReceiveCount on the redrive policy). DLQs are essential for debugging and preventing poison messages from blocking the queue.
• Long polling: By setting the WaitTimeSeconds parameter (1-20 seconds), the consumer waits for messages to arrive rather than returning immediately. Long polling reduces the number of empty responses (and therefore cost) compared to short polling.

# Create a standard queue
aws sqs create-queue --queue-name orders-queue

# Create a FIFO queue
aws sqs create-queue --queue-name orders-queue.fifo \
 --attributes FifoQueue=true,ContentBasedDeduplication=true

# Send a message
aws sqs send-message --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/orders-queue \
 --message-body '{"orderId":"12345","item":"widget"}'

# Receive messages with long polling
aws sqs receive-message --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/orders-queue \
 --wait-time-seconds 20 --max-number-of-messages 10

Amazon Simple Notification Service (SNS)

SNS is a fully managed pub/sub messaging service. A publisher sends a message to an SNS topic, and the topic fans out that message to all subscribers. Subscribers can be SQS queues, Lambda functions, HTTP/HTTPS endpoints, email addresses, SMS, or mobile push notifications.

Standard topics provide best-effort ordering and at-least-once delivery. FIFO topics provide strict ordering and exactly-once delivery, and can only have SQS FIFO queues as subscribers.

SNS supports message filtering. Each subscriber can attach a filter policy (a JSON document) that specifies which message attributes it cares about. SNS evaluates the filter and delivers only matching messages to that subscriber. Without filter policies, every subscriber receives every message.

{
 "eventType": ["order_placed"],
 "region": ["us-east-1", "eu-west-1"]
}

With this filter policy, the subscriber receives only messages where the eventType attribute equals order_placed AND the region attribute is either us-east-1 or eu-west-1.

💡 Exam Trap: SNS is push-based (messages are pushed to subscribers). SQS is pull-based (consumers poll for messages). A common pattern tested on the exam is "fan-out": one SNS topic fans out to multiple SQS queues, each processed by a different consumer group.

Fan-Out Pattern: SNS + SQS

The fan-out architecture is one of the most frequently tested patterns. A single event (e.g., an image upload to S3) triggers a message to an SNS topic. That topic has multiple SQS queues subscribed to it. Each queue is consumed by a different service: one generates thumbnails, another runs image recognition, a third updates a database.

S3 Event Processing Flow

This pattern provides full decoupling: each consumer scales independently, failures in one pipeline do not affect the others, and you can add new subscribers without modifying the publisher.

Amazon EventBridge

EventBridge (formerly CloudWatch Events) is a serverless event bus. While SNS delivers messages you explicitly publish, EventBridge also ingests events automatically from AWS services (e.g., an EC2 instance state change, an S3 object created event, a CodePipeline stage transition).

Key EventBridge concepts:

• Event bus: A router that receives events and evaluates them against rules. The default event bus receives events from AWS services. You can create custom event buses for your own applications.
• Rules: Each rule matches incoming events using an event pattern (a JSON-based filter on the event structure) and routes matches to one or more targets.
• Targets: Over 20 AWS services can be targets, including Lambda, SQS, SNS, Step Functions, Kinesis Data Streams, API Gateway, and more.
• Schema registry: EventBridge can discover and store the schema (structure) of events flowing through the bus, and generate code bindings for your applications.

EventBridge is preferred over CloudWatch Events for new designs. It supports third-party SaaS integrations (Zendesk, Datadog, Auth0, etc.), archive and replay of events, and cross-account/cross-region event routing.

💡 Exam Trap: If the exam question involves reacting to AWS service events (e.g., "when an EC2 instance terminates, send a notification"), EventBridge (or its earlier name, CloudWatch Events) is the correct answer, not SNS. SNS requires a publisher to explicitly send a message.

AWS Step Functions

Step Functions is a serverless orchestration service that lets you coordinate multiple AWS services into workflows using a visual state machine. Each step in the workflow can invoke a Lambda function, run an ECS task, send a message to SQS, wait for a callback, or perform many other actions.

Step Functions is relevant to loose coupling because it replaces embedded orchestration logic in application code with a declarative, managed workflow. If a step fails, Step Functions can retry it, catch the error and branch to an error-handling state, or wait for a human approval.

Standard Workflows can run for up to one year, are priced per state transition, and guarantee exactly-once execution. Express Workflows can run for up to five minutes, are priced per execution/duration, and support at-least-once execution at high throughput.

💡 Exam Trap: If the question describes a long-running process with multiple steps and error handling (e.g., "coordinate an order workflow across payment, inventory, and shipping services"), Step Functions is the answer, not a Lambda function with a loop.

Loose Coupling with Managed Services

Beyond messaging, using managed (serverless) services is itself a form of loose coupling because it removes the need to provision, patch, and scale infrastructure.

AWS Lambda is a serverless compute service that runs code in response to events. You upload your code, and AWS manages the servers. Lambda functions scale automatically to handle the number of incoming events. Lambda's concurrency model is one execution environment per concurrent invocation, and the default account-level concurrency limit is 1,000 concurrent executions per Region (can be increased).

Key Lambda limits for the exam:

• Memory: 128 MB to 10,240 MB (10 GB) in 1-MB increments. CPU scales proportionally with memory.
• Timeout: Maximum 15 minutes.
• Deployment package: 50 MB zipped (uploaded directly), 250 MB unzipped. Container images up to 10 GB.
• Ephemeral storage (/tmp): 512 MB to 10,240 MB.
• /tmp vs Layers: Layers provide shared code/libraries (up to 5 layers per function, total unzipped size 250 MB). /tmp is scratch space available during a single invocation.

💡 Exam Trap: Lambda has a 15-minute maximum timeout. If a question describes a process that takes longer than 15 minutes, Lambda alone is not the answer. Consider AWS Batch, ECS/Fargate, or Step Functions with multiple Lambda invocations.

Amazon API Gateway provides a managed REST, HTTP, or WebSocket API front end. It handles throttling, caching, authorization, and request/response transformation. API Gateway integrates with Lambda, HTTP backends, and other AWS services.

• REST API: Full-featured, supports API keys, usage plans, resource policies, request validation, WAF integration. Priced per API call and data transfer.
• HTTP API: Lower cost, lower latency, simpler feature set. Supports JWT authorizers and Lambda authorizers. Recommended for most new APIs unless REST API-specific features (resource policies, API keys, request validation) are needed.
• WebSocket API: For persistent, two-way communication (chat, real-time dashboards).

Choosing the Right Decoupling Mechanism

Amazon Kinesis

Kinesis Data Streams is a real-time data streaming service. Producers push data records into a stream, which consists of one or more shards. Each shard supports up to 1,000 records per second for writes (up to 1 MB/s) and 2 MB/s for reads. Consumers (Lambda, KCL applications, Kinesis Data Analytics) read records from the stream. Data is retained for 24 hours by default (configurable up to 365 days).

Kinesis is the answer when the exam describes real-time streaming, ordering within a partition key, or replay of recent data. SQS is the answer for decoupling individual tasks.

Kinesis Data Firehose is a fully managed delivery service that captures, transforms, and loads streaming data into destinations such as S3, Redshift, OpenSearch, and Splunk. Firehose handles batching, compression, and encryption. Unlike Data Streams, Firehose is near-real-time (minimum buffer interval of 60 seconds).

💡 Exam Trap: Kinesis Data Streams supports replay (consumers can re-read records within the retention period). SQS does not (once deleted, the message is gone). If the question mentions "replay" or "re-process," choose Kinesis Data Streams.

Microservices and Container Orchestration

Decomposing a monolith into microservices is a structural form of loose coupling. Each microservice is a small, independently deployable unit that communicates with others through APIs or messaging.

Amazon Elastic Container Service (ECS) is a container orchestration service. You define tasks (one or more containers), and ECS places them on a cluster. ECS supports two launch types:

• EC2 launch type: You manage the EC2 instances in the cluster. You control instance types, AMIs, and scaling.
• Fargate launch type: AWS manages the underlying infrastructure. You specify CPU and memory per task, and Fargate runs it. No EC2 instances to manage.

Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service. If the exam says "Kubernetes" or "k8s," the answer is EKS. EKS also supports Fargate for serverless pod execution.

💡 Exam Trap: ECS with Fargate is the simplest serverless container option on AWS. EKS with Fargate provides the same serverless infrastructure but for Kubernetes workloads. If the question does not mention Kubernetes, prefer ECS with Fargate for simplicity.

Caching for Scalability

Caching reduces load on backend systems by serving frequently requested data from a fast in-memory store.

Amazon ElastiCache provides managed in-memory caching with two engines:

• Redis: Supports complex data structures (sorted sets, lists, hashes), persistence, replication, Multi-AZ with automatic failover, and backup/restore. Supports encryption at rest and in transit.
• Memcached: Simpler, multi-threaded, supports auto-discovery of nodes. No persistence, no replication, no Multi-AZ failover.

If the exam asks for caching with persistence, replication, or complex data types, the answer is ElastiCache for Redis. If it asks for the simplest possible cache with multiple threads and no persistence requirement, the answer is Memcached.

Amazon CloudFront is a global content delivery network (CDN). It caches content at edge locations worldwide, reducing latency for end users. CloudFront can serve static content from S3, dynamic content from ALB or API Gateway, and can run Lambda@Edge or CloudFront Functions for request/response manipulation at the edge.

DynamoDB Accelerator (DAX) is a fully managed, in-memory cache for DynamoDB. It sits in front of a DynamoDB table and serves reads with microsecond latency. DAX is API-compatible with DynamoDB, so applications require minimal code changes.

💡 Exam Trap: DAX is specifically for DynamoDB. ElastiCache is for general-purpose caching (session stores, database query results, API response caching). If the question says "cache DynamoDB reads," DAX is the answer, not ElastiCache.

Database Scalability

Amazon DynamoDB is a serverless, key-value and document NoSQL database. It scales horizontally by partitioning data across servers. Two capacity modes:

• On-demand: Pay per request. Scales automatically. Best for unpredictable workloads.
• Provisioned: You specify read capacity units (RCU) and write capacity units (WCU). Auto scaling can adjust provisioned capacity based on utilization. Best for predictable workloads where you want cost control.

One RCU provides one strongly consistent read per second (or two eventually consistent reads) for items up to 4 KB. One WCU provides one write per second for items up to 1 KB.

DynamoDB Global Tables provide multi-Region, active-active replication. Writes in any Region are propagated to all other Regions. This provides both scalability and disaster recovery across Regions.

Amazon Aurora is a MySQL- and PostgreSQL-compatible relational database with up to five times the throughput of standard MySQL and three times the throughput of standard PostgreSQL. Aurora stores data in a cluster volume that automatically replicates six copies across three Availability Zones. Aurora supports up to 15 read replicas with sub-10ms replica lag.

Aurora Serverless automatically starts, stops, and scales capacity based on demand. Aurora Serverless v2 scales in fine-grained increments (0.5 ACU increments, where 1 ACU is approximately 2 GB of memory) and does not require stopping the database during scaling.

Amazon RDS Read Replicas allow you to create read-only copies of your RDS database (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server). Read replicas use asynchronous replication and can be created in the same AZ, a different AZ, or a different Region (cross-Region read replicas). Read replicas offload read traffic from the primary database.

💡 Exam Trap: Read replicas are for read scaling, not for high availability. Multi-AZ deployments are for high availability (automatic failover). You can have both: a Multi-AZ primary with read replicas.

Elastic Scaling for Other Compute Services

AWS Auto Scaling (the broader service, distinct from EC2 Auto Scaling) can create scaling plans for multiple resource types: EC2 Auto Scaling groups, ECS services, DynamoDB tables/indexes, Aurora replicas, and Spot Fleet requests. It uses target tracking to keep metrics at defined targets.

This section establishes the building blocks for scaling and decoupling. The next section applies these same services to the specific problems of high availability and fault tolerance.