Scalable, loosely coupled architectures

Components that talk through queues, topics, events, and APIs can scale, fail, and change independently. Keep tiers stateless so they scale out, and pick the managed or serverless service built for each job.

Scaling out, scaling up, and staying stateless

• Vertical scaling: A bigger instance. Simple, but it has a ceiling and usually needs a restart.
• Horizontal scaling: More instances behind a load balancer. No hard ceiling, and losing one instance isn't an outage.
• Horizontal scaling needs stateless servers: keep session data in ElastiCache or DynamoDB, and files in S3 or EFS, not on the instance.
• Microservices split an application into small services that own their data and talk over APIs or events, so each can be deployed and scaled on its own.

Queues, topics, and events

• Amazon SQS: A managed queue that buffers work between producers and consumers. Standard queues: at-least-once delivery and best-effort ordering. FIFO queues: strict ordering and exactly-once processing.
• SQS features to know: Visibility timeout hides a message while a consumer works on it; a dead-letter queue catches messages that keep failing; long polling cuts empty receives and cost.
• Amazon SNS: Publish/subscribe: one message is pushed to many subscribers (SQS queues, Lambda, HTTP endpoints, email, SMS). SNS-to-SQS fan-out gives each consumer its own durable queue.
• Amazon EventBridge: An event bus that routes events from AWS services, your apps, and SaaS partners to targets using rules that match on event content. EventBridge Scheduler runs scheduled tasks.
• Amazon MQ: Managed Apache ActiveMQ or RabbitMQ for existing applications that use standard protocols such as JMS, AMQP, or MQTT. Choose it to migrate without rewriting messaging code.
• Amazon AppFlow: Moves data between SaaS applications and AWS services without custom integration code.

Serverless building blocks

• AWS Lambda: Runs code in response to events and scales with the number of requests. You pay for requests and duration; one invocation can run up to 15 minutes.
• Amazon API Gateway: Managed front door for REST, HTTP, and WebSocket APIs: authorization (IAM, Cognito, Lambda authorizers), throttling, usage plans with API keys, and response caching for REST APIs.
• AWS Step Functions: Orchestrates multi-step workflows as a state machine with retries, error handling, parallel branches, and waits for human approval. Standard workflows for long-running jobs; Express for high-volume, short ones.
• AWS Fargate: Runs containers for ECS or EKS without managing servers. Choose it when you want containers but not EC2 capacity planning.
• Event-driven pattern: an S3 upload or a DynamoDB stream triggers Lambda, which writes results and publishes an event for the next step. No component waits on another.

Containers

• When containers fit: Long-running services, workloads that need a specific runtime or OS packages, or apps you want to move as-is with consistent packaging.
• Amazon ECS: AWS's own container orchestrator. Simple and tightly integrated with AWS.
• Amazon EKS: Managed Kubernetes. Choose it when the team already uses Kubernetes tools or needs portability.
• Amazon ECR: A private container image registry that ECS, EKS, and Lambda pull from.
• Migrating an app into containers: package it as an image, push it to ECR, define a task or pod, then run it on Fargate or EC2 behind a load balancer. ECS Anywhere and EKS Anywhere run the same tooling on premises.

Load balancing, caching, and multi-tier designs

• Application Load Balancer (ALB): Layer 7 (HTTP/HTTPS). Routes by path, host, header, or query string to instances, IP addresses, containers, or Lambda functions.
• Network Load Balancer (NLB): Layer 4 (TCP, UDP, TLS). Very high throughput and low latency, with a static IP address per AZ.
• Gateway Load Balancer: Sends traffic through fleets of third-party virtual appliances such as firewalls.
• Caching: CloudFront at the edge, API Gateway response caching, ElastiCache or DynamoDB Accelerator (DAX) in front of databases. Every cache hit is load the back end doesn't carry.
• Read replicas: Copies of a database that take read-only queries off the primary. Use them when reads, not writes, are the bottleneck.

Storage types

• Object storage (Amazon S3): Whole objects over HTTP, virtually unlimited, very durable. Static assets, data lakes, backups.
• File storage (Amazon EFS, Amazon FSx): Shared file systems many servers mount at once. EFS for Linux (NFS); FSx for Windows File Server (SMB), Lustre (HPC), NetApp ONTAP, and OpenZFS.
• Block storage (Amazon EBS): Volumes attached to an EC2 instance in one AZ, like a disk. Databases and boot volumes.
• AWS Transfer Family: Managed SFTP, FTPS, FTP, and AS2 endpoints that store files in S3 or EFS, so partners keep using the protocols they already have.

Choosing purpose-built services

• Match the service to the access pattern: DynamoDB for key-value lookups at any scale, Aurora or RDS for relational data, OpenSearch Service for search, Neptune for graphs, Keyspaces for Cassandra workloads, DocumentDB for MongoDB-compatible documents.
• Prefer a managed or serverless service when it meets the requirement: less to patch, scale, and keep available.