AWS Security Services Architecture — Overview

AWS provides a layered security services ecosystem for threat detection, vulnerability management, investigation, and centralized security posture management. Understanding how GuardDuty, Security Hub, Inspector, Detective, and Macie work together is essential for SCS-C03 and frequently tested on SAP-C02.

Service Comparison

How They Work Together

1. GuardDuty detects a compromised EC2 instance (cryptocurrency mining activity)
2. Security Hub receives the finding, correlates with Inspector findings (unpatched CVE on same instance)
3. EventBridge triggers automated response Lambda (isolates instance via Security Group change)
4. Detective investigates — shows what the compromised instance communicated with, what IAM calls it made, timeline of suspicious behavior
5. Config records the Security Group change for audit trail

Multi-Account Security Architecture

• Delegated Administrator: Designate a Security Tooling account as delegated admin for GuardDuty, Security Hub, Inspector, Macie (not the management account)
• Auto-enable: New member accounts automatically enrolled in all security services
• Cross-region aggregation: Security Hub can aggregate findings from all regions into a single region
• Centralized logging: All findings → Security Hub → EventBridge → S3 (Log Archive account) for SIEM integration

Automated Response Patterns

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A security team receives a GuardDuty finding that an EC2 instance is communicating with a known command-and-control (C2) server. They need to immediately contain the threat AND preserve forensic evidence. What should the automated response do?

1. Terminate the instance immediately
2. Change the Security Group to deny all traffic (isolate) but keep the instance running
3. Take an AMI snapshot and then terminate the instance
4. Remove the instance from its Auto Scaling Group

Question 2:

A company needs to ensure all EC2 instances across 50 accounts are scanned for software vulnerabilities (CVEs) automatically, with findings centralized in one place. Which architecture achieves this with LEAST operational overhead?

1. Install vulnerability scanning agents on all EC2 instances manually
2. Amazon Inspector with delegated admin in Security Tooling account, auto-enable for all org accounts, findings to Security Hub
3. AWS Config rules checking for unpatched software
4. GuardDuty Malware Protection scanning all instances

Question 3:

A compliance team needs to verify that no S3 bucket in the organization contains unencrypted PII (Social Security numbers, credit card numbers). They need ongoing monitoring, not just a one-time scan. Which service provides this?

1. AWS Config rule checking S3 encryption settings
2. Amazon Macie with automated sensitive data discovery
3. S3 access logging analysis with Athena
4. GuardDuty S3 protection

Question 4:

After GuardDuty detects suspicious API calls from an IAM user’s access keys, a security analyst needs to understand: what other resources did this user access in the last 30 days? What was their normal behavior pattern vs current anomaly? Which service provides this investigation capability?

1. CloudTrail Lake with SQL queries
2. Amazon Detective with entity behavior graphs
3. Security Hub finding details
4. CloudWatch Logs Insights

Question 5:

A company uses Security Hub with CIS AWS Foundations Benchmark. They want non-compliant findings to be automatically remediated (e.g., disable unused access keys, enable S3 encryption). What is the recommended automation architecture?

1. Security Hub → SNS → manual review → manual fix
2. Security Hub → EventBridge rules (filter by finding type) → SSM Automation documents (remediation)
3. AWS Config auto-remediation rules for each check
4. Lambda scheduled to scan Security Hub findings hourly and fix them

Related Architecture Patterns

• Zero Trust Security
• Multi-Account Architecture
• Config vs CloudTrail vs CloudWatch
• All Architecture Patterns – Hub

Related Posts

• AWS Zero Trust Architecture
• Multi-Account Architecture – Organizations & Control Tower
• Network Firewall vs WAF vs Security Groups vs NACLs
• Responsible AI – Guardrails & Governance
• WAF vs Shield vs Firewall Manager

References

• AWS Security Reference Architecture
• Automate Remediation with GuardDuty and Security Hub — AWS Blog
• Amazon Inspector EC2 Scanning — AWS Blog
• Amazon Detective Simplifies Investigations — AWS Blog

Frequently Asked Questions

What is the difference between GuardDuty and Inspector?

GuardDuty detects active threats and malicious behavior (someone attacking you NOW — C2 communication, brute force, cryptocurrency mining). Inspector finds vulnerabilities that COULD be exploited (unpatched CVEs, misconfigured software). GuardDuty = “you’re being attacked.” Inspector = “you’re vulnerable to attack.”

Do I need both Security Hub and GuardDuty?

Yes — they serve different roles. GuardDuty is a detection engine that generates findings. Security Hub is an aggregation and management platform that collects findings from GuardDuty AND Inspector, Macie, Config, Firewall Manager, and third-party tools. Security Hub provides the unified dashboard, compliance scoring, and automated action triggers.

What is the delegated administrator pattern?

Instead of managing security services from the management account (which should have minimal workloads), you designate a Security Tooling account as delegated admin for GuardDuty, Security Hub, Inspector, and Macie. This account manages security across all org members without needing access to the management account.

Kinesis vs MSK (Managed Kafka) — Overview

AWS offers two managed streaming platforms: Amazon Kinesis Data Streams (AWS-native, serverless option) and Amazon MSK (managed Apache Kafka). Both handle real-time data streaming but differ in complexity, ecosystem, pricing, and operational model. This comparison is relevant for SAP-C02 (architecture selection) and MLA-C01 (data ingestion for ML).

Feature Comparison

Decision Guide

Architecture Patterns

Pattern 1: Kinesis — Real-time Analytics Pipeline

• Flow: IoT devices → Kinesis Data Streams → Managed Flink (windowed aggregation) → DynamoDB/Redshift
• Why Kinesis: Serverless (on-demand mode), Lambda integration for lightweight processing, Firehose for direct S3/Redshift delivery

Pattern 2: MSK — Event Backbone for Microservices

• Flow: 20 microservices produce → MSK topics → Consumer groups per team → Each team processes independently
• Why MSK: Kafka Connect pulls from databases (CDC), consumer groups allow unlimited independent readers, Kafka Streams for stateful processing

Pattern 3: MSK → Kinesis Firehose (Best of Both)

• Flow: MSK (high-throughput streaming backbone) → Firehose (managed delivery to S3/Redshift/OpenSearch)
• Why: Kafka ecosystem for producers/consumers + Firehose’s auto-batching, compression, and format conversion for lake/warehouse delivery

Pricing Comparison

Rule of thumb: Kinesis is cheaper below ~5 MB/s. MSK becomes more cost-effective above ~50 MB/s with provisioned brokers + Graviton instances.

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

A company is migrating from self-managed Apache Kafka on EC2 to a managed service. They have 30+ microservices using Kafka producers/consumers with custom Kafka Connect connectors. They want to minimize code changes. Which service should they use?

1. Amazon Kinesis Data Streams (rewrite producers to use AWS SDK)
2. Amazon MSK (drop-in Kafka replacement, same client code)
3. Amazon SQS FIFO (provides ordering like Kafka)
4. Amazon EventBridge (replace Kafka topics with event bus rules)

Question 2:

A startup needs real-time clickstream processing. They want the simplest, most serverless approach: data arrives → process in real-time → deliver to S3 in Parquet format. No Kafka expertise on the team. Which combination is simplest?

1. MSK Serverless → Kafka Streams → S3 sink connector
2. Kinesis Data Streams (on-demand) → Lambda → S3
3. Kinesis Data Streams → Kinesis Data Firehose → S3 (Parquet conversion built-in)
4. MSK → Managed Flink → S3

Question 3:

A financial platform needs exactly-once processing guarantees for payment events. Events must be processed exactly one time, even if producers retry. Which streaming option provides this natively?

1. Kinesis Data Streams with deduplication in Lambda consumer
2. Amazon MSK with Kafka transactions (exactly-once semantics)
3. SQS FIFO queue with deduplication ID
4. EventBridge with archive ensuring no duplicates

Question 4:

A company streams 500 MB/s of log data from 1000 servers. They need 30 days retention and 5 independent consumer applications reading the same data. Which is MOST cost-effective?

1. Kinesis with 500 shards + Enhanced Fan-Out for 5 consumers
2. MSK Provisioned with Graviton brokers + tiered storage + 5 consumer groups
3. Kinesis on-demand mode with 5 Lambda consumers
4. 5 separate Kinesis streams (one per consumer)

Question 5:

A team uses Kinesis Data Streams but finds that one consumer (analytics) is falling behind because the shared shard read limit (2MB/s) is consumed by another faster consumer (alerting). How should they fix this without increasing shards?

1. Increase the consumer’s batch size
2. Register the analytics consumer as an Enhanced Fan-Out (EFO) consumer
3. Move the analytics consumer to a separate Kinesis stream
4. Switch to MSK for consumer group isolation

Related Architecture Patterns

• SNS vs SQS vs EventBridge
• Event-Driven Serverless
• Data Lake & Analytics
• All Architecture Patterns – Hub

Related Posts

• SQS Standard vs FIFO – Differences, Ordering & When to Use
• Kinesis Streams vs Firehose vs Managed Flink
• SNS vs SQS vs EventBridge
• Event-Driven Serverless Architecture
• Data Lake & Analytics Architecture

References

• Best Practices for Kafka on AWS — AWS Blog
• Amazon MSK Serverless — AWS Blog
• Kinesis Enhanced Fan-Out — AWS Docs
• MSK Tiered Storage — AWS Blog

Frequently Asked Questions

Can I use Kinesis with existing Kafka consumers?

Not directly — Kinesis uses a proprietary API (AWS SDK / KCL), not the Kafka protocol. If you have existing Kafka consumers, MSK allows them to work with zero changes. To use Kinesis, you’d need to rewrite consumers using the KCL or Lambda event source mapping.

What is MSK Serverless vs MSK Provisioned?

MSK Serverless auto-scales partitions and throughput — no broker management, pay per data. MSK Provisioned gives you dedicated broker instances (you choose types, scaling is manual). Serverless is simpler; Provisioned is cheaper at high sustained throughput and gives more configuration control.

When should I use Managed Flink instead of Lambda for stream processing?

Use Lambda for simple, stateless per-record transformations (filter, enrich, route). Use Managed Flink for complex stateful processing: windowed aggregations, joins across streams, pattern detection, CEP (Complex Event Processing). Flink maintains state across records; Lambda processes each batch independently.

SNS vs SQS vs EventBridge — Overview

AWS offers three core messaging/eventing services that are often confused. Each serves a distinct purpose: SQS for queuing (point-to-point buffering), SNS for pub/sub (fan-out notifications), and EventBridge for event routing (content-based filtering from many sources). Choosing the right one — or combining them — is a frequent SAP-C02 and DOP-C02 exam question.

Feature Comparison

Decision Guide — When to Use Which

Common Architecture Patterns

Pattern 1: SNS + SQS Fan-out (Most Common)

One event → multiple independent processors, each with their own retry and failure handling.

• Flow: Order Service → SNS Topic → SQS-Inventory + SQS-Email + SQS-Analytics (each with Lambda consumer)
• Why not just SNS → Lambda directly? SQS adds buffering, retry with backoff, DLQ, and prevents Lambda throttling from affecting other consumers.

Pattern 2: EventBridge + SNS + SQS (Full Decoupling)

Many producers → EventBridge routes by type → SNS fans out → SQS buffers each consumer.

• Flow: 10 microservices emit events → EventBridge (rules filter by event type) → SNS per domain → SQS per consumer
• Why: Producers don’t know about consumers. New consumers subscribe without changing producers.

Pattern 3: SQS as Lambda Buffer (Load Leveling)

Protect downstream from traffic spikes.

• Flow: API Gateway → SQS → Lambda (controlled concurrency)
• Why: API Gateway has unlimited throughput but Lambda has concurrency limits. SQS absorbs spikes and Lambda processes at a controlled rate.

Pattern 4: EventBridge for AWS Service Events

React to infrastructure changes automatically.

• Flow: EC2 instance terminates → EventBridge rule → Lambda (cleanup DNS/LB) + SNS (alert ops team)
• Why: EventBridge receives AWS service events natively without any configuration on the source side.

Pricing Comparison

Cost tip: AWS service events on EventBridge (EC2 state changes, S3 events via EventBridge, etc.) are FREE. Only custom/partner events incur the $1/M charge.

Exam Tips

AWS Certification Exam Practice Questions

Question 1:

An order processing system needs to trigger three downstream services (inventory, billing, shipping) independently. If billing fails, inventory and shipping should still succeed. Each service needs its own retry logic. Which architecture is BEST?

1. SNS topic → 3 Lambda subscribers directly
2. SNS topic → 3 SQS queues (each with own Lambda consumer and DLQ)
3. EventBridge → 3 Lambda targets on one rule
4. SQS queue → Lambda → calls 3 services sequentially

Question 2:

A company receives events from 15 microservices. They need to route “payment” events to the payment processor, “inventory” events to the warehouse system, and “audit” events to the compliance system — based on an “event_type” field in the JSON body. Which service provides this content-based routing?

1. SNS with message attribute filter policies
2. SQS with multiple queues and client-side routing
3. EventBridge with rules filtering on event body content
4. Kinesis with partition key-based routing

Question 3:

A bug in a consumer caused it to silently discard events for 6 hours before being discovered. The events were published to SNS. Can they be recovered?

1. Yes — replay from SNS message retention
2. Yes — if the SQS subscriber had a DLQ configured
3. No — SNS does not persist messages; once delivered they are gone
4. Yes — retrieve from CloudWatch Logs

Question 4:

A company wants to trigger a Lambda function when ANY EC2 instance in their account changes state (running, stopped, terminated). They want this with zero custom code on the producer side. Which approach works?

1. CloudWatch Events (same as EventBridge) rule for EC2 state change → Lambda target
2. SNS topic that EC2 publishes to on state change → Lambda subscription
3. SQS queue polled by Lambda checking EC2 DescribeInstances
4. CloudTrail log with S3 event notification triggering Lambda

Question 5:

A team uses SNS to fan out order events to 5 subscribers. One subscriber (analytics) only needs “premium” orders (order_value > $100). Currently it receives ALL orders and filters client-side, wasting Lambda invocations. How should they reduce unnecessary invocations?

1. Create a separate SNS topic for premium orders
2. Add an SNS subscription filter policy matching the “order_tier” message attribute = “premium”
3. Replace SNS with EventBridge and use content-based filtering on order_value
4. Add a Lambda@Edge function to filter before delivery

Related Architecture Patterns

• Event-Driven Serverless
• Kinesis vs MSK
• Container Platform (ECS/EKS)
• All Architecture Patterns – Hub

Related Posts

• SQS Standard vs FIFO Queue – Complete Comparison
• AWS Event-Driven Serverless Architecture
• Lambda vs Step Functions vs EventBridge
• Kinesis Streams vs Firehose vs Managed Flink
• GenAI Application Architecture

References

• Choosing Between Messaging Services for Serverless — AWS Blog
• Let’s Architect: Event-Driven Architectures — AWS Blog
• Amazon EventBridge User Guide
• Building Event-Driven Applications with EventBridge — AWS Blog
• Filtering Messages with Amazon SNS — AWS Blog

Frequently Asked Questions

When should I use EventBridge vs SNS?

Use EventBridge when you need content-based filtering on the event body, integration with AWS service events or SaaS partners, schema discovery, or event replay. Use SNS for simple fan-out where attribute-based filtering is sufficient, multi-protocol delivery (email, SMS), or when you need FIFO ordering with topics.

Can I use SQS without SNS?

Yes. Use SQS alone when you have a single producer and single consumer (point-to-point). The producer sends directly to the queue, and one consumer processes messages. Add SNS in front only when you need the same message delivered to multiple independent consumers (fan-out).

What happens if an SNS subscriber is down?

For Lambda/HTTP subscribers: SNS retries with backoff (up to 23 days for HTTP). For SQS subscribers: messages are delivered to the SQS queue immediately (SQS is always “up”) and wait until the consumer processes them. This is why SNS→SQS is more reliable than SNS→Lambda directly — SQS persists messages even if the consumer is temporarily unavailable.

AWS Database Migration Architecture — Overview

Database migration is one of the most common workload migration patterns on AWS. The architecture combines AWS Database Migration Service (DMS) for data replication, AWS Schema Conversion Tool (SCT) for schema transformation, and various strategies depending on source/target compatibility and downtime tolerance. This is a core topic for SAP-C02 (migration scenarios) and DOP-C02 (automation).

AWS Database Migration Service (DMS)

DMS replicates data from source to target with minimal downtime. It runs on a managed replication instance in your VPC.

How DMS Works

1. Full Load: Migrates all existing data from source tables to target tables
2. Change Data Capture (CDC): Continuously replicates ongoing changes (inserts, updates, deletes) after full load completes
3. Full Load + CDC: Combines both — migrates existing data, then keeps target in sync until cutover

DMS Components

Supported Sources and Targets

AWS Schema Conversion Tool (SCT)

SCT converts database schemas and code from one engine to another (heterogeneous migrations only):

• Schema conversion: Tables, indexes, views, constraints → target engine syntax
• Code conversion: Stored procedures, functions, triggers → target equivalent
• Assessment Report: Identifies what can be auto-converted vs what needs manual effort (red/yellow/green)
• Data Extraction Agents: For large-scale migrations, SCT agents extract data in parallel to S3, then load into target

Not needed for homogeneous migrations (e.g., MySQL → Aurora MySQL) since the schema is compatible.

Migration Strategies (The 7 Rs)

Zero-Downtime Migration Pattern

1. Provision target — Create Aurora/RDS in target region/account
2. SCT (if heterogeneous) — Convert and apply schema to target
3. DMS Full Load + CDC — Start migration task: initial load + ongoing replication
4. Validation — Enable DMS data validation to compare source vs target row counts and checksums
5. Application testing — Point test/staging app at target DB, validate functionality
6. Cutover — Stop writes to source → Wait for CDC to catch up (seconds) → Redirect application to target
7. Decommission — Monitor target, then retire source after confidence period

Downtime: Only during step 6 (seconds to minutes — time for last CDC events to apply + DNS/connection string update).

Large-Scale Migration (TB to PB)

• Problem: Migrating 50TB+ over network takes weeks even on Direct Connect
• Solution: AWS Snowball Edge for initial bulk transfer + DMS CDC for changes during transit
• Pattern: Start CDC from Day 1 → Ship Snowball (days) → Load Snowball data to target → Apply accumulated CDC → Cutover
• Alternative: SCT Data Extraction Agents — parallel extraction to S3 via Direct Connect, then load to target

Target Database Selection

Exam Tips by Certification

AWS Certification Exam Practice Questions

Question 1:

A company needs to migrate a 10TB Oracle database to Aurora PostgreSQL with less than 1 hour of downtime. The application must continue running during migration. Which approach achieves this?

1. Use AWS SCT to convert schema, then pg_dump/pg_restore for data
2. Use AWS SCT for schema + DMS with Full Load and CDC, then cutover after CDC catches up
3. Create an Oracle RDS instance first, then use Aurora read replica promotion
4. Use AWS Snowball Edge to transfer the data, then apply schema with SCT

Question 2:

A company has a 50TB data warehouse they want to migrate to AWS. Network bandwidth to AWS is 1 Gbps (would take ~5 days for full transfer). They need the target ready within 2 weeks and cannot tolerate data loss. What is the MOST efficient approach?

1. DMS Full Load over Direct Connect for 5 days, then CDC
2. AWS Snowball Edge for bulk data + DMS CDC running in parallel from Day 1
3. S3 Transfer Acceleration for faster upload
4. Multiple DMS replication instances in parallel

Question 3:

A company is migrating from Oracle to Aurora PostgreSQL. The SCT assessment report shows 60% of stored procedures can be auto-converted, but 40% require manual intervention. The migration has a 3-month deadline. What should they prioritize?

1. Rewrite all stored procedures in the application layer and remove database logic
2. Convert the 60% automatically with SCT, manually convert the critical 40%, begin DMS replication in parallel
3. Stay on Oracle and rehost to Oracle on EC2 instead
4. Use AWS Lambda to emulate Oracle stored procedures

Question 4:

After starting a DMS migration task, a company notices some tables have row count mismatches between source and target. What DMS feature helps identify and resolve this?

1. CloudWatch metrics for table statistics
2. DMS data validation (automatic source-target comparison)
3. DMS premigration assessment
4. AWS Config compliance rules

Question 5:

A company wants to migrate their on-premises MySQL database to RDS MySQL. The source and target use the same engine version. What is the SIMPLEST migration approach?

1. SCT for schema conversion + DMS for data migration
2. DMS only (Full Load + CDC) — no SCT needed for homogeneous migration
3. mysqldump export → S3 → RDS import
4. Create RDS read replica from on-premises using binary log replication

Related Architecture Patterns

• Data Lake & Analytics
• Disaster Recovery
• Hybrid Cloud Networking
• All Architecture Patterns – Hub

Related Posts

• AWS DMS – Database Migration Service, CDC & Replication
• AWS RDS Replication – Multi-AZ & Read Replicas
• Aurora vs RDS vs DynamoDB – Selection Guide
• AWS Data Lake & Analytics Architecture
• AWS Disaster Recovery Architecture
• Hybrid Cloud Networking – Direct Connect & Transit Gateway
• Migration Architecture – 7Rs & Tools
• RDS & Aurora Performance

References

• AWS Database Migration Service User Guide
• Migrate Oracle to Aurora – AWS Database Blog
• Migrating Large Databases to AWS – Prescriptive Guidance
• Best Practices for Migrating to Amazon Aurora – AWS Blog
• Database Migration Strategy – AWS Prescriptive Guidance

Frequently Asked Questions

What is the difference between DMS and SCT?

DMS migrates the data (rows) from source to target with optional ongoing replication (CDC). SCT converts the schema and code (stored procedures, functions, triggers) from one database engine to another. For homogeneous migrations (same engine), only DMS is needed. For heterogeneous migrations (different engines), both SCT and DMS are required.

Can DMS migrate to a different AWS region?

Yes. DMS supports cross-region migration. The replication instance can be in either the source or target region. For on-premises to AWS, place the replication instance in the target region. For cross-region AWS migrations, place it in the target region for better performance (closer to where data is written).

How do I achieve zero-downtime migration?

Use DMS Full Load + CDC: the full load migrates existing data while the application continues running. CDC captures all changes made during migration. At cutover, briefly stop application writes (seconds), wait for CDC to apply final changes, then redirect the application to the new target. Total downtime: seconds to minutes.

AWS Architecture Patterns — Reference Diagrams for Certification

58 architecture pattern posts covering all 12 AWS certification exams. Each post includes HTML/CSS diagrams, comparison tables, design decisions, exam tips, and 5 practice questions with expandable answers.

🏗️ Core Architecture Patterns (SAP-C02 / SAA-C03)

🌐 Networking (ANS-C01 / SAP-C02)

🔒 Security (SCS-C03 / SAP-C02)

🤖 AI/ML & GenAI (AIP-C01 / AIF-C01 / MLA-C01)

📊 Data & Analytics (DAS-C01 / DEA-C01 / DBS-C01)

⚙️ DevOps & Operations (DOP-C02 / SOA-C03)

🚀 Migration & Storage (SAP-C02 / SAA-C03)

AWS Container Platform Architecture — Overview

Containers are the standard deployment unit for microservices on AWS. The platform spans image management (ECR), orchestration (ECS/EKS), compute (Fargate/EC2), networking (ALB/NLB/Service Connect), and observability (Container Insights/X-Ray). This architecture is heavily tested on DOP-C02 (deployment and operations) and SAP-C02 (architectural decisions).

ECS vs EKS — Decision Guide

Compute — Fargate vs EC2

Cost Decision Rule of Thumb

• Fargate cheaper when: Utilization is <50% (bursty workloads, dev/test, batch jobs)
• EC2 cheaper when: Utilization is >50% consistently (use Reserved Instances or Savings Plans + Spot for non-critical)
• Mixed strategy: Fargate for baseline + EC2 Spot capacity providers for spikes

Networking Patterns

Ingress (North-South)

• ALB: Layer 7 — path/host routing, gRPC, WebSocket, authentication integration. Best for HTTP/HTTPS microservices.
• NLB: Layer 4 — ultra-low latency, static IPs, TCP/UDP. Best for non-HTTP protocols, high throughput.
• API Gateway: For serverless-first architectures integrating with containers via VPC Link → NLB → ECS/EKS.

Service Discovery (East-West)

Auto-Scaling

ECS Scaling

• Service Auto Scaling: Target tracking (CPU/Memory utilization), step scaling, or scheduled scaling on desired task count
• Capacity Providers: ECS manages EC2 ASG capacity automatically — scales nodes when tasks need capacity
• Fargate: No node scaling needed — each task gets its own compute instantly

EKS Scaling

• Horizontal Pod Autoscaler (HPA): Scales pod replicas based on CPU/memory/custom metrics
• Karpenter: Provisions optimal EC2 nodes in seconds based on pending pod requirements (replaces Cluster Autoscaler)
• KEDA: Event-driven scaling (scale on SQS queue depth, Kafka lag, custom metrics)
• Fargate on EKS: Pods run serverless — no node scaling, instant per-pod provisioning

Deployment Strategies

Security

Observability Stack

• Container Insights: CPU, memory, network, disk metrics per task/pod + cluster-level dashboards (CloudWatch)
• X-Ray: Distributed tracing across services — inject X-Ray daemon as sidecar or use ADOT (OpenTelemetry)
• FireLens: ECS log router (Fluent Bit sidecar) — route logs to CloudWatch, S3, OpenSearch, Datadog, Splunk
• Prometheus + Grafana: Native for EKS — Amazon Managed Prometheus (AMP) + Amazon Managed Grafana (AMG)
• EKS audit logs: Control plane API audit logs → CloudWatch Logs (detect unauthorized access attempts)

Exam Tips by Certification

AWS Certification Exam Practice Questions

Question 1:

A company runs 50 microservices on EKS. Their cluster nodes are often under-utilized (30% average CPU) because the Cluster Autoscaler provisions nodes too conservatively. They want faster scaling with better bin-packing. What should they use?

1. Increase HPA target utilization from 50% to 80%
2. Replace Cluster Autoscaler with Karpenter
3. Switch all workloads to Fargate
4. Use larger EC2 instance types for better packing

Question 2:

An ECS service needs to connect to other ECS services by name (e.g., http://payment-service:8080) with automatic load balancing, health checking, and traffic metrics — without managing an ALB for each internal service. Which feature provides this?

1. Cloud Map DNS-based discovery
2. ECS Service Connect
3. VPC Lattice
4. Application Load Balancer with multiple target groups

Question 3:

An EKS pod needs to access an S3 bucket and DynamoDB table. The security team requires that ONLY this specific pod gets these permissions — not other pods on the same node. What is the recommended approach?

1. Attach the permissions to the node’s EC2 instance profile
2. Use IAM Roles for Service Accounts (IRSA) or EKS Pod Identity
3. Store access keys as K8s secrets and mount in the pod
4. Use a VPC endpoint policy to restrict access to this pod’s security group

Question 4:

A company wants zero-downtime deployments for their ECS Fargate service with the ability to instantly roll back if health checks fail. The deployment should create a new task set, validate it, then switch traffic. Which configuration achieves this?

1. ECS rolling update with minimumHealthyPercent=100, maximumPercent=200
2. CodeDeploy Blue/Green deployment with ECS, ALB listener rules, and CloudWatch alarm-based rollback
3. Manual task count adjustment — double tasks, then drain old
4. ECS service with multiple task definitions running simultaneously

Question 5:

A startup runs a variable workload on ECS — 2 tasks during business hours and 0 tasks at night. They want minimum cost with no node management overhead. On weekdays, tasks need to scale up to 20 within seconds during marketing campaigns. Which configuration fits?

1. EC2 launch type with Reserved Instances and an ASG scheduled action
2. Fargate launch type with ECS Service Auto Scaling (target tracking on CPU)
3. EC2 Spot instances with capacity provider managed scaling
4. Fargate Spot for all tasks to minimize cost

Related Architecture Patterns

• CI/CD Pipeline Architecture
• Event-Driven Serverless
• Zero Trust Security
• All Architecture Patterns – Hub

Related Posts

• AWS EKS vs ECS – Decision Guide
• AWS ALB vs NLB vs GWLB
• AWS CI/CD Pipeline Architecture
• AWS Event-Driven Serverless Architecture
• AWS Zero Trust Architecture

References

• AWS Containers Blog
• EKS Best Practices Guide
• ECS Service Connect — AWS Blog
• Karpenter — Node Autoscaling for Kubernetes
• ECS Deployment Circuit Breaker — AWS Blog

📖 Related: Launch Template vs Launch Configuration

Frequently Asked Questions

Is Fargate always more expensive than EC2?

No. Fargate is cheaper for variable, bursty workloads with <50% average utilization because you pay nothing when tasks aren’t running. EC2 becomes cheaper at >50% sustained utilization, especially with Reserved Instances or Savings Plans. Most production workloads benefit from a mix: Fargate for base + EC2 Spot for peaks.

ECS vs EKS for a new project — which should I pick?

If your team has no Kubernetes experience and you’re AWS-only, choose ECS — less operational overhead, tighter AWS integration, no control plane cost. If you need Kubernetes portability, have K8s expertise, or want ecosystem tools (Helm, ArgoCD, Istio, OPA), choose EKS. Both support Fargate.

Can I run sidecars on Fargate?

Yes. ECS Fargate supports multiple containers per task definition (native sidecars with lifecycle dependencies since 2023). EKS Fargate also supports sidecar containers in pods. Common sidecars: Envoy (Service Connect), X-Ray daemon, Fluent Bit (logs), ADOT (OpenTelemetry).

AWS Data Lake & Analytics Architecture — Overview

A data lake centralizes structured, semi-structured, and unstructured data in S3, enabling analytics at scale without upfront schema design. Combined with AWS analytics services, it forms a complete pipeline from ingestion through transformation to visualization. This architecture is critical for SAP-C02 (architectural decisions) and MLA-C01 (data preparation for ML).

Data Lake Zones

A well-designed data lake organizes data into zones (S3 prefixes) representing data maturity:

Key principle: Raw zone is immutable — never modify source data. All transformations produce new objects in curated/enriched zones. This enables reprocessing if transformation logic changes.

Ingestion Layer

Catalog & Governance — Lake Formation

AWS Lake Formation is the governance layer that sits on top of the Glue Data Catalog:

• Glue Data Catalog: Central metadata repository — databases, tables, schemas, partitions (Hive metastore compatible)
• Lake Formation Permissions: Fine-grained access control (row-level, column-level, cell-level filtering)
• Tag-Based Access Control (TBAC): Assign tags to tables/columns (e.g., “PII=true”), grant access based on tags — scales across thousands of tables
• Cross-account sharing: Share databases/tables with other AWS accounts via RAM or direct grant (no data copying)
• Governed Tables: ACID transactions on S3 data (via Apache Iceberg integration)

Processing & Transformation

Analytics & Visualization

Cost Optimization

• Columnar formats (Parquet/ORC): 3-5x compression vs CSV/JSON, Athena scans less data = lower cost
• Partitioning: Partition by date/region/product — queries scan only relevant partitions (e.g., WHERE year=2026 scans 1/N of data)
• Compaction: Merge small files into larger ones (1-128MB optimal) — reduces list/get operations and improves query speed
• S3 Intelligent-Tiering: Automatically moves infrequently accessed data to cheaper tiers (no retrieval fees)
• Athena workgroups: Set per-query and per-workgroup data scan limits to prevent runaway costs
• Redshift Serverless: Pay per RPU-second — no idle cost for intermittent warehouse workloads

Exam Tips by Certification

AWS Certification Exam Practice Questions

Question 1:

A company stores 50TB of data in S3 as CSV files. Data analysts run Athena queries daily but costs are high ($500/day) because queries scan the entire dataset. What TWO changes would MOST reduce Athena costs?

1. Convert CSV to Parquet and partition by date
2. Move data to Redshift and query there instead
3. Enable S3 Transfer Acceleration for faster queries
4. Add more Athena workgroups to distribute load

Question 2:

A financial company needs different teams to access different columns of the same table. The compliance team needs all columns, while the analytics team should NOT see PII columns (SSN, email). The table has 200+ columns. What is the MOST scalable approach?

1. Create separate copies of the table with PII columns removed for analytics
2. Lake Formation column-level permissions with tag-based access control
3. S3 bucket policies restricting access to specific prefixes per team
4. Athena views that exclude PII columns for the analytics team

Question 3:

A company needs to continuously replicate changes from their on-premises Oracle database to S3 for analytics. They need ongoing synchronization (not just a one-time migration) with minimal impact on the source database. Which service provides this?

1. AWS Glue with JDBC connection on a schedule
2. AWS DMS with CDC (Change Data Capture) to S3 target
3. Kinesis Data Firehose with custom producer
4. AWS DataSync on a recurring schedule

Question 4:

A data engineering team needs to process 5TB of raw JSON data daily, apply complex transformations (joins across 10 tables, deduplication, schema evolution), and write results to S3 in Parquet. They want serverless with no cluster management. Which service fits?

1. Athena CTAS (Create Table As Select)
2. AWS Glue ETL with auto-scaling
3. Amazon EMR Serverless
4. Lambda with S3 batch operations

Question 5:

A company wants to share specific tables from their data lake with a partner AWS account without copying data. The partner should only see curated tables with certain rows filtered (e.g., only their region’s data). What is the recommended approach?

1. Copy filtered data to an S3 bucket in the partner account nightly
2. Lake Formation cross-account sharing with row-level security filters
3. Redshift data sharing with the partner account
4. S3 bucket policy granting partner account read access to specific prefixes

Related Architecture Patterns

• Kinesis vs MSK
• MLOps Pipeline Architecture
• Database Migration (DMS)
• All Architecture Patterns – Hub

Related Posts

• AWS S3 Storage Classes
• Kinesis Data Streams vs Firehose vs Managed Flink
• Amazon Athena
• AWS S3 vs EBS vs EFS – Storage Comparison
• AWS MLOps Pipeline Architecture
• AWS Event-Driven Serverless Architecture
• EMR & Spark Architecture

References

• Building a Data Lake on AWS — AWS Whitepaper
• Design a Data Mesh Architecture Using Lake Formation and Glue — AWS Blog
• Build a Serverless Data Pipeline with Glue and Athena — AWS Blog
• Best Practices for Data Lake S3 Bucket Organization — AWS Prescriptive Guidance
• Reduce Cost and Improve Query Performance with Athena — AWS Blog

📖 Related: AWS EBS Volume Types – Performance & Cost Comparison

Frequently Asked Questions

Data lake vs data warehouse — when to use which?

A data lake (S3) stores raw data in any format at low cost — best for data exploration, ML, and diverse data types. A data warehouse (Redshift) stores structured, pre-modeled data optimized for fast, repeated analytical queries. Most organizations use both: lake for storage/exploration, warehouse for production dashboards and business intelligence.

AWS Glue vs EMR — when to use which?

Use Glue for standard ETL jobs where you want serverless, auto-scaling, and visual job authoring. Use EMR when you need custom Spark/Hadoop configurations, specific library versions, long-running clusters, or workloads exceeding Glue’s capabilities. Glue is simpler; EMR is more flexible and cost-effective at very large scale with spot instances.

What is Lake Formation vs Glue Data Catalog?

Glue Data Catalog is the metadata repository (table definitions, schemas, partitions). Lake Formation is the governance layer on top that adds fine-grained access control (row/column/cell-level), tag-based permissions, cross-account sharing, and data location registration. Lake Formation uses the Catalog underneath but adds security and governance.

AWS Hybrid Cloud Networking Architecture — Overview

Hybrid cloud networking connects on-premises data centers to AWS, enabling workload migration, burst capacity, disaster recovery, and multi-cloud strategies. The architecture must balance bandwidth, latency, cost, encryption, and redundancy. This is a core focus area for SAP-C02 and the Advanced Networking Specialty (ANS-C01).

Connectivity Options Compared

When to Use Which

• Direct Connect: Large data transfers (TB+), consistent low-latency requirements, reduced egress costs, compliance requiring private connectivity
• Site-to-Site VPN: Quick setup, encrypted by default, backup for Direct Connect, low-moderate bandwidth needs
• DX + VPN together: Encryption over private connection (Direct Connect provides bandwidth + VPN provides encryption)
• Client VPN: Individual remote users needing access to VPC resources (being replaced by Verified Access for Zero Trust)

AWS Transit Gateway — Central Hub

Transit Gateway is the single point of connectivity for all VPCs, VPNs, Direct Connect, and peered Transit Gateways:

• Hub-and-spoke: All VPCs attach to TGW instead of meshing VPC peering (N² problem → N attachments)
• Route tables: Separate route tables for network segmentation (Prod, Dev, Shared Services — control who talks to whom)
• Multi-region: Transit Gateway Peering connects TGWs across regions (inter-region traffic stays on AWS backbone)
• ECMP: Equal-Cost Multi-Path across VPN tunnels for aggregate bandwidth (e.g., 4 tunnels × 1.25 Gbps = 5 Gbps)
• Multicast: TGW supports multicast for financial/media workloads
• Appliance mode: Ensures symmetric routing when traffic passes through a virtual appliance (firewall) in a VPC

Direct Connect Architecture

Virtual Interfaces (VIFs)

High Availability for Direct Connect

• Maximum resilience: 2 DX connections at 2 separate DX locations (protects against location failure)
• High resilience: 2 DX connections at 1 DX location (protects against device failure)
• DX + VPN backup: Direct Connect as primary, Site-to-Site VPN as failover (via BGP priority)
• LAG (Link Aggregation): Bundle multiple connections at same location for aggregate bandwidth

Hybrid DNS — Route 53 Resolver

Hybrid DNS ensures name resolution works seamlessly between on-premises and AWS:

• Inbound Endpoint: On-premises DNS servers forward queries for AWS-hosted domains (e.g., *.aws.internal) → Route 53 Resolver resolves them
• Outbound Endpoint: AWS resources query on-premises domains (e.g., corp.example.com) → Route 53 Resolver forwards to on-premises DNS
• Resolver Rules: Define which domains forward where (conditional forwarding)
• RAM sharing: Share Resolver Rules across accounts so all VPCs in the org resolve hybrid DNS consistently

Centralized Egress & Inspection

Instead of NAT Gateway per VPC (expensive), centralize in a dedicated egress VPC:

• Egress VPC: Contains NAT Gateways + AWS Network Firewall
• TGW routing: All VPCs’ 0.0.0.0/0 route points to TGW → TGW routes to Egress VPC
• Network Firewall: Inspects all outbound traffic (domain filtering, IDS/IPS, stateful rules)
• Cost savings: One set of NAT Gateways shared across all VPCs vs per-VPC NATs

Multi-Region Networking

• Transit Gateway Peering: Connect TGWs across regions for inter-region VPC communication (static routes)
• Direct Connect Gateway: Single DX connection → access VPCs in multiple regions (via TGW in each region)
• Global Accelerator: Anycast IPs that route to nearest healthy AWS endpoint (for multi-region failover)
• CloudFront: Edge caching for static/dynamic content, reducing latency for global users

Exam Tips by Certification

AWS Certification Exam Practice Questions

Question 1:

A company has a 10 Gbps Direct Connect connection for production traffic. They need encrypted connectivity to AWS for compliance, but Direct Connect is not encrypted by default. What is the MOST bandwidth-efficient solution?

1. Replace Direct Connect with Site-to-Site VPN (encrypted by default)
2. Create a Site-to-Site VPN over the Direct Connect connection (VPN over DX using public VIF)
3. Enable MACsec encryption on the Direct Connect connection
4. Use AWS CloudHSM to encrypt all traffic at the application layer

Question 2:

A company has 15 VPCs across 3 accounts. They need all VPCs to communicate with on-premises via a single Direct Connect connection, while keeping production VPCs isolated from development VPCs. What architecture achieves this?

1. VPC Peering between all VPCs + Virtual Private Gateway per VPC
2. Transit Gateway with separate route tables for Prod and Dev, connected to Direct Connect via DX Gateway
3. Direct Connect with 15 Private VIFs (one per VPC)
4. AWS PrivateLink between all VPCs and on-premises

Question 3:

A company’s on-premises applications need to resolve AWS private hosted zone DNS names (e.g., api.internal.company.com hosted in Route 53). Currently, on-premises DNS queries for these names fail. What should be configured?

1. Create a public hosted zone and use public DNS resolution
2. Configure Route 53 Resolver Inbound Endpoints in the VPC and forward on-premises DNS to them
3. Replicate Route 53 records to on-premises DNS servers
4. Configure Route 53 Resolver Outbound Endpoints with forwarding rules

Question 4:

A company wants to access S3 and DynamoDB from on-premises without traversing the public internet. Their Direct Connect is already established. Which VIF type and configuration enables this?

1. Private VIF to a VPC with VPC Gateway Endpoints for S3/DynamoDB
2. Public VIF — advertises AWS public IP ranges over the DX connection
3. Transit VIF with TGW routing to S3 endpoints
4. Create an S3 VPC Interface Endpoint and route from on-prem via Private VIF

Question 5:

A company needs maximum resilience for their Direct Connect connectivity. Their compliance requires surviving a complete DX location failure. What is the minimum configuration?

1. Single DX connection with 2 Private VIFs
2. 2 DX connections at the same DX location
3. 2 DX connections at 2 different DX locations
4. 1 DX connection + Site-to-Site VPN as backup

Related Architecture Patterns

• Disaster Recovery Architecture
• Zero Trust Security
• Multi-Account Architecture
• All Architecture Patterns – Hub

Related Posts

• Route 53 Routing Policies – Simple, Weighted, Latency, Failover & Geolocation
• Route 53 Alias vs CNAME – Differences & When to Use Each
• AWS Virtual Private Cloud (VPC)
• AWS Direct Connect
• AWS VPC Explained – Beginners Guide
• Network Firewall vs WAF vs Security Groups vs NACLs
• AWS Multi-Account Architecture
• AWS Zero Trust Architecture
• VPC Connectivity Decision Guide – Peering vs TGW vs PrivateLink

References

• AWS Hybrid Connectivity Whitepaper
• Single Internet Exit Point from Multiple VPCs Using Transit Gateway — AWS Blog
• Integrating Transit Gateway with Direct Connect — AWS Blog
• AWS Direct Connect Resiliency Recommendations
• Simplify DNS Management in Multi-Account with Route 53 Resolver — AWS Blog

Frequently Asked Questions

Is Direct Connect encrypted?

No, by default Direct Connect is NOT encrypted — it’s a private connection but data travels in cleartext. For encryption, either enable MACsec (Layer 2, line-speed, on 10/100 Gbps) or create a Site-to-Site VPN over the DX connection (IPSec, limited to 1.25 Gbps per tunnel). MACsec is preferred for high-bandwidth encrypted private connectivity.

Transit Gateway vs VPC Peering — when to use which?

Use VPC Peering for simple point-to-point connectivity between 2-3 VPCs (no transitive routing, lower cost). Use Transit Gateway when you have 4+ VPCs, need on-premises connectivity, require route segmentation, or need transitive routing. TGW scales better but costs more (per-attachment + data processing fee).

What is a Direct Connect Gateway?

A Direct Connect Gateway is a globally available resource that connects your DX connection to VPCs/TGWs in any AWS region (not just the region where the DX location resides). One physical DX connection → DX Gateway → access VPCs across multiple regions. It supports both Private VIFs (→ VGW) and Transit VIFs (→ TGW).

AWS Event-Driven Serverless Architecture — Overview

Event-driven architecture (EDA) decouples services by communicating through events rather than direct calls. Combined with serverless compute, it provides automatic scaling, zero idle cost, and fault-tolerant loose coupling. This is a core pattern for SAP-C02 (architectural decisions) and DOP-C02 (automation and failure handling).

Core Event-Driven Patterns

1. Point-to-Point (Queue)

One producer → One consumer. SQS decouples them with buffering and retry.

• Use case: Order processing, task queues, async job execution
• Pattern: API Gateway → SQS → Lambda (poll-based)
• Guarantee: At-least-once (Standard) or Exactly-once (FIFO)

2. Pub/Sub (Fan-out)

One event → Multiple consumers process independently.

• Use case: Order placed → update inventory + send email + update analytics
• Pattern: SNS topic → multiple SQS queues (each with own Lambda consumer)
• Variant: SNS + filter policies → each subscriber gets only relevant events

3. Event Bus (Content-Based Routing)

Central router matches events to rules and routes to appropriate targets.

• Use case: Multi-service system where different events go to different processors
• Pattern: EventBridge rules with content filtering → specific Lambda/SQS/Step Functions per event type
• Advantage: Producers don’t know about consumers — fully decoupled

4. Orchestration (Step Functions)

Central coordinator manages multi-step workflows with branching, error handling, and retries.

• Use case: Order fulfillment (validate → charge → ship → notify), ETL pipelines
• Pattern: Step Functions state machine calling Lambda, ECS, Bedrock, DynamoDB directly
• Advantage: Visual workflow, built-in retry/catch, wait states, parallel execution

5. Choreography (Distributed Events)

No central coordinator — each service reacts to events and emits new events.

• Use case: Loosely coupled microservices, event sourcing
• Pattern: Service A emits event → EventBridge → Service B reacts + emits new event → Service C reacts
• Trade-off: More autonomous but harder to debug/trace end-to-end

Service Comparison — When to Use Which

Error Handling & Resilience

Idempotency — Critical for Event-Driven

At-least-once delivery means consumers may process the same event multiple times. Design for idempotency:

• DynamoDB conditional writes — Use event ID as key, conditional put (only if not exists)
• SQS FIFO deduplication — Built-in 5-minute deduplication window
• Idempotency key in Lambda — Store processed event IDs in DynamoDB/ElastiCache, skip if seen
• Powertools for Lambda — AWS Lambda Powertools provides idempotency utility out of the box

Scaling Considerations

• Lambda concurrency: Default 1000/region. Use reserved concurrency for critical functions, SQS batching to control invocation rate.
• SQS → Lambda scaling: Lambda auto-scales up to 1000 concurrent by adding 60 instances/minute. Batch size (1-10K) controls throughput.
• EventBridge throttling: 2400 PutEvents/sec default (soft limit). Rules trigger targets with target-specific throttling.
• Step Functions: Standard (2000 state transitions/sec), Express (100K/sec) — choose based on volume.
• SNS: Virtually unlimited throughput for publishing. Subscriber delivery follows target limits.

Exam Tips by Certification

AWS Certification Exam Practice Questions

Question 1:

An e-commerce application needs to process an order event by simultaneously updating inventory, sending a confirmation email, and notifying the warehouse. Each downstream service should process independently and failures in one should NOT affect others. Which pattern is MOST appropriate?

1. SQS queue with a single Lambda consuming and calling each service
2. SNS topic with SQS queue subscriptions for each downstream service (each with own Lambda)
3. Step Functions parallel state calling all three services
4. EventBridge with a single rule targeting all three Lambdas

Question 2:

A financial system processes payment events that MUST be processed exactly once and in the order they were submitted per customer. Different customers’ payments can be processed in parallel. Which configuration provides this?

1. SQS Standard queue with Lambda deduplication logic
2. SQS FIFO queue with MessageGroupId set to customer ID
3. Kinesis Data Stream with partition key set to customer ID
4. EventBridge with ordered delivery enabled

Question 3:

A multi-step order fulfillment process (validate → charge → reserve inventory → ship → notify) needs to compensate previous steps if a later step fails (e.g., refund if shipping fails). Which approach implements this saga pattern?

1. Lambda function chaining (each Lambda invokes the next)
2. Step Functions with Catch blocks that invoke compensation Lambdas
3. SQS with manual retry and DLQ
4. EventBridge choreography with each service emitting success/failure events

Question 4:

A Lambda function consuming from SQS occasionally fails on certain messages (malformed data). These messages are retried repeatedly, consuming concurrency and blocking other messages. How should this be resolved?

1. Increase Lambda timeout to give more processing time
2. Configure maxReceiveCount on the SQS queue with a DLQ — messages exceeding retry limit move to DLQ for investigation
3. Delete the malformed message in a try/catch block
4. Increase SQS visibility timeout to delay retries

Question 5:

A company uses EventBridge to route events from 20+ microservices. A bug in a consumer caused it to discard events for 3 hours before being discovered. They need to reprocess those lost events. Which EventBridge feature enables this?

1. EventBridge Pipes with enrichment
2. EventBridge Archive and Replay
3. EventBridge Schema Registry
4. CloudWatch Logs Insights query on EventBridge logs

Related Architecture Patterns

• SNS vs SQS vs EventBridge
• Kinesis vs MSK
• Container Platform (ECS/EKS)
• All Architecture Patterns – Hub

Related Posts

• SQS Standard vs FIFO – Differences, Ordering & When to Use
• AWS SQS Standard vs FIFO Queue
• AWS Kinesis Streams vs Firehose vs Managed Flink
• AWS Lambda Durable Functions
• AWS Lambda vs Step Functions vs EventBridge
• GenAI Application Architecture on AWS
• AWS Disaster Recovery Architecture
• Serverless API Architecture – API Gateway & Lambda

References

• AWS Event-Driven Architecture Overview
• Building an Event-Driven Application with Amazon EventBridge — AWS Compute Blog
• Let’s Architect: Designing Event-Driven Architectures — AWS Architecture Blog
• Event-Driven Architecture Pattern — AWS Prescriptive Guidance
• Implementing the Saga Pattern with AWS Step Functions — AWS Blog

📖 Related: ElastiCache Redis vs Memcached

Frequently Asked Questions

When should I use EventBridge vs SNS for fan-out?

Use SNS for simple fan-out where all subscribers get the same event (or basic attribute filtering). Use EventBridge when you need content-based filtering on any field in the event body, schema discovery, archive/replay, cross-account routing, or SaaS integration. EventBridge is more powerful; SNS is simpler and cheaper for basic pub/sub.

Should I use Step Functions or choreography (distributed events)?

Use Step Functions (orchestration) when you need clear visibility into workflow state, error handling with compensation (saga), and centralized control. Use choreography when services are independently developed/deployed by different teams and you want maximum autonomy. Orchestration is easier to debug; choreography scales organizational independence.

How do I handle poison messages in event-driven systems?

Configure a Dead Letter Queue (DLQ) with maxReceiveCount on SQS queues. After N failed processing attempts, the message moves to the DLQ. Set CloudWatch alarms on DLQ message count. Investigate and replay from DLQ after fixing the issue. For EventBridge, use Archive+Replay for recovery.

AWS Disaster Recovery Architecture — Overview

Disaster Recovery (DR) ensures business continuity when an entire region or infrastructure becomes unavailable. AWS offers four DR strategies with increasing cost and decreasing recovery time. Choosing the right strategy depends on your RTO (Recovery Time Objective) and RPO (Recovery Point Objective). This is heavily tested on SAP-C02 and DOP-C02.

Strategy Deep Dive

1. Backup & Restore

Approach: Data is backed up to a DR region. On disaster, restore data and rebuild infrastructure from templates.

• Data replication: S3 Cross-Region Replication, EBS snapshot copy, RDS automated backup copy, DynamoDB on-demand backup to another region
• Infrastructure: CloudFormation/CDK templates stored in S3 — deploy on failover
• Recovery process: Restore latest snapshot → Launch infrastructure from templates → Update DNS
• RTO: Hours (time to restore + launch + warm up)
• RPO: Hours (depends on backup frequency)
• Cost: Only storage costs in DR region during normal operation

2. Pilot Light

Approach: Core data layer is always replicated and running in DR. Compute and app tier are provisioned on failover.

• Always running: RDS Read Replica or Aurora Global Database secondary in DR region
• Ready to launch: AMIs pre-built, Launch Templates configured, ASG desired=0 (or minimal)
• Recovery process: Promote DB replica → Scale ASG to desired → Update DNS
• RTO: 10s of minutes (DB promotion + instance launch + health checks)
• RPO: Minutes (async replication lag)
• Key difference from Backup/Restore: Data is already there (no restore step)

3. Warm Standby

Approach: Full application stack runs in DR at reduced capacity. Scale up to production on failover.

• Always running: Full stack at minimum scale (e.g., 1 instance per tier instead of 10)
• DB: Aurora Global Database or RDS Multi-Region with synchronous or near-synchronous replication
• Recovery process: Scale up ASG/ECS → Promote DB (if needed) → Route 53 failover
• RTO: Minutes (just scaling, no provisioning from scratch)
• RPO: Seconds (continuous replication)
• Bonus: DR environment can serve read traffic or run batch jobs during normal ops (cost offset)

4. Multi-Site Active/Active

Approach: Full production capacity in multiple regions simultaneously serving traffic.

• Always running: Full production scale in 2+ regions
• Data: DynamoDB Global Tables (multi-master) or Aurora Global Database (single writer, fast failover)
• Routing: Route 53 latency-based or weighted routing distributes traffic across regions
• No failover: If one region fails, Route 53 health checks remove it — other region(s) absorb traffic
• RTO/RPO: Near zero — no recovery action needed
• Challenge: Data consistency, conflict resolution (DynamoDB uses last-writer-wins)

Key AWS Services for DR

Route 53 Failover Patterns

• Active-Passive (Failover): Primary record with health check → Secondary record (DR). Traffic goes to secondary only when primary fails. Used with Pilot Light/Warm Standby.
• Active-Active (Latency/Weighted): Both regions serve traffic simultaneously. Health checks remove unhealthy region. Used with Multi-Site.
• Health checks: HTTP/HTTPS endpoint checks, CloudWatch alarm-based checks, calculated checks (combine multiple)

RTO/RPO Selection Guide

DR Testing & Automation

• AWS Resilience Hub — Assess applications against RTO/RPO targets, identify gaps, generate recommendations
• AWS Fault Injection Service (FIS) — Simulate failures (AZ outage, instance termination) to validate DR readiness
• GameDay exercises — Regular scheduled failover drills to validate runbooks and team readiness
• Automated failover runbooks — Systems Manager Automation documents for repeatable DR procedures

Exam Tips by Certification

AWS Certification Exam Practice Questions

Question 1:

A company requires RTO of 15 minutes and RPO of 1 minute for their customer-facing application. They want to minimize costs while meeting these targets. Which DR strategy is MOST appropriate?

1. Backup & Restore
2. Pilot Light
3. Warm Standby
4. Multi-Site Active/Active

Question 2:

An application uses Aurora MySQL as its primary database. The DR strategy requires the database to fail over to another region in under 1 minute with minimal data loss. Which Aurora feature provides this?

1. Aurora Read Replica in another region with manual promotion
2. Aurora Global Database with managed planned/unplanned failover
3. RDS Multi-AZ with cross-region snapshot copy
4. Aurora Serverless with multi-region configuration

Question 3:

A global SaaS company needs zero-downtime even during a full region failure. Their application uses a NoSQL database. Users in multiple continents should always hit the closest region with read-write access. Which architecture achieves this?

1. Aurora Global Database with Route 53 latency-based routing
2. DynamoDB Global Tables with Route 53 latency-based routing
3. ElastiCache Global Datastore with CloudFront
4. RDS Multi-AZ in each region with cross-region read replicas

Question 4:

A company’s DR plan uses Pilot Light strategy. During a failover drill, they find that recovering takes 45 minutes instead of the expected 15 minutes. Most time is spent waiting for EC2 instances to launch and pass health checks. How should they reduce RTO?

1. Switch to Backup & Restore with faster snapshots
2. Pre-warm the load balancer and use pre-baked AMIs with reduced health check grace periods
3. Upgrade to Warm Standby with minimum-scale running instances
4. Use larger instance types for faster boot time

Question 5:

An architect wants to validate that their multi-region application can survive an AZ failure without manual intervention. Which AWS service allows them to safely simulate this in production?

1. AWS Config with remediation actions
2. AWS Fault Injection Service (FIS) with AZ disruption experiment
3. CloudWatch Synthetics with failure injection
4. AWS Systems Manager Automation with termination scripts

Related Architecture Patterns

• Hybrid Cloud Networking
• Multi-Account Architecture
• Event-Driven Serverless
• All Architecture Patterns – Hub

Frequently Asked Questions

What is the difference between RTO and RPO?

RTO (Recovery Time Objective) is the maximum acceptable time to restore service after a disaster — “how long can we be down?” RPO (Recovery Point Objective) is the maximum acceptable data loss measured in time — “how much data can we lose?” Lower values for both cost more to achieve.

Can I use Multi-AZ instead of multi-region for DR?

Multi-AZ protects against single AZ failures (hardware, networking) but NOT against region-wide events (which are rare but possible). For true DR against region failure, you need multi-region. Multi-AZ is high availability (HA), not disaster recovery (DR). Most production workloads need both.

What is AWS Elastic Disaster Recovery?

AWS Elastic Disaster Recovery (DRS) continuously replicates servers (block-level) to a staging area in your DR region. On failover, it launches fully provisioned servers from the latest replication point within minutes. It’s ideal for lift-and-shift workloads and Pilot Light/Warm Standby strategies where you need rapid server recovery.

Related Posts

• Global Traffic Management – Route 53, GA & CloudFront
• Multi-Region Active-Active Architecture
• Hybrid Cloud Networking