EFS vs FSx Decision Guide – Shared File Storage on AWS

AWS Shared File Storage — EFS vs FSx Decision Guide

Shared file storage appears in 51+ questions across SAA-C03 and SOA-C03. The exam tests when to use EFS (Linux NFS), which FSx variant (Windows/Lustre/ONTAP/OpenZFS), and performance class selection. This post covers the complete decision framework.

Shared File Storage — Decision Tree
What OS/protocol do your workloads need?
Linux (NFS)
Amazon EFS
Serverless, elastic
Multi-AZ by default
Lambda compatible
Lifecycle tiering
Windows (SMB)
FSx for Windows
NTFS, AD integration
DFS namespaces
Shadow copies
Multi-AZ HA
HPC / ML Training
FSx for Lustre
Sub-millisecond latency
100s GB/s throughput
S3-linked (lazy load)
Scratch or persistent
Multi-protocol (NFS+SMB)
FSx for ONTAP
NFS + SMB + iSCSI
NetApp features
Snapshots, cloning
Compression, dedup

Detailed Comparison

Feature EFS FSx Windows FSx Lustre FSx ONTAP
Protocol NFSv4 SMB POSIX (Lustre) NFS, SMB, iSCSI
OS Linux Windows Linux Linux + Windows
Capacity Elastic (auto-grows) Provisioned (32GB-64TB) Provisioned (1.2TB-PBs) Provisioned (auto-grows with tiering)
Throughput Up to 10+ GB/s (Elastic) Up to 2 GB/s 100s GB/s Up to 4 GB/s
Latency Low milliseconds Sub-millisecond (SSD) Sub-millisecond Sub-millisecond (SSD tier)
HA Multi-AZ (Regional) or One Zone Multi-AZ or Single-AZ Single-AZ (Persistent or Scratch) Multi-AZ
S3 integration No native link No Yes (S3-linked, lazy load) No native link
Best for Web serving, CMS, containers, Lambda .NET apps, SQL Server, Windows workloads HPC, ML training, video processing Multi-protocol, NetApp migration, DevOps

EFS Performance Classes

Mode Throughput Use Case
General Purpose Lowest latency (default) Web serving, CMS, home directories
Max I/O Higher aggregate throughput (higher latency) Big data, media processing, highly parallel (legacy — use Elastic)
Elastic Throughput Auto-scales up to 10+ GB/s (pay per use) Spiky workloads, unknown patterns (recommended for most)
Provisioned Throughput Fixed throughput regardless of data size Small datasets needing high throughput (predictable)

EFS Storage Classes & Lifecycle

  • Standard: Frequently accessed data. Multi-AZ durability.
  • Infrequent Access (IA): 92% cheaper storage, per-access retrieval fee. Auto-tiered via lifecycle policy.
  • One Zone: Single-AZ (20% cheaper than Standard). Good for dev/test or data that can be recreated.
  • One Zone-IA: Cheapest option. Single AZ + infrequent access pricing.
  • Lifecycle policy: Move files to IA after 7/14/30/60/90 days of no access. Can transition back on access.

FSx for Lustre — S3 Integration

  • S3-linked: FSx Lustre filesystem linked to S3 bucket. Data lazy-loaded on first access.
  • Scratch: Temporary, no replication. Highest performance. Use for short-term processing (ML training job).
  • Persistent: Data replicated within AZ. Use for longer-term workloads needing durability.
  • Write-back: Modified files automatically exported back to S3.
  • Pattern: S3 (durable storage) → FSx Lustre (high-performance processing) → results back to S3

Exam Tips

Exam Key Points
SAA-C03 “Linux shared file system” → EFS. “Windows file share with AD” → FSx for Windows. “HPC/ML high throughput” → FSx for Lustre. “Multi-protocol (NFS+SMB)” → FSx ONTAP. “Lambda needs shared storage” → EFS (only file system Lambda supports). “Reduce storage costs” → EFS lifecycle to IA. “S3 data for HPC processing” → FSx Lustre linked to S3. “Auto-growing” → EFS (elastic). “Migrate NetApp” → FSx ONTAP.

AWS Certification Exam Practice Questions

Question 1:

A company runs a content management system on multiple EC2 Linux instances behind an ALB. The instances need shared access to uploaded media files. The storage must auto-scale as content grows and support Multi-AZ for high availability. Which storage solution fits?

  1. Amazon EBS with Multi-Attach enabled
  2. Amazon EFS with Standard storage class (Regional)
  3. Amazon S3 with s3fs mount on each instance
  4. FSx for Lustre linked to an S3 bucket
Show Answer

Answer: B — EFS provides a shared NFS file system accessible from multiple EC2 instances simultaneously. Standard (Regional) storage class stores data redundantly across multiple AZs. Capacity auto-scales. EBS Multi-Attach (A) only works within a single AZ and requires cluster-aware applications. S3 (C) isn’t a POSIX file system. FSx Lustre (D) is overkill for a CMS.

Question 2:

A machine learning team needs to train models on a 10TB dataset stored in S3. Training jobs require sub-millisecond read latency and 50+ GB/s aggregate throughput across hundreds of GPU instances. Training runs last 3-4 hours. Which storage is optimal?

  1. EFS with Elastic Throughput mode
  2. FSx for Lustre (Scratch) linked to the S3 bucket
  3. EBS gp3 volumes attached to each instance with data copied from S3
  4. FSx for Windows File Server with SSD storage
Show Answer

Answer: B — FSx for Lustre provides sub-millisecond latency and hundreds of GB/s throughput — designed for HPC/ML. S3-linked means data is lazy-loaded from S3 on first access (no pre-copy needed). Scratch type is perfect for short training jobs (no replication needed, highest performance, cheapest). After training, results write back to S3. EFS (A) maxes at ~10 GB/s. EBS (C) requires copying to each instance individually.

Question 3:

A company is migrating their Windows file server to AWS. The file server uses NTFS permissions, DFS namespaces, and integrates with their Active Directory for access control. Which AWS service provides native support for all these features?

  1. Amazon EFS with POSIX permissions mapped to Windows
  2. Amazon FSx for Windows File Server with Active Directory integration
  3. Amazon S3 with IAM policies mimicking NTFS permissions
  4. FSx for ONTAP with SMB protocol
Show Answer

Answer: B — FSx for Windows is built on Windows Server and natively supports NTFS permissions, DFS namespaces, DFS replication, shadow copies, and Active Directory integration. It’s a drop-in replacement for on-premises Windows file servers. EFS (A) is NFS/Linux only. ONTAP (D) supports SMB but doesn’t have native Windows features like DFS namespaces.

Question 4:

A company stores 50TB in EFS but only 5TB is accessed regularly. They want to reduce costs without changing application behavior or access patterns. Which approach achieves the highest cost reduction?

  1. Switch to EFS One Zone storage class
  2. Enable EFS Intelligent-Tiering lifecycle policy — automatically moves files not accessed for 14 days to Infrequent Access (IA) storage class
  3. Move the entire EFS to S3 and use File Gateway
  4. Migrate to FSx for Lustre which is cheaper at scale
Show Answer

Answer: B — EFS lifecycle policy automatically transitions files not accessed for N days to IA class (92% cheaper per GB). Since only 5TB of 50TB is active, 45TB moves to IA — saving ~90% on that 45TB with zero application changes. Files automatically move back to Standard when accessed. One Zone (A) saves 20% but loses Multi-AZ resilience. S3 (C) requires application changes.

Question 5:

A company needs shared file storage accessible from both Linux and Windows instances simultaneously. They also need snapshot capabilities and data compression to reduce storage costs. Which service supports all requirements?

  1. EFS (supports Linux) + FSx for Windows (supports Windows) — two separate systems
  2. FSx for ONTAP — supports NFS (Linux), SMB (Windows), snapshots, and inline compression/deduplication
  3. S3 with separate mount tools for Linux and Windows
  4. EBS Multi-Attach with a cluster file system
Show Answer

Answer: B — FSx for ONTAP is the only AWS file service supporting NFS (Linux) + SMB (Windows) simultaneously on the same data. It also includes NetApp features: snapshots, FlexClone (instant copies), inline compression, and deduplication. Perfect for mixed-OS environments. Two separate systems (A) don’t share the same data. S3 (C) isn’t a file system.

Related Posts

References

Frequently Asked Questions

EFS vs FSx for ONTAP — both support NFS. Which should I choose?

EFS: Simpler, serverless (no capacity planning), auto-scales, cheaper for large elastic workloads, native Lambda support. FSx ONTAP: Multi-protocol (NFS+SMB+iSCSI), compression/dedup, NetApp features (FlexClone, SnapMirror), better for hybrid/on-prem integration. Choose EFS for pure Linux NFS with auto-scaling needs. Choose ONTAP when you need multi-protocol, compression, or NetApp-compatible features.

When is FSx for Lustre better than EFS?

When you need extreme throughput (100s GB/s) and sub-millisecond latency for parallel workloads: ML training, HPC simulations, video rendering. Also when data lives in S3 and you need a high-performance processing layer on top (S3-linked Lustre). EFS maxes at ~10 GB/s and has millisecond latency — fine for web/general purpose, not enough for HPC.

AWS Storage Gateway vs DataSync vs Snow – Hybrid Data Transfer Guide

AWS Storage Gateway & DataSync — Overview

AWS DataSync vs Storage Gateway — quick answer: Use DataSync for fast, one-time or scheduled data transfer/migration between on-premises (or other clouds) and AWS storage — it moves data and then you’re done. Use Storage Gateway for ongoing hybrid access, where on-premises applications need continuous, low-latency access to data backed by AWS (File, Volume, or Tape Gateway). In short: DataSync moves data; Storage Gateway gives on-prem apps persistent access to cloud storage.

Hybrid storage and data transfer is a core SAA-C03 topic appearing in 73+ questions. The key decision is: Storage Gateway (on-premises access to cloud storage) vs DataSync (one-time or scheduled data migration/sync). This post covers all gateway types, DataSync patterns, Snow Family decisions, and the Transfer Family for protocol-based access.

Hybrid Data Transfer — Decision Tree
What is your requirement?
On-prem apps need cloud storage
↓
Storage Gateway
NFS/SMB/iSCSI interface
Local cache + S3/EBS backend
Migrate/sync data to AWS
↓
DataSync
Agent-based transfer
NFS/SMB/HDFS → S3/EFS/FSx
Bulk offline transfer (10TB+)
↓
Snow Family
Snowball Edge (80TB)
Snowcone (14TB)
Snowmobile (100PB)
SFTP/FTP access to S3
↓
Transfer Family
Managed SFTP/FTPS/FTP
Direct to S3/EFS

Storage Gateway Types

Type Protocol Backend Use Case
S3 File Gateway NFS, SMB S3 (each file = S3 object) On-prem apps accessing S3 via file share. Data lake ingestion. Backup to S3.
FSx File Gateway SMB FSx for Windows Windows file share with local cache. Branch office access to central FSx.
Volume Gateway (Cached) iSCSI S3 (hot data cached locally) Block storage for apps. Primary data in S3, frequently accessed cached locally.
Volume Gateway (Stored) iSCSI Local (async backup to S3) Full dataset on-prem, asynchronous EBS snapshots to S3 for DR.
Tape Gateway iSCSI (VTL) S3 → Glacier/Deep Archive Replace physical tape libraries. Backup software unchanged.

Storage Gateway vs DataSync — Decision

Feature Storage Gateway DataSync
Purpose Ongoing hybrid access (on-prem apps use cloud storage) Data movement/migration (copy data from A to B)
Access pattern Continuous read/write from on-premises applications One-time migration or scheduled sync (not continuous access)
Local cache Yes (low-latency access to frequently used data) No (agent transfers data, doesn’t provide access)
Bandwidth Throttled to not saturate link Maximizes bandwidth (10x faster than open-source tools)
Destinations S3, FSx, EBS Snapshots, Glacier S3, EFS, FSx (all types), Snow, between AWS storage
Exam answer “On-prem app needs to read/write S3 as NFS” → File Gateway “Migrate NAS to EFS” or “daily sync to S3” → DataSync

DataSync — Key Features

  • Agent: Deploy on-premises (VMware/Hyper-V/EC2) to connect to source storage
  • Sources: NFS, SMB, HDFS, self-managed object storage, S3-compatible
  • Destinations: S3 (all classes), EFS, FSx (Windows/Lustre/ONTAP/OpenZFS)
  • Scheduling: One-time or recurring (hourly, daily, weekly)
  • Incremental: Only transfers changed files (compares metadata)
  • Bandwidth throttling: Configurable to avoid saturating network links
  • Between AWS: Can sync between AWS services (S3 → EFS, cross-region S3 → S3)
  • Verification: Data integrity verification after transfer

Snow Family — When Network Is Not Enough

Device Capacity Use Case
Snowcone 8-14 TB (HDD/SSD) Edge computing, small data transfers, IoT collection
Snowball Edge Storage 80 TB Large data migration when network too slow. Compute available.
Snowball Edge Compute 80 TB + GPU Edge ML inference, video processing + data transfer
Snowmobile 100 PB Exabyte-scale data center migration (shipping container)

Decision rule: Calculate transfer time. If network transfer takes > 1 week, use Snow Family. Formula: DataSize(GB) × 8 / BandwidthMbps / 86400 = days.

Transfer Family

  • What: Managed SFTP, FTPS, FTP, and AS2 servers that store data directly in S3 or EFS
  • Use case: Partners/vendors who require SFTP to send/receive files. No changes to their workflow.
  • Authentication: AWS Directory Service, custom Lambda authorizer, or service-managed users
  • Exam note: “Third-party partners upload files via SFTP to S3” → Transfer Family

Exam Tips

Exam Key Points
SAA-C03 “On-prem app needs NFS access to S3” → S3 File Gateway. “Migrate file server to AWS” → DataSync → EFS/FSx. “Replace tape backups” → Tape Gateway. “80TB limited bandwidth” → Snowball Edge. “SFTP to S3” → Transfer Family. “Low-latency local access + cloud backup” → Volume Gateway Cached. “Full data on-prem + DR snapshots” → Volume Gateway Stored. “Daily sync NFS to S3” → DataSync with schedule.

AWS Certification Exam Practice Questions

Question 1:

A company’s on-premises applications access files via NFS. They want to store this data in S3 for durability and cost savings, but applications must continue using NFS without modification. Which solution provides this?

  1. AWS DataSync to copy files to S3 on a schedule
  2. AWS S3 File Gateway presenting S3 as an NFS mount point with local caching
  3. Mount S3 directly using s3fs-fuse on Linux
  4. AWS Transfer Family with NFS protocol
Show Answer

Answer: B — S3 File Gateway provides an NFS/SMB interface that applications use without modification. Files written to the gateway are stored as S3 objects. A local cache provides low-latency access to recently used data. DataSync (A) copies data but doesn’t provide ongoing NFS access. s3fs (C) is unreliable and not recommended. Transfer Family (D) doesn’t support NFS.

Question 2:

A company needs to migrate 50TB from their on-premises NAS (NFS) to Amazon EFS. Their internet connection is 1 Gbps. They want the migration completed within 1 week with minimal disruption. Which approach is fastest?

  1. AWS Snowball Edge — ship device, load data, ship back
  2. AWS DataSync agent on-premises → EFS over Direct Connect or internet (transfers at near line speed)
  3. S3 File Gateway — let it sync over time
  4. rsync over SSH to an EC2 instance with EFS mounted
Show Answer

Answer: B — At 1 Gbps, 50TB takes approximately 4.6 days (50,000 GB × 8 / 1000 Mbps / 86400 = 4.6 days). This fits within 1 week over the network. DataSync maximizes bandwidth utilization (up to 10 Gbps), handles incremental transfer, and integrates directly with EFS. Snowball (A) takes 5-7 days for shipping alone. DataSync is the fastest when network bandwidth is sufficient.

Question 3:

A company’s backup software writes to a tape library using iSCSI VTL interface. They want to eliminate physical tapes and store backups in AWS at the lowest long-term cost. The backup software cannot be modified. Which solution fits?

  1. S3 File Gateway with lifecycle policy to Glacier
  2. Tape Gateway — presents virtual tapes via iSCSI VTL, archives to S3 Glacier Deep Archive
  3. DataSync scheduled backup to S3 Glacier
  4. AWS Backup with custom vault in Glacier
Show Answer

Answer: B — Tape Gateway is a virtual tape library (VTL) that presents iSCSI targets to backup software. The software sees virtual tapes — no modification needed. When tapes are ejected/archived, they move to S3 Glacier or Deep Archive (lowest cost). File Gateway (A) would require changing the backup software from tape to NFS. This is the standard tape replacement pattern.

Question 4:

A company needs to transfer 200TB of data to S3. Their internet bandwidth is 100 Mbps. Transfer would take approximately 185 days over the network. Which approach completes the transfer fastest?

  1. Provision AWS Direct Connect (10 Gbps) and use DataSync
  2. Order multiple Snowball Edge devices (80TB each), load in parallel, ship to AWS
  3. Use S3 Transfer Acceleration with multipart upload
  4. Increase internet bandwidth to 1 Gbps and use DataSync
Show Answer

Answer: B — At 100 Mbps, network transfer is impractical (185 days). Direct Connect (A) takes weeks to provision. Order 3 Snowball Edge devices (80TB each), load them in parallel (~2-3 days to load each), ship to AWS (~5-7 days). Total time: ~2 weeks vs 6+ months over network. This is the textbook “when to use Snow” scenario. Transfer Acceleration (C) still limited by 100 Mbps bandwidth.

Question 5:

A company’s partners upload daily files via SFTP. Currently this goes to an on-premises server. The company wants to move to AWS with minimal partner disruption — partners must continue using their existing SFTP clients and credentials. Files should land in S3. Which service provides this?

  1. EC2 instance running OpenSSH SFTP server with S3 mounted via s3fs
  2. AWS Transfer Family with SFTP protocol, configured to store files in S3
  3. S3 File Gateway with SFTP enabled
  4. API Gateway with a custom SFTP-to-S3 Lambda function
Show Answer

Answer: B — Transfer Family provides a fully managed SFTP server that stores files directly in S3. Partners connect to the same protocol (SFTP) with custom hostname. You can use existing SSH keys or passwords. No infrastructure to manage. File Gateway (C) doesn’t support SFTP protocol. EC2 SFTP (A) works but is self-managed (patching, scaling, HA).

Related Posts

References

Frequently Asked Questions

Storage Gateway vs DataSync — which do I need?

Storage Gateway: When on-premises applications need ongoing access to cloud storage (NFS/SMB/iSCSI interface). It’s a persistent access point. DataSync: When you need to move or synchronize data between locations (migration, backup, replication). It’s a transfer tool. If apps need to read/write → Gateway. If you need to copy data → DataSync.

When should I use Snow Family vs DataSync?

Calculate network transfer time: DataSize(GB) × 8 ÷ BandwidthMbps ÷ 86400 = days. If transfer takes more than 1 week, consider Snow Family. Typical break-even: 10-50TB at 100 Mbps → borderline. 100TB+ at 100 Mbps → definitely Snow. Also consider: ongoing costs of higher bandwidth vs one-time Snow device rental.

What is the difference between Volume Gateway Cached vs Stored?

Cached: Primary data lives in S3, local cache stores frequently accessed data. Best when dataset is too large for local storage. Stored: Full dataset lives locally, asynchronous snapshots uploaded to S3. Best when you need low-latency access to entire dataset and S3 is just for backup/DR. Cached saves local storage; Stored provides better local performance.

GenAI Observability & Evaluation – Monitoring, LLM-as-Judge & Testing

GenAI Observability & Evaluation — Overview

Monitoring and evaluation are tested in AIP-C01 Domains 4 & 5 (23% combined). The exam tests FM-specific observability (token usage, latency, model drift), evaluation methods (automated metrics, LLM-as-Judge, human evaluation), and continuous testing patterns.

GenAI Observability Stack
Metrics (CloudWatch)
Token usage (in/out)
Latency (TTFT, TPS)
Throttling rate
Error rate
Cost per request
Tracing (X-Ray)
End-to-end request flow
RAG retrieval time
Agent reasoning steps
Tool call duration
Service map
Logging (CW Logs)
Prompt/response pairs
Guardrail decisions
Error details
Model invocation logs
Bedrock model invocation logging
Evaluation
Automated metrics (BLEU, ROUGE)
LLM-as-Judge (Bedrock)
Human evaluation
A/B testing
Regression testing

SageMaker Clarify for FM Evaluation

  • Automated FM Evaluation — Evaluate foundation models for accuracy, robustness, toxicity, and factual consistency using built-in benchmark datasets.
  • Model Comparison — Compare multiple FMs (from JumpStart or Bedrock) side-by-side on the same evaluation criteria to select the best fit.
  • Custom Evaluation Criteria — Define domain-specific evaluation metrics beyond standard benchmarks (e.g., certification-specific accuracy).
  • Human Evaluation Workflows — Integrate human reviewers via SageMaker Ground Truth for subjective quality assessment.
  • Bias Detection in FMs — Detect bias in model outputs across demographic groups, including stereotyping, toxicity, and representational harms.
  • Explainability for FM Responses — Token-level attribution showing which parts of the prompt influenced specific output segments.
  • Continuous Monitoring — Integrate with Model Monitor for ongoing evaluation of deployed FM endpoints (prompt drift, output quality degradation).

Key Metrics for GenAI Applications

Metric What It Measures Why It Matters
Time to First Token (TTFT) Time from request to first output token User-perceived responsiveness
Tokens Per Second (TPS) Output generation speed Streaming quality, throughput capacity
Input/Output Tokens Token counts per request Cost tracking, context window usage
Invocation Count Number of FM API calls Usage patterns, scaling needs
Guardrail Intervention Rate % of requests blocked/modified by guardrails Safety compliance, guardrail tuning
RAG Retrieval Relevance How relevant are retrieved chunks (custom metric) Knowledge base quality, chunking effectiveness

Model Evaluation Methods

Method How Best For
Automated Metrics BLEU, ROUGE, BERTScore — compare output to reference Summarization, translation (reference-based tasks)
LLM-as-Judge (Bedrock) Use a powerful FM to evaluate another FM’s output (coherence, relevance, safety) Open-ended generation, quality scoring at scale
Human Evaluation Domain experts rate responses (SageMaker Ground Truth) Final quality validation, subjective quality
A/B Testing Route % of traffic to new model/prompt, compare metrics Production validation of changes
Regression Testing Run fixed test suite on every change, compare to baseline Prevent quality degradation during updates

Bedrock Model Invocation Logging

  • Enable: Bedrock settings → Model invocation logging → S3 and/or CloudWatch Logs
  • Captures: Full prompt, full response, model ID, token counts, latency, request metadata
  • Use for: Debugging, compliance audit, prompt regression detection, cost attribution
  • Privacy: Can contain PII — ensure encryption (KMS), access control, retention policies

X-Ray Tracing for GenAI

  • End-to-end trace: User request → API Gateway → Lambda → Bedrock API → response
  • Subsegments: RAG retrieval time, agent reasoning loops, tool call duration, guardrail processing
  • Service map: Visualize dependencies between GenAI components
  • Annotations: Tag traces with model ID, prompt template version, user segment for filtering

Exam Tips

Exam Key Points
AIP-C01 “Evaluate FM quality at scale” → LLM-as-Judge (Bedrock evaluation). “Compare output to reference” → BLEU/ROUGE. “Track token costs” → CloudWatch metrics + Bedrock invocation logging. “Debug agent reasoning” → Bedrock agent trace + X-Ray. “Detect quality regression” → automated test suite + regression testing. “Monitor for drift” → custom CloudWatch metrics + alerting.

AWS Certification Exam Practice Questions

Question 1:

A company needs to evaluate the quality of their GenAI chatbot’s responses at scale (1000+ responses daily). Human reviewers can only check 50 per day. Which approach provides comprehensive quality assessment?

  1. Only evaluate the 50 human-reviewed responses and extrapolate
  2. Use Bedrock model evaluation with LLM-as-Judge to automatically score all responses on coherence, relevance, and helpfulness
  3. Count the number of tokens in each response as a quality proxy
  4. Use BLEU score for all responses
Show Answer

Answer: B — LLM-as-Judge uses a powerful FM (like Claude) to evaluate another FM’s outputs against criteria you define (coherence, relevance, helpfulness, safety). It scales to all responses without human bottleneck. Correlates well with human judgment for most criteria. Use human review (A) for calibration and edge cases. BLEU (D) requires reference answers and doesn’t work for open-ended responses.

Question 2:

After updating a prompt template, a company notices their chatbot’s responses have degraded for certain query types. They need to detect such regressions automatically before deploying prompt changes. Which approach provides this?

  1. A/B test every prompt change with 50% of production traffic
  2. Maintain a regression test suite of queries with expected outputs, run automatically on every prompt change, alert if scores drop below threshold
  3. Monitor token output length — shorter responses indicate regression
  4. Wait for user complaints to identify issues
Show Answer

Answer: B — A regression test suite with curated query-response pairs catches quality drops before production. Run it in CI/CD pipeline: new prompt → run test suite → score with LLM-as-Judge or similarity metrics → gate deployment if scores drop. This is proactive (catches issues before users see them). A/B testing (A) is for production validation, not pre-deployment prevention. User complaints (D) are too late.

Question 3:

A development team needs to debug why their Bedrock Agent sometimes takes 30+ seconds to respond. The response eventually works but is too slow. Which observability tool shows where time is being spent?

  1. CloudWatch Logs Insights querying for slow requests
  2. AWS X-Ray tracing showing subsegments for each agent step (FM call, tool invocation, knowledge base retrieval)
  3. Bedrock console metrics dashboard
  4. CloudTrail showing API call sequence
Show Answer

Answer: B — X-Ray traces show the timing breakdown of each component: how long the FM reasoning took, how long each tool/action group Lambda ran, how long the knowledge base retrieval took. You can identify the bottleneck (e.g., one tool call taking 20s) and optimize specifically. CloudWatch metrics (C) show averages, not per-request breakdown. CloudTrail (D) shows API calls but not internal agent reasoning steps.

Related Posts

References

Frequently Asked Questions

What is LLM-as-Judge?

A technique where a powerful FM evaluates another FM’s outputs against defined criteria (relevance, coherence, safety, helpfulness). You provide the evaluation prompt (rubric), the original question, and the FM’s response. The judge FM scores it. Bedrock supports this natively in model evaluation. It scales to thousands of evaluations per hour without human reviewers.

Which metrics should I monitor for a GenAI chatbot?

Essential: (1) Latency — TTFT and total response time. (2) Token usage — input/output per request (cost tracking). (3) Error/throttle rate — availability. (4) Guardrail intervention rate — safety. (5) User satisfaction — thumbs up/down if available. (6) Retrieval relevance — for RAG applications. Create CloudWatch dashboard combining all six.

AWS Network Firewall & Traffic Inspection – IDS/IPS, TLS & GWLB

AWS Network Firewall & Traffic Inspection — Overview

Network Firewall covers the “infrastructure security” domain of SCS-C03 (18% of exam). Questions test deep packet inspection, North-South vs East-West traffic patterns, centralized firewall deployment with Transit Gateway, and integration with third-party IDS/IPS tools via Traffic Mirroring.

Centralized Inspection Architecture (Transit Gateway)
Spoke VPC A
(Workload)
Spoke VPC B
(Workload)
Spoke VPC C
(Workload)
↕ ↕ ↕
Transit Gateway
Route tables route ALL traffic through Inspection VPC before reaching destination
↕
Inspection VPC (Network Firewall)
Stateful Rules
IDS/IPS signatures
Domain filtering
Protocol detection
Stateless Rules
IP allow/deny
Port filtering
Protocol matching
TLS Inspection
Decrypt → inspect → re-encrypt
ACM certificate
Exempt trusted domains
↕
Internet Gateway
(North-South)
On-Premises
(VPN/DX)

AWS Network Firewall — Features

Feature Details
Stateless rules Evaluated first. Match on IP, port, protocol. Actions: pass, drop, forward to stateful engine. Like NACLs but more powerful.
Stateful rules Deep packet inspection. Suricata-compatible IDS/IPS signatures. Domain list filtering. Protocol detection (HTTP, TLS, DNS).
TLS inspection Decrypt HTTPS traffic, inspect, re-encrypt. Uses ACM certificate. Can exempt specific domains (banking, healthcare).
Domain filtering Allow/deny traffic to specific domains (e.g., allow only *.amazonaws.com). Works with HTTP Host header or TLS SNI.
Managed rule groups AWS-managed threat intelligence feeds. Block known malicious IPs/domains automatically.
Logging Flow logs + alert logs → S3, CloudWatch, Kinesis Firehose. See which rules matched.

North-South vs East-West Traffic

Direction Definition Inspection Options
North-South Traffic entering/leaving VPC (internet, on-premises) Network Firewall in Inspection VPC, WAF on ALB/CloudFront, Security Groups
East-West Traffic between VPCs, between subnets, between services Network Firewall via TGW routing, Security Groups, VPC Lattice service policies

Deployment Patterns

Pattern 1: Centralized Inspection (TGW)

  • Single Inspection VPC with Network Firewall
  • TGW route tables force ALL inter-VPC and internet-bound traffic through the Inspection VPC
  • Best for: Multi-account environments needing consistent inspection
  • Managed by: Central security team via Firewall Manager

Pattern 2: Distributed (Per-VPC)

  • Network Firewall endpoints in each VPC
  • VPC route tables direct traffic through firewall endpoints
  • Best for: Single-account or when latency-sensitive (avoids TGW hop)

Pattern 3: Gateway Load Balancer (Third-Party)

  • GWLB distributes traffic to third-party firewall appliances (Palo Alto, Fortinet, Check Point)
  • Transparent inspection — traffic flows through appliance without source IP change
  • Best for: Organizations with existing third-party IDS/IPS investments

VPC Traffic Mirroring

  • What: Copy network traffic from ENIs to monitoring targets (out-of-band inspection)
  • Use case: IDS/IPS that needs to see raw packets but shouldn’t be inline (passive monitoring)
  • Targets: NLB (distributes mirrored traffic to monitoring fleet) or another ENI
  • Filters: Mirror only specific traffic (source/dest IPs, ports, protocols)
  • Limitation: Not supported on all instance types (requires Nitro). Additional network bandwidth cost.
  • Exam note: “Passive inspection without affecting traffic flow” → Traffic Mirroring. “Inline inspection” → Network Firewall or GWLB.

Network Firewall vs Security Groups vs NACLs vs WAF

Control Layer Inspection Depth Use
Security Groups Instance (ENI) IP/Port only (stateful) Per-instance access control
NACLs Subnet IP/Port only (stateless) Subnet-level deny rules
Network Firewall VPC Deep packet (L3-L7, IDS/IPS, domain, TLS) Centralized inspection, compliance
WAF Application (L7) HTTP request inspection (headers, body, URI) Web application protection (SQLi, XSS)

Exam Tips

Exam Key Points
SCS-C03 “Deep packet inspection” → Network Firewall (stateful rules). “Domain filtering” → Network Firewall (allow list). “IDS/IPS signatures” → Network Firewall (Suricata rules). “Third-party firewall appliance” → Gateway Load Balancer. “Passive monitoring without inline” → VPC Traffic Mirroring. “Inspect encrypted traffic” → Network Firewall TLS inspection. “Centralized inspection across VPCs” → TGW + Inspection VPC pattern.

AWS Certification Exam Practice Questions

Question 1:

A company needs to inspect all traffic between VPCs (East-West) for malicious patterns using IDS/IPS signatures. They have 20 spoke VPCs connected via Transit Gateway. Which architecture provides centralized inspection?

  1. Deploy Network Firewall in each spoke VPC
  2. Create a dedicated Inspection VPC with Network Firewall, configure TGW route tables to route all inter-VPC traffic through it
  3. Use Security Groups with deny rules between VPCs
  4. Enable VPC Flow Logs and analyze with GuardDuty
Show Answer

Answer: B — The centralized inspection pattern: Inspection VPC hosts Network Firewall with IDS/IPS rules. TGW route tables direct all inter-VPC traffic through the Inspection VPC before reaching the destination. This provides single-pane management and consistent policy. Per-VPC deployment (A) is costly and hard to manage at 20 VPCs. Security Groups (C) can’t do deep packet inspection. GuardDuty (D) detects threats but doesn’t inspect inline traffic.

Question 2:

A security team needs to allow EC2 instances to access only specific approved domains (e.g., *.github.com, *.amazonaws.com) and block all other outbound internet traffic. Which service provides this domain-based filtering?

  1. Security Groups with domain names in rules
  2. AWS Network Firewall with stateful domain list rules
  3. Route 53 Resolver DNS Firewall with block rules
  4. NACLs with domain-based rules
Show Answer

Answer: B — Network Firewall stateful rules can filter by domain (using HTTP Host header for HTTP or TLS SNI for HTTPS). You create an allow list of approved domains and set default action to drop. Security Groups (A) and NACLs (D) only work with IPs, not domains. DNS Firewall (C) blocks DNS resolution but doesn’t prevent direct IP access — the instance could bypass it by using IP addresses directly.

Question 3:

A company uses third-party Palo Alto firewall appliances for deep inspection. They want to route VPC traffic through these appliances transparently without changing source/destination IPs. Which AWS service enables this?

  1. Network Load Balancer in front of firewall instances
  2. Gateway Load Balancer (GWLB) with GENEVE encapsulation
  3. ALB with forwarding rules to firewall targets
  4. Transit Gateway with static routes to firewall instances
Show Answer

Answer: B — Gateway Load Balancer uses GENEVE encapsulation to transparently insert third-party appliances into the traffic path. Traffic flows through the appliance with original source/destination IPs preserved (bumps-in-the-wire). GWLB handles scaling, HA, and load distribution across appliance fleet. NLB (A) would change the destination IP. TGW (D) requires complex routing and doesn’t provide appliance load balancing.

Question 4:

A security team needs to passively monitor network traffic on specific EC2 instances for forensic analysis without affecting application performance or traffic flow. Which approach achieves this?

  1. Deploy Network Firewall inline with alerting-only mode
  2. Configure VPC Traffic Mirroring from the instance ENIs to a monitoring NLB target
  3. Enable enhanced VPC Flow Logs with packet capture
  4. Install tcpdump on each instance and send to S3
Show Answer

Answer: B — VPC Traffic Mirroring copies network packets (out-of-band) to a monitoring target without affecting the original traffic flow or adding latency. NLB distributes mirrored traffic to a fleet of monitoring/IDS tools. VPC Flow Logs (C) capture metadata only (IPs, ports), not packet content. Network Firewall (A) is inline (adds latency). tcpdump (D) consumes instance resources and doesn’t scale.

Question 5:

A company’s compliance requires inspecting HTTPS traffic for data exfiltration. They need to decrypt outbound TLS, inspect the content, then re-encrypt before forwarding. Certain financial and healthcare domains must be exempted from inspection. Which solution provides this?

  1. CloudFront with Lambda@Edge inspecting request bodies
  2. AWS Network Firewall with TLS inspection policy and domain exception list
  3. WAF with body inspection rules on all outbound traffic
  4. Install proxy servers (Squid) on EC2 instances with SSL bump
Show Answer

Answer: B — Network Firewall TLS inspection decrypts outbound HTTPS traffic using an ACM certificate, inspects the decrypted content with stateful rules, then re-encrypts before forwarding. You can configure exception domains (bypass inspection for banking/healthcare). This is the managed AWS solution for TLS inspection. WAF (C) only works on inbound HTTP at ALB/CloudFront, not outbound. Squid (D) works but is self-managed overhead.

Related Posts

References

Frequently Asked Questions

Network Firewall vs WAF — when to use which?

Network Firewall: Inspects all network traffic (any protocol, any direction). Works at VPC level. Use for IDS/IPS, domain filtering, TLS inspection, East-West traffic. WAF: Inspects HTTP/HTTPS requests only. Works at ALB/CloudFront/API Gateway. Use for web application attacks (SQLi, XSS, bot control). Most architectures need both: WAF for web-layer protection, Network Firewall for network-layer inspection.

What is Gateway Load Balancer used for?

GWLB transparently inserts third-party network appliances (Palo Alto, Fortinet, Check Point) into your traffic path. It handles scaling, HA, and traffic distribution across appliance fleet. Traffic passes through appliances with original source/destination IPs preserved (GENEVE encapsulation). Use when you have existing third-party security tools or need features not available in AWS Network Firewall.

Can Network Firewall inspect encrypted (HTTPS) traffic?

Yes — Network Firewall supports TLS inspection. It decrypts traffic using an ACM certificate, inspects the decrypted content with your stateful rules, then re-encrypts before forwarding. You can exempt specific domains from inspection (compliance requirement for financial/healthcare traffic). Without TLS inspection, Network Firewall can still filter by TLS SNI (domain name) but cannot inspect the encrypted payload.

AWS Secrets & Certificate Management – Secrets Manager, ACM & Rotation Patterns

AWS Secrets & Certificate Management — Overview

Secrets management appears in 81+ questions across SCS-C03 (Data Protection) and SAP-C02/DOP-C02. The core decisions are: Secrets Manager vs Parameter Store (when to use which), automatic rotation patterns, ACM certificate management, and mTLS enforcement. This post covers all patterns exam questions test.

Secrets Manager vs Parameter Store — Decision
AWS Secrets Manager
✅ Built-in rotation (Lambda)
✅ RDS/Redshift/DocumentDB native rotation
✅ Cross-account access via resource policy
✅ Automatic versioning (AWSCURRENT/AWSPREVIOUS)
✅ Random password generation
💰 $0.40/secret/month + $0.05/10K API calls
Best: DB credentials, API keys needing rotation
SSM Parameter Store
✅ Free tier (Standard parameters)
✅ Hierarchical paths (/app/prod/db/password)
✅ SecureString (KMS encrypted)
✅ Change notifications (EventBridge)
❌ No built-in rotation
💰 Free (Standard) / $0.05/10K (Advanced)
Best: Config values, feature flags, non-rotating secrets
Rule of thumb: Need automatic rotation? → Secrets Manager. Non-sensitive config or tight budget? → Parameter Store. Can reference Secrets Manager secrets FROM Parameter Store path: /aws/reference/secretsmanager/my-secret

Detailed Comparison

Feature Secrets Manager Parameter Store
Rotation Built-in with Lambda (native for RDS/Redshift/DocumentDB) Not built-in (must implement yourself)
Cross-account Yes (resource policy on secret) No resource policy (must use cross-account IAM role)
Encryption Always encrypted (KMS required) Optional (String vs SecureString)
Size limit 64 KB per secret 4 KB (Standard) / 8 KB (Advanced)
Versioning Automatic (AWSCURRENT, AWSPREVIOUS, AWSPENDING) Labels on parameter versions
Throughput 10,000 TPS 1,000 TPS (Standard) / 10,000 (Advanced)
CloudFormation Dynamic references resolve at deploy time Dynamic references resolve at deploy time

Secrets Rotation — How It Works

Secrets Manager rotation uses a Lambda function that executes 4 steps:

  1. createSecret: Generate new credentials, store as AWSPENDING version
  2. setSecret: Update the database/service with the new credentials
  3. testSecret: Verify the new credentials work (connect to DB)
  4. finishSecret: Move AWSPENDING → AWSCURRENT, old current → AWSPREVIOUS

Rotation Strategies

Strategy How Downtime Risk
Single user Change password of the same user Brief — between password change and app refresh
Alternating users Two users (user_1, user_2). Alternate which is active. Zero — one user always works while the other is being rotated

AWS Certificate Manager (ACM)

Feature ACM Public Certificates ACM Private CA
Cost Free $400/month per CA + per-certificate fee
Validation DNS or Email validation No external validation needed
Renewal Automatic (DNS-validated certs auto-renew) Automatic (configurable validity)
Export private key No (cannot export) Yes (can export for on-premises use)
Use with ELB, CloudFront, API Gateway, Amplify ELB, CloudFront, API Gateway, EC2, on-premises, IoT
Use case Public-facing HTTPS websites/APIs Internal services, mTLS, IoT devices, code signing

mTLS (Mutual TLS) Patterns

  • API Gateway + mTLS: Configure custom domain with mutual TLS. Upload truststore (CA bundle) to S3. Clients present certificate signed by your CA.
  • ALB + mTLS: ALB verifies client certificates. Configure trust store with your CA. Supports certificate revocation (CRL/OCSP).
  • Service Mesh (App Mesh): Envoy proxies handle mTLS between microservices automatically. ACM Private CA issues short-lived certificates.
  • Exam note: “Verify client identity at API level” → mTLS. “Verify client identity at network level” → VPN with certificate auth.

Integration Patterns

  • RDS + Secrets Manager: Native rotation for MySQL, PostgreSQL, Oracle, SQL Server, MariaDB. Secrets Manager auto-manages the DB password.
  • Lambda + Secrets Manager: Cache secrets using AWS Parameters and Secrets Lambda Extension (reduces API calls, adds caching layer).
  • ECS + Secrets Manager: Reference secrets in task definition as environment variables. ECS agent fetches at container start.
  • CloudFormation + Secrets Manager: Generate random password at deploy: {{resolve:secretsmanager:my-secret:SecretString:password}}
  • CodePipeline/CodeBuild: Reference Parameter Store/Secrets Manager for build secrets. Never hardcode in buildspec.

Exam Tips

Exam Key Points
SCS-C03 “Automatic rotation of DB credentials” → Secrets Manager. “Free config storage” → Parameter Store (Standard). “Cross-account secret access” → Secrets Manager resource policy. “mTLS for API” → API Gateway custom domain + truststore. “Internal certificates for microservices” → ACM Private CA. “Cannot export private key” → ACM Public (use Private CA if export needed). “Alternating users” = zero-downtime rotation.

AWS Certification Exam Practice Questions

Question 1:

A company’s application connects to an RDS MySQL database using hardcoded credentials in the application configuration file. The security team requires automatic credential rotation every 30 days without application downtime. Which solution meets these requirements with the LEAST development effort?

  1. Store credentials in SSM Parameter Store SecureString, write a Lambda function to rotate the DB password and update the parameter every 30 days
  2. Enable Secrets Manager with native RDS rotation using the alternating users strategy, update application to retrieve credentials from Secrets Manager at runtime
  3. Use IAM database authentication instead of passwords
  4. Store credentials in a KMS-encrypted S3 file, rotate manually every 30 days
Show Answer

Answer: B — Secrets Manager provides native RDS rotation with pre-built Lambda functions for MySQL (zero development effort for the rotation logic). Alternating users strategy ensures zero downtime — one user is always valid while the other rotates. The application calls Secrets Manager API at startup/periodically to get current credentials. Parameter Store (A) requires you to write the rotation Lambda yourself. IAM auth (C) has connection limits and doesn’t work for all DB engines/configurations.

Question 2:

Multiple AWS accounts in an Organization need to access a shared database credential stored in a central security account. The credential must be accessible without creating IAM users or access keys in the security account. Which approach enables this?

  1. Store in Parameter Store and share via RAM
  2. Store in Secrets Manager and add a resource policy allowing the member accounts’ roles to retrieve it
  3. Replicate the secret to each account using Secrets Manager multi-Region replication
  4. Store in S3 with a bucket policy allowing cross-account access
Show Answer

Answer: B — Secrets Manager supports resource policies (like S3 bucket policies). Add a policy allowing specific IAM roles in member accounts to call secretsmanager:GetSecretValue. The member account role assumes its own role and directly accesses the secret cross-account — no credentials needed in the security account. Parameter Store (A) doesn’t support resource policies or RAM sharing. Multi-region replication (C) is for HA, not cross-account sharing.

Question 3:

A company needs to issue short-lived certificates for internal microservices running on ECS. The certificates must be automatically rotated, and the private keys must be exportable so the application can use them directly. Public CAs should NOT be involved. Which service provides this?

  1. ACM public certificates with auto-renewal
  2. ACM Private CA issuing short-lived certificates (configured with 1-7 day validity)
  3. Self-signed certificates generated by a Lambda function
  4. Let’s Encrypt certificates with certbot automation
Show Answer

Answer: B — ACM Private CA creates your own internal CA. You can issue short-lived certificates (hours to days) for service-to-service mTLS. Private keys are exportable (unlike ACM public certificates). No public CA involved — fully private. Works with ECS, EKS, EC2, App Mesh. Self-signed (C) doesn’t provide centralized management or revocation. Let’s Encrypt (D) is public and has rate limits.

Question 4:

A security engineer discovers that application developers are storing database passwords in Lambda environment variables (visible in the console). They need a solution that encrypts secrets at rest, restricts access via IAM, and allows the Lambda function to retrieve the secret without code changes to the environment variable approach. Which solution achieves this?

  1. Encrypt environment variables using a KMS key and grant Lambda’s execution role kms:Decrypt
  2. Store secrets in Secrets Manager, reference them in Lambda environment variables using dynamic resolution
  3. Use the AWS Parameters and Secrets Lambda Extension to cache Secrets Manager values, update code to read from extension cache
  4. Store secrets in S3 encrypted with KMS, have Lambda download at startup
Show Answer

Answer: A — Lambda environment variables can be encrypted with a KMS key. The values appear encrypted in the console (not visible). The Lambda execution role needs kms:Decrypt permission. At runtime, Lambda automatically decrypts the environment variables — no code changes needed. This is the “without code changes” approach. Secrets Manager (B, C) is better long-term but requires code changes. The extension (C) requires reading from a different source.

Question 5:

A company requires that their API Gateway verifies the identity of each calling client using certificates (not just API keys or tokens). Clients must present a certificate issued by the company’s internal CA. How should this be configured?

  1. Configure API Gateway with a Lambda authorizer that validates certificate headers
  2. Configure a custom domain on API Gateway with mutual TLS enabled, upload the company’s CA certificate bundle as a truststore to S3
  3. Put CloudFront in front of API Gateway and configure CloudFront to validate client certificates
  4. Configure a VPN connection and require VPN client certificates
Show Answer

Answer: B — API Gateway supports mutual TLS (mTLS) on custom domains. Upload your CA bundle (truststore) to S3, reference it in the custom domain configuration. API Gateway will verify that each client presents a valid certificate signed by your CA. No additional authentication layer needed. CloudFront (C) doesn’t natively validate client certificates for API Gateway origins. Lambda authorizer (A) would need custom certificate parsing logic.

Related Posts

References

Frequently Asked Questions

When should I use Secrets Manager vs Parameter Store?

Use Secrets Manager when you need: automatic rotation (especially for RDS), cross-account access (resource policy), or built-in password generation. Use Parameter Store for: configuration values (not secrets), feature flags, when cost matters (free tier), or when you need hierarchical paths. You can reference Secrets Manager secrets from Parameter Store paths for compatibility.

How does Secrets Manager rotation work without downtime?

Use the alternating users strategy: create two DB users (user_1, user_2). Secrets Manager rotates one at a time. While user_1’s password is being changed, user_2 still works. Applications that cache credentials continue working with the previous valid user until they refresh. The AWSPREVIOUS version remains valid during the rotation window.

Can I use ACM certificates on EC2 instances?

ACM public certificates cannot be exported (no private key access), so they can’t be installed directly on EC2. They work only with integrated services (ELB, CloudFront, API Gateway). ACM Private CA certificates CAN be exported and installed on EC2, on-premises servers, IoT devices, or anywhere you need the private key.

AWS DDoS & Edge Protection Architecture – WAF, Shield & CloudFront Security

AWS DDoS & Edge Protection Architecture — Overview

Edge protection is tested across SCS-C03 (Domain 3: Infrastructure Security) and SAP-C02. The architecture combines CloudFront (CDN/edge), AWS WAF (Layer 7 rules), AWS Shield (DDoS mitigation), and AWS Firewall Manager (centralized management). This post covers the full defense stack, rule design, and automated response patterns.

Multi-Layer DDoS & Edge Protection
INTERNET (Attackers + Legitimate Traffic)
↓
Layer 1: AWS Shield (Always On)
Shield Standard (free): Automatic L3/L4 DDoS protection. SYN floods, UDP reflection, DNS amplification.
Shield Advanced ($3K/month): L3/L4/L7 protection, DRT team, cost protection, real-time metrics, health-based detection.
↓
Layer 2: CloudFront (Edge Network)
400+ edge locations absorb traffic. Geo-restrictions. Origin isolation (origin never exposed). TLS termination at edge. Caching reduces origin load.
↓
Layer 3: AWS WAF (Layer 7 Rules)
Rate limiting (per IP)
Geo blocking
IP reputation lists
OWASP Top 10 (SQLi, XSS)
Bot control
↓
Layer 4: Application (ALB / API Gateway / AppSync)
Security Groups restrict to CloudFront IPs only. Application-level auth (Cognito). Input validation.
Firewall Manager: Central policy → deploys WAF rules, Shield Advanced, Security Groups across all accounts/regions automatically

AWS WAF — Rule Types & Strategy

Rule Type What It Does Use Case
Rate-based Counts requests per IP in 5-min window; blocks when exceeds threshold Brute force prevention, DDoS mitigation, API abuse
IP Set Allow/Block specific IP addresses or CIDR ranges Threat intelligence feeds, allowlisting corporate IPs
Geo Match Match by country of origin Block countries, route to regional content
SQL Injection Detects SQLi patterns in query strings, body, headers OWASP Top 10 — SQL injection prevention
XSS Detects cross-site scripting patterns OWASP Top 10 — XSS prevention
Size Constraint Block requests exceeding size limits Prevent large payload attacks
Managed Rule Groups Pre-built rules by AWS or marketplace sellers AWSManagedRulesCommonRuleSet (OWASP), BotControl, ATPProtection
Custom Response Return custom HTTP response (403, 429) with custom body Friendly error pages, CAPTCHA challenges

AWS Shield — Standard vs Advanced

Feature Shield Standard Shield Advanced
Cost Free (included with all AWS accounts) $3,000/month + data transfer fees
Protection Layer 3/4 (network/transport) Layer 3/4/7 (+ application layer)
DRT Access No Yes — AWS DDoS Response Team assists during attacks
Cost Protection No Refund for scaling costs caused by DDoS attacks
Resources Protected All (automatic) CloudFront, ALB, NLB, EIP, Global Accelerator, Route 53
Health-based Detection No Yes — uses Route 53 health checks to detect application-layer attacks
Automatic L7 Mitigation No Yes — auto-creates WAF rules during L7 attacks

AWS Firewall Manager — Centralized Policy

  • Purpose: Deploy and manage security rules across ALL accounts in an Organization from a single admin account
  • Manages: WAF rules, Shield Advanced protections, Security Groups, Network Firewall rules, Route 53 Resolver DNS Firewall
  • Auto-remediation: Automatically applies policies to new resources/accounts (no manual setup per account)
  • Prerequisite: AWS Organizations + Config enabled in all accounts
  • Exam key: “Deploy WAF rules consistently across all accounts” → Firewall Manager

Protection Patterns by Attack Type

Attack Layer Mitigation
SYN Flood L3/4 Shield Standard (automatic). Put behind CloudFront/ALB.
UDP Reflection/Amplification L3/4 Shield Standard. Security groups (block UDP if not needed).
DNS Amplification L3/4 Route 53 (inherently scalable). Shield protects Route 53.
HTTP Flood L7 WAF rate-based rules. CloudFront caching. Shield Advanced auto-mitigation.
Slowloris L7 ALB (handles connection pooling). CloudFront times out slow connections.
SQL Injection L7 WAF SQLi rule set. Input validation at application.
Bot/Scraper L7 WAF Bot Control (managed rule). CAPTCHA challenges. Client fingerprinting.

Best Practice Architecture

  • Always front with CloudFront: Absorbs volumetric attacks at edge, hides origin IP, enables WAF without additional latency
  • Origin protection: Security group on ALB allows only CloudFront managed prefix list IPs + custom origin header validation
  • WAF on CloudFront: Deploy WAF at CloudFront (not ALB) — blocks attacks at the edge before they reach your region
  • Rate limiting at multiple levels: WAF rate rules (per-IP), API Gateway throttling (per-API key), application-level
  • Auto-scaling behind protection: Even with DDoS protection, ensure ASG/ALB can handle legitimate traffic spikes

Exam Tips

Exam Key Points
SCS-C03 “L3/L4 DDoS” → Shield Standard (free, automatic). “L7 DDoS + cost protection + DRT” → Shield Advanced. “Block SQL injection” → WAF SQLi rule. “Rate limit per IP” → WAF rate-based rule. “Deploy WAF across all accounts” → Firewall Manager. “Hide origin from internet” → CloudFront + SG restricting to CF IPs. “OWASP Top 10” → AWS Managed Rules Common Rule Set. “Automatic L7 mitigation” → Shield Advanced.

AWS Certification Exam Practice Questions

Question 1:

A company’s web application behind an ALB is experiencing an HTTP flood attack (thousands of requests per second from distributed IPs targeting the /login endpoint). Shield Standard is not mitigating it. What combination provides the fastest protection?

  1. Enable Shield Advanced on the ALB and wait for automatic mitigation
  2. Add a WAF rate-based rule on the ALB limiting requests to /login per IP, and deploy CloudFront in front of the ALB
  3. Increase ALB capacity and add more EC2 instances behind the ASG
  4. Block all international traffic using Security Group rules
Show Answer

Answer: B — Shield Standard only handles L3/L4 attacks, not L7 HTTP floods. A WAF rate-based rule (e.g., 100 requests per 5 minutes per IP to /login) blocks excessive requesters. CloudFront absorbs the volumetric load at the edge before it reaches the ALB. Shield Advanced (A) would help long-term but takes time to onboard. Scaling (C) increases cost without solving the attack. SG rules (D) can’t block distributed IPs easily.

Question 2:

A company needs to deploy identical WAF rules (OWASP protections + rate limiting) across 30 AWS accounts in their Organization. When new accounts are added, the rules must be automatically applied. Which approach requires the LEAST ongoing effort?

  1. Create a CloudFormation StackSet that deploys WAF WebACLs to all accounts
  2. Use AWS Firewall Manager with a WAF policy applied to the Organization
  3. Create a central Lambda function that deploys WAF rules to each account via cross-account roles
  4. Document the WAF rules and require each account team to implement them manually
Show Answer

Answer: B — Firewall Manager automatically applies WAF policies to all accounts in the Organization. When new accounts are added, policies are automatically applied. When new resources (ALBs, CloudFront distributions) are created, WAF is automatically associated. CloudFormation StackSets (A) work but require manual triggering for new accounts/resources.

Question 3:

A company wants to ensure their ALB origin is NEVER directly accessible from the internet — all traffic must flow through CloudFront. They also want to verify that requests actually came from their CloudFront distribution (not someone else’s). Which controls achieve this?

  1. ALB security group allowing only CloudFront managed prefix list + custom origin header in CloudFront that ALB validates
  2. Private ALB in a private subnet with no internet gateway
  3. WAF on ALB blocking requests without CloudFront headers
  4. Shield Advanced protecting the ALB directly
Show Answer

Answer: A — Two layers: (1) Security group restricts ALB ingress to only the CloudFront managed prefix list IPs (no direct internet access). (2) CloudFront adds a custom origin header (secret value), ALB or application validates it — ensures the request came from YOUR distribution (not any random CloudFront distribution). Private ALB (B) wouldn’t receive CloudFront traffic either. WAF (C) alone doesn’t prevent direct IP access.

Question 4:

During a DDoS attack, a company’s Auto Scaling group scales up significantly, tripling their EC2 and data transfer costs. They have Shield Advanced. After the attack, how can they recover these costs?

  1. File a support ticket requesting a general AWS credit
  2. Request DDoS cost protection credit through Shield Advanced — AWS refunds scaling costs attributed to the DDoS attack
  3. Shield Advanced automatically credits the account without any action
  4. Costs cannot be recovered; Shield Advanced only prevents future attacks
Show Answer

Answer: B — Shield Advanced includes DDoS cost protection. After an attack, you can request service credits for scaling charges (EC2, ELB, CloudFront, Route 53, Global Accelerator) caused by the DDoS event. You must file a request within 15 days of the billing cycle. It’s not automatic (C is wrong) — you must submit a request with evidence that the scaling was DDoS-related.

Question 5:

A security engineer needs to block requests from a specific list of 10,000 malicious IPs updated daily by a threat intelligence feed. The block must apply to CloudFront distributions across all accounts. What is the most operationally efficient solution?

  1. Manually update Security Groups daily in each account
  2. Create a WAF IP set, use a Lambda function to update it daily from the threat feed, deploy via Firewall Manager across all accounts
  3. Use Network Firewall with stateful rules in each VPC
  4. Configure Route 53 to not resolve DNS for those IPs
Show Answer

Answer: B — WAF IP sets can hold up to 10,000 IPs. Lambda (triggered daily by EventBridge) fetches the threat feed and updates the IP set via the WAF API. Firewall Manager deploys the WAF policy with this IP set rule across all accounts/distributions automatically. Security Groups (A) have a 60-rule limit and don’t apply to CloudFront. Network Firewall (C) doesn’t protect CloudFront. Route 53 (D) doesn’t block by source IP.

Related Posts

References

Frequently Asked Questions

Do I need Shield Advanced if I have WAF?

Shield Standard (free) handles L3/L4 DDoS automatically. WAF handles L7 (application) attacks with rules you define. Shield Advanced adds: L7 automatic mitigation, DRT team access during attacks, cost protection (refund for DDoS-caused scaling), and near real-time visibility. For most applications, Shield Standard + WAF is sufficient. Shield Advanced is for high-profile targets needing DRT support and cost protection.

Where should I deploy WAF — on CloudFront or ALB?

Deploy WAF on CloudFront when possible. Attacks are blocked at the edge (closer to attacker, further from your infrastructure). If you need different WAF rules per path/domain on the same ALB, add WAF on ALB too. CloudFront WAF is global (one WebACL for all edge locations). ALB WAF is regional. You can have WAF on both simultaneously.

What is the difference between WAF rate-based rules and API Gateway throttling?

WAF rate-based rules: Block by source IP when requests exceed threshold (e.g., 100 per 5 minutes). Applied at CloudFront/ALB level. API Gateway throttling: Limit by API key, stage, or method (e.g., 1000 req/sec per API key). Applied per API. Use both: WAF for DDoS/abuse protection, API Gateway for fair-use rate limiting per customer.

AWS IAM Security Architecture – SCPs, Permission Boundaries & ABAC

AWS IAM Security Architecture — Overview

IAM is the largest exam domain on SCS-C03 (20%) and appears heavily on SAP-C02. This post covers the layered access control model: SCPs (organization guardrails) → Permission Boundaries (delegation limits) → Identity Policies (actual permissions) → Resource Policies (resource-level control). Understanding policy evaluation order and interaction is critical.

AWS Access Control Layers (Evaluation Order)
Layer 1: Organization SCPs (Deny Guardrails)
Maximum permissions for ALL principals in the account. Cannot GRANT — only RESTRICT.
Layer 2: Resource Control Policies (RCPs)
Control what external principals can do with resources in the account.
Layer 3: Permission Boundaries (Delegation Safety)
Maximum permissions a SPECIFIC principal can have. Set by admin, limits what identity policy can grant.
Layer 4: Identity Policies (IAM Policies)
Actual permissions granted to the user/role. INTERSECTS with boundaries and SCPs.
Layer 5: Resource Policies
Attached to resources (S3 bucket, KMS key, SQS queue). Can grant cross-account access directly.
Result: Effective permissions = SCP ∩ RCP ∩ Boundary ∩ Identity Policy (∪ Resource Policy for cross-account)

Service Control Policies (SCPs)

Feature Details
What they do Set maximum available permissions for ALL principals in an account (including root!). Cannot grant permissions — only restrict.
Applied to OUs or individual accounts (inherited from parent OU → child OU → account)
Do NOT affect Management account (always exempt), service-linked roles, CloudFront key pairs
Strategy: Deny list Start with FullAWSAccess, add explicit Deny statements for restricted actions (most common approach)
Strategy: Allow list Remove FullAWSAccess, explicitly allow only approved services (more restrictive, harder to manage)

Common SCP Patterns (Exam Favorites)

  • Prevent leaving Organization: Deny organizations:LeaveOrganization
  • Prevent disabling CloudTrail: Deny cloudtrail:StopLogging, cloudtrail:DeleteTrail
  • Prevent deleting GuardDuty: Deny guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount
  • Restrict regions: Deny all actions unless aws:RequestedRegion is in allowed list (with exceptions for global services)
  • Require encryption: Deny s3:PutObject unless s3:x-amz-server-side-encryption is present
  • Prevent root user access: Deny all actions when aws:PrincipalArn matches root (doesn’t affect management account)

Permission Boundaries

  • Purpose: Allow administrators to delegate user/role creation safely. The boundary sets maximum permissions that any identity policy can grant.
  • Intersection model: Effective permissions = Identity Policy ∩ Permission Boundary. If boundary doesn’t allow s3:*, even AdministratorAccess policy can’t grant S3.
  • Use case: DevOps team can create roles for their applications, but boundary ensures they can’t create roles with more permissions than they have themselves (privilege escalation prevention).
  • Exam trap: Permission boundaries ONLY affect identity-based policies. Resource policies (like S3 bucket policy) bypass the boundary check.

ABAC (Attribute-Based Access Control)

Approach How Best For
RBAC (traditional) One policy per role per resource. Explicit ARNs in policies. Small, static environments
ABAC (tag-based) Policy uses conditions: aws:ResourceTag/Project = ${aws:PrincipalTag/Project} Dynamic, large environments. No policy changes when new resources are created.
  • ABAC advantage: One policy works for all projects/teams. Tag a user with Project=Alpha, resources with Project=Alpha → access granted automatically.
  • ABAC + SCPs: Use SCP to require tags on resource creation (aws:RequestTag must include Project)
  • Session tags: SAML federation can pass tags (department, team) from IdP → IAM role → ABAC policy evaluation

IAM Policy Evaluation Logic

For same-account requests:

  1. Explicit Deny? → DENIED (anywhere in any policy = final denial)
  2. SCP allows? → If SCP doesn’t allow, DENIED
  3. Resource policy allows? → If resource policy grants access (same-account), ALLOWED (skip remaining checks)
  4. Permission boundary allows? → If boundary set and doesn’t include action, DENIED
  5. Session policy allows? → If session policy set and doesn’t include action, DENIED
  6. Identity policy allows? → If identity policy grants, ALLOWED. Otherwise, implicit DENIED.

For cross-account requests:

  • BOTH sides must allow: Account A’s identity policy (or resource policy) must allow AND Account B’s resource policy must allow
  • Exception: If Account B’s resource policy specifies Account A’s role ARN directly, Account A’s identity policy is not needed
  • SCPs apply to the requesting principal’s account

Session Policies & Roles Anywhere

  • Session policies: Passed when assuming role (AssumeRole API). Further restricts the role’s permissions for that session only. Effective = Role Policy ∩ Session Policy.
  • IAM Roles Anywhere: Workloads OUTSIDE AWS (on-premises servers) can get temporary credentials by presenting a certificate from a registered CA trust anchor. Eliminates long-term access keys for hybrid workloads.
  • Amazon Verified Permissions: Fine-grained authorization for applications using Cedar policy language. Externalize authorization logic from application code.

Exam Tips

Exam Key Points
SCS-C03 “Prevent region usage” → SCP with aws:RequestedRegion. “Delegate role creation safely” → Permission Boundaries. “Dynamic access based on tags” → ABAC. “Cross-account access” → both identity + resource policy (or resource policy alone). “Management account” = exempt from SCPs. “Explicit Deny always wins”. “Permission boundary doesn’t affect resource policies”.

AWS Certification Exam Practice Questions

Question 1:

A company wants to allow their development team to create IAM roles for Lambda functions, but prevent them from creating roles with more permissions than their own (privilege escalation). The solution must not require security team approval for each role creation. Which approach achieves this?

  1. Create an SCP denying iam:CreateRole for the development OU
  2. Require developers to attach a specific permission boundary to any role they create, enforced by a condition in their IAM policy
  3. Create a Lambda execution role and require all functions use only this role
  4. Use AWS Service Catalog to manage approved role configurations
Show Answer

Answer: B — Permission boundaries solve the delegation problem. The developer’s policy allows iam:CreateRole, iam:AttachRolePolicy BUT with a condition: iam:PermissionsBoundary must equal the approved boundary ARN. Any role they create is automatically limited to the boundary’s permissions — they cannot escalate. SCP (A) blocks all role creation. Single role (C) doesn’t scale. Service Catalog (D) requires approval overhead.

Question 2:

An organization wants to ensure NO AWS account (except the management account) can disable CloudTrail or leave the organization, regardless of what IAM permissions exist in those accounts. How should this be implemented?

  1. Remove iam:* from all accounts to prevent admin access
  2. Apply an SCP at the organization root denying cloudtrail:StopLogging, cloudtrail:DeleteTrail, and organizations:LeaveOrganization
  3. Create AWS Config rules to detect and auto-remediate these actions
  4. Create EventBridge rules in each account to block these API calls
Show Answer

Answer: B — SCPs are preventive controls that set maximum available permissions. A Deny in an SCP overrides any Allow in any identity policy, even AdministratorAccess. Applied at the root OU, it affects all member accounts. The management account is automatically exempt (cannot SCP itself). Config rules (C) and EventBridge (D) are detective/reactive — they detect after the fact, not prevent. Removing iam:* (A) breaks everything.

Question 3:

A company uses SAML federation from their on-premises Active Directory. They need engineers tagged with “Department=Engineering” in AD to only access EC2 instances tagged with “Department=Engineering” — without creating separate policies per department. Which approach provides this?

  1. Create separate IAM roles per department, each with hardcoded resource ARNs
  2. Use SAML session tags to pass Department attribute, then use ABAC policy with aws:PrincipalTag/Department condition matching aws:ResourceTag/Department
  3. Use permission boundaries per department limiting resource access
  4. Create resource policies on each EC2 instance allowing specific department groups
Show Answer

Answer: B — ABAC with session tags: The SAML IdP passes the Department attribute as a session tag during federation. The IAM policy condition checks aws:ResourceTag/Department == ${aws:PrincipalTag/Department}. One policy works for ALL departments. New departments automatically work without policy changes — just tag users and resources. This scales infinitely without per-department roles (A) or policies.

Question 4:

Account B has an S3 bucket with a bucket policy allowing Account A’s role to PutObject. However, when Account A’s role tries to upload, it gets AccessDenied. The role has s3:* in its identity policy. Account A has an SCP that allows all S3 actions. What is the most likely cause?

  1. The bucket policy needs to specify the role ARN, not the account
  2. Account B’s SCP is blocking the PutObject action
  3. Account A’s permission boundary on the role doesn’t include s3:PutObject
  4. S3 requires the request to include server-side encryption headers
Show Answer

Answer: C — For cross-account access where the identity policy allows the action, a permission boundary on the role will still restrict it. Even though the identity policy has s3:* and the SCP allows it, the boundary creates an additional intersection. If the boundary doesn’t include s3:PutObject, the effective permission is denied. Note: if only the resource policy (bucket policy) grants access and the identity policy doesn’t have the action, boundaries don’t apply — but here the identity policy also has s3:*.

Question 5:

A company has on-premises servers that need to call AWS APIs (S3, DynamoDB) without storing long-term access keys on the servers. The servers have certificates issued by the company’s private CA. Which solution eliminates long-term credentials?

  1. Create an IAM user with access keys, rotate keys every 90 days
  2. Set up a Site-to-Site VPN and use the VPC’s IAM capabilities
  3. Configure IAM Roles Anywhere with the company’s private CA as trust anchor, servers present certificates to get temporary credentials
  4. Use AWS SSO (IAM Identity Center) with SAML for machine-to-machine auth
Show Answer

Answer: C — IAM Roles Anywhere enables workloads outside AWS to obtain temporary credentials by presenting an X.509 certificate. Register your CA as a trust anchor, create a profile with the desired IAM role. Servers present their certificate → Roles Anywhere validates against the CA → issues temporary STS credentials. No long-term keys stored. SSO/Identity Center (D) is for human users, not machine-to-machine.

Related Posts

References

Frequently Asked Questions

What is the difference between SCPs and Permission Boundaries?

SCPs apply to an entire AWS account (all principals within it). They set the maximum permissions for the account. Permission Boundaries apply to a specific IAM user or role. They limit what that specific principal can do. SCPs are set by the Organization admin; boundaries are set by the account admin. Both use the intersection model — effective permissions must be allowed by both.

Does the management account get restricted by SCPs?

No. The management account is always exempt from SCPs. This is by design — you can’t accidentally lock yourself out of the Organization. Because of this, best practice is to NOT run workloads in the management account. Use it only for Organization management, billing, and account creation.

How does ABAC scale better than RBAC?

With RBAC, you need N policies for N projects/teams (one policy per team specifying resource ARNs). With ABAC, you need ONE policy that uses tag conditions. When a new project starts, just tag the resources and users — no policy changes. The policy Condition: aws:ResourceTag/Project == ${aws:PrincipalTag/Project} automatically works for all current and future projects.

AWS Data Encryption Architecture – KMS vs CloudHSM, Key Policies & Rotation

AWS Data Encryption Architecture — Overview

Data encryption is the largest topic on the SCS-C03 exam (Domain 5: 18%). Every scenario involves choosing between KMS and CloudHSM, selecting the right key type, designing cross-account key access, and implementing rotation. This post covers the complete encryption decision framework — from key hierarchy to cross-account patterns to exam traps around key policies.

AWS Key Management — Decision Tree
Do you need FIPS 140-2 Level 3 or single-tenant HSM?
YES → CloudHSM
FIPS 140-2 Level 3 validated
Single-tenant dedicated HSM
You control keys (AWS cannot access)
Custom key store for KMS
Oracle TDE, SSL offloading
~$1.50/hr per HSM
NO → AWS KMS
AWS Managed Key
aws/s3, aws/ebs, aws/rds
Auto-created per service
Cannot manage rotation
Cannot use cross-account
Free (no monthly fee)
Customer Managed Key
You create & manage
Full key policy control
Cross-account sharing ✅
Auto-rotation (configurable)
$1/month + $0.03/10K requests
Imported Key Material
Bring your own key
You manage durability
Can set expiration
Manual rotation only
Delete & re-import
Custom Key Store: KMS interface + CloudHSM backend. Get KMS API convenience with CloudHSM security. Keys never leave your HSM.

KMS vs CloudHSM — Detailed Comparison

Feature AWS KMS CloudHSM
FIPS Level FIPS 140-2 Level 2 (Level 3 in some modules) FIPS 140-2 Level 3
Tenancy Multi-tenant (shared infrastructure) Single-tenant (dedicated HSM in your VPC)
Key Access AWS manages HSM; you control via key policy You have full exclusive control (AWS cannot access keys)
Key Types Symmetric (AES-256), Asymmetric (RSA, ECC) Symmetric, Asymmetric, + custom algorithms
Integration Native AWS service integration (S3, EBS, RDS, etc.) Custom application integration, Oracle TDE, SSL/TLS offload
Cross-account Yes (via key policy + IAM) Not directly (must share via network/VPC peering)
HA Built-in (multi-AZ by default) You must deploy cluster (min 2 HSMs across AZs)
Cost $1/key/month + API calls ~$1.50/hr per HSM (~$1,100/month per HSM)

KMS Key Policy — The Critical Exam Topic

KMS key policies are the #1 exam trap. Unlike all other AWS resources, KMS keys have their own resource policy that MUST explicitly grant access — IAM policies alone are insufficient unless the key policy allows it.

  • Default key policy: Allows the root principal to perform all actions → enables IAM policies to control access
  • Without root principal statement: IAM policies cannot grant access to the key (even AdministratorAccess won’t work!)
  • Key administrators: Can manage the key (enable/disable, delete, rotate) but CANNOT use it for encrypt/decrypt
  • Key users: Can use the key for encrypt/decrypt/generate data key operations
  • Grants: Delegated, temporary access to a key (used by AWS services internally, e.g., EBS attaching encrypted volume)

Cross-Account KMS Key Access

Two things must be true for cross-account KMS access:

  1. Key policy in Account A must allow Account B’s root (or specific role): "Principal": {"AWS": "arn:aws:iam::ACCOUNT_B:root"}
  2. IAM policy in Account B must allow the role to use the key: "Resource": "arn:aws:kms:region:ACCOUNT_A:key/key-id"

Exam trap: If the key policy only lists specific principals (no root principal), IAM policies in Account A won’t work either. The key policy is the primary gatekeeper.

Key Rotation

Key Type Auto-Rotation Manual Rotation Exam Notes
AWS Managed Automatic (every year) — cannot change N/A You cannot control rotation period
Customer Managed (KMS-generated) Optional, configurable (90-2560 days) Create new key + update alias Old key material kept (decrypt old data). Key ID unchanged. Only new data uses new material.
Imported Key Material ❌ Not supported Delete → re-import new material Must manage externally. Can set expiration date. Use alias for transparent rotation.
CloudHSM You manage entirely Application-level rotation Full customer responsibility

Encryption Patterns — At Rest

Service SSE Options Key Decision
S3 SSE-S3 (default), SSE-KMS, SSE-C, CSE SSE-KMS for audit trail (CloudTrail logs each decrypt). SSE-C when you manage keys externally. CSE for client-side.
EBS AES-256 (KMS) Enable default encryption per region. Snapshots inherit key. Cross-account: re-encrypt with shared key.
RDS AES-256 (KMS) Must enable at creation (cannot encrypt existing). Encrypted snapshots → encrypted restore. Cross-region: re-encrypt with target region key.
DynamoDB AWS owned, AWS managed, Customer managed Customer managed for cross-account access control and audit. AWS owned is free.

Encryption in Transit

  • ELB: Configure security policies (TLS 1.2+ enforced). Use ACM certificates. ALB terminates TLS, can re-encrypt to backend.
  • S3: Bucket policy with aws:SecureTransport: false denies HTTP. Forces HTTPS only.
  • RDS: rds.force_ssl = 1 (MySQL) or rds.force_ssl = true (PostgreSQL). Download RDS CA bundle.
  • API Gateway: HTTPS only by default. Can configure mutual TLS (mTLS) with custom domain.
  • VPC: VPN (IPsec) or PrivateLink for private connectivity. All inter-region VPC peering is encrypted.

Envelope Encryption (Data Key Pattern)

  • How it works: KMS generates a Data Encryption Key (DEK). Plaintext DEK encrypts your data. KMS encrypts the DEK with the CMK. Store encrypted DEK alongside encrypted data.
  • Why: KMS has a 4KB limit on direct encrypt. Envelope encryption allows encrypting any size data. Only the small DEK crosses the network to KMS.
  • GenerateDataKey: Returns both plaintext DEK (use to encrypt) and encrypted DEK (store alongside data)
  • Decrypt flow: Send encrypted DEK to KMS → get plaintext DEK → decrypt data locally
  • Exam relevance: “Encrypt 1GB file with KMS” → must use envelope encryption (GenerateDataKey), NOT Encrypt API

Exam Tips

Exam Key Points
SCS-C03 “FIPS 140-2 Level 3” → CloudHSM. “Cross-account encryption” → Customer managed KMS key + key policy allowing other account. “Audit who decrypted” → SSE-KMS (CloudTrail logs Decrypt calls). “Imported key material” → manual rotation only, you manage durability. “Key policy allows root principal” = enables IAM policies. “Encrypt large file with KMS” → envelope encryption (GenerateDataKey). “Cannot encrypt existing RDS” → snapshot, copy with encryption, restore.

AWS Certification Exam Practice Questions

Question 1:

A company stores sensitive financial data in S3. Compliance requires that all decryption events are logged in CloudTrail, the encryption key can be disabled immediately if compromised, and only specific IAM roles can decrypt. Which encryption configuration meets ALL these requirements?

  1. SSE-S3 (Amazon S3-managed keys)
  2. SSE-KMS with an AWS managed key (aws/s3)
  3. SSE-KMS with a customer managed key and restrictive key policy
  4. SSE-C (customer-provided keys)
Show Answer

Answer: C — Customer managed KMS key provides: (1) CloudTrail logging of every Decrypt/Encrypt call. (2) Ability to disable the key immediately (renders all data inaccessible). (3) Key policy controls exactly which roles can decrypt. AWS managed keys (B) log decrypt events but cannot be disabled and don’t allow custom key policy. SSE-S3 (A) doesn’t log individual decrypt events. SSE-C (D) requires customer to manage key delivery on every request.

Question 2:

Account A has an encrypted EBS snapshot that needs to be shared with Account B. The snapshot is encrypted with a customer managed KMS key. What steps are required for Account B to use this snapshot?

  1. Share the snapshot with Account B. Account B copies it using their own KMS key. No key policy change needed.
  2. Modify the KMS key policy to allow Account B access. Share the snapshot. Account B creates a volume or copies with their own key.
  3. Create an unencrypted copy of the snapshot, then share the unencrypted version with Account B.
  4. Export the KMS key to Account B using key material import.
Show Answer

Answer: B — For cross-account encrypted snapshot sharing: (1) The KMS key policy must grant Account B permission to use the key (kms:Decrypt, kms:CreateGrant). (2) Share the snapshot with Account B. (3) Account B can then copy the snapshot to their account, re-encrypting with their own CMK. Without key policy change, Account B cannot decrypt the snapshot even after it’s shared. You cannot create an unencrypted copy of an encrypted snapshot (C is wrong).

Question 3:

A company’s compliance team requires that encryption keys used for sensitive workloads are stored in hardware that AWS personnel cannot access, while still using the KMS API for integration with AWS services. Which configuration achieves this?

  1. KMS with customer managed keys (standard)
  2. KMS with imported key material
  3. KMS custom key store backed by CloudHSM cluster
  4. Client-side encryption with keys stored in Secrets Manager
Show Answer

Answer: C — Custom key store connects KMS to your CloudHSM cluster. You get the KMS API (integrates with S3, EBS, RDS, etc.) but keys are generated and stored in your single-tenant CloudHSM (AWS personnel cannot access). Standard KMS (A) uses multi-tenant AWS-managed HSMs. Imported keys (B) still reside in AWS HSMs after import. This is the best-of-both-worlds approach.

Question 4:

A developer tries to use a KMS key to encrypt data but receives “AccessDeniedException.” Their IAM policy has kms:* on the key ARN. The key policy only contains a statement allowing the key administrator to manage the key. What is the issue?

  1. The IAM policy must specify the exact actions (kms:Encrypt) not wildcard
  2. The key policy does not include the root principal statement, so IAM policies cannot grant access
  3. The developer needs to be added as a key administrator
  4. KMS keys require explicit Deny removal before access works
Show Answer

Answer: B — This is the #1 KMS exam trap. KMS key policies are the primary access control. If the key policy does not include a statement allowing the account’s root principal (which enables IAM policies to work), then NO IAM policy can grant access — even kms:* will fail. The fix: add {"Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::ACCOUNT:root"}, "Action": "kms:*", "Resource": "*"} to the key policy.

Question 5:

A company needs to encrypt a 50MB file using KMS. When they call the kms:Encrypt API with the file, they receive an error that the payload exceeds the 4KB limit. How should they encrypt this file?

  1. Split the file into 4KB chunks and encrypt each chunk separately with kms:Encrypt
  2. Use kms:GenerateDataKey to get a data encryption key, encrypt the file locally with the plaintext key, store the encrypted key alongside the encrypted file
  3. Increase the KMS payload limit through a service quota increase request
  4. Use CloudHSM instead, which has no payload size limit
Show Answer

Answer: B — This is envelope encryption. KMS’s Encrypt API has a 4KB payload limit. For larger data: (1) Call GenerateDataKey → get plaintext DEK + encrypted DEK. (2) Use plaintext DEK to encrypt the 50MB file locally (AES-256). (3) Discard plaintext DEK from memory. (4) Store encrypted DEK alongside encrypted file. To decrypt: send encrypted DEK to KMS (Decrypt API) → get plaintext DEK → decrypt file locally. The 4KB limit cannot be increased (C is wrong).

Related Posts

References

Frequently Asked Questions

When should I use CloudHSM vs KMS?

Use KMS for most workloads — it integrates natively with 100+ AWS services, is fully managed, and costs $1/key/month. Use CloudHSM when you need: FIPS 140-2 Level 3 compliance, single-tenant HSM (regulatory requirement), full exclusive key control (AWS cannot access), or custom cryptographic algorithms. You can combine both via KMS Custom Key Store.

Can I use one KMS key across multiple accounts?

Yes, but both the key policy AND an IAM policy must allow it. The key policy grants the other account’s root principal (or specific role) access. Then an IAM policy in the consuming account allows the role to call KMS. Without BOTH, cross-account access fails. AWS managed keys (aws/s3, aws/ebs) cannot be shared cross-account — only customer managed keys.

What happens when I rotate a KMS key?

AWS creates new key material but keeps the old material. The key ID and ARN don’t change. New data encrypts with new material. Old data still decrypts fine (KMS tracks which version encrypted each ciphertext). You don’t need to re-encrypt existing data. This is automatic and transparent — no application changes needed.

AWS Centralized Logging Architecture – CloudTrail, Security Lake & SIEM

AWS Centralized Logging Architecture — Overview

Centralized logging is a foundational security requirement across all AWS certifications. The SCS-C03 exam tests your ability to design multi-account logging architectures that aggregate, correlate, and alert on security events. This post covers the complete logging pipeline: from source collection (CloudTrail, VPC Flow Logs, DNS logs) through aggregation (Security Lake, CloudWatch) to analysis (Athena, OpenSearch, SIEM).

Centralized Security Logging Architecture
LOG SOURCES (All Accounts)
CloudTrail (API)
VPC Flow Logs
Route 53 DNS
GuardDuty
WAF Logs
S3 Access
ELB Access
Config
↓ ↓ ↓
Path A: S3 + Athena
CloudTrail Org Trail → S3 (Log Archive Account)
VPC Flow Logs → S3
Athena queries for ad-hoc analysis
Glue Catalog for schema
Cost: Lowest | Query: Ad-hoc
Path B: Security Lake (OCSF)
Auto-collects from 80+ sources
Normalizes to OCSF schema
S3 storage (Apache Iceberg)
Query via Athena or 3rd-party SIEM
Cost: Medium | Schema: Unified
Path C: CloudWatch + OpenSearch
CloudWatch Logs (real-time)
Subscription filters → OpenSearch
Dashboards + Alerts
Cross-account log aggregation
Cost: Highest | Real-time: Yes
↓ ↓ ↓
Detection & Alerting
EventBridge Rules → SNS/Lambda
CloudWatch Alarms
GuardDuty Findings
Automated Response
Lambda remediation
Step Functions playbooks
Systems Manager runbooks
Investigation
Amazon Detective
Athena queries
OpenSearch dashboards

Log Sources — What to Collect

Source What It Captures Destination Options Key Exam Points
CloudTrail All API calls (who did what, when, from where) S3, CloudWatch Logs Organization trail covers ALL accounts. Management events on by default. Data events (S3/Lambda) must be explicitly enabled.
VPC Flow Logs Network traffic metadata (src/dst IP, port, action) S3, CloudWatch Logs Does NOT capture packet content. Transit Gateway flow logs for inter-VPC. Enable in ALL VPCs.
Route 53 Resolver Logs DNS queries from VPCs S3, CloudWatch Logs, Kinesis Firehose Detects DNS exfiltration, C2 communication. Share via RAM to Log Archive account.
GuardDuty Findings Threat detections (recon, compromise, crypto-mining) EventBridge, S3 (export) Delegated admin aggregates all member findings. Auto-archives after 90 days.
AWS Config Resource configuration changes, compliance S3, SNS Aggregator for multi-account/region view. Config rules for compliance detection.
S3 Access Logs Bucket-level access (who accessed what object) S3 (target bucket) Different from CloudTrail S3 data events. Best-effort delivery. Use for audit trails.
ELB Access Logs Request details (client IP, latency, status codes) S3 Captures client IP even behind CloudFront. Useful for forensics.
WAF Logs Web requests matched/blocked by WAF rules S3, CloudWatch Logs, Kinesis Firehose Full request headers, rule matched. Essential for tuning WAF rules.

Organization CloudTrail Trail

  • Setup: Create from the management account → automatically applies to ALL member accounts
  • Storage: Central S3 bucket in Log Archive account with bucket policy allowing organization trail delivery
  • Protection: S3 Object Lock (WORM), MFA Delete, bucket policy denying s3:DeleteObject, KMS encryption
  • Validation: CloudTrail log file integrity validation (SHA-256 hash chain). Detects if log files are modified/deleted.
  • Key exam trap: Member accounts can see the trail but CANNOT modify or delete it. Only the management account can.

Cross-Account Log Aggregation Patterns

Pattern How Best For
Org Trail to Central S3 Organization trail → S3 bucket in Log Archive account CloudTrail API logs (cheapest, simplest)
CloudWatch Cross-Account Source accounts → CloudWatch Logs destination (Kinesis/Firehose) → Central account Real-time application logs, Lambda logs
Security Lake (Delegated Admin) Delegated admin auto-collects from all member accounts Unified OCSF schema, SIEM integration
Kinesis Firehose Cross-Account Source account → cross-account Firehose delivery stream → S3/OpenSearch High-volume streaming logs (VPC Flow, custom)

Amazon Security Lake (OCSF)

  • What: Centralized security data lake that automatically collects logs from 80+ AWS and third-party sources
  • Schema: Normalizes ALL data to Open Cybersecurity Schema Framework (OCSF) — single schema regardless of source
  • Storage: S3 with Apache Iceberg tables (efficient querying, time-travel)
  • Sources: CloudTrail, VPC Flow Logs, Route 53, Security Hub, Lambda execution, S3 data events, EKS audit, WAF
  • Subscribers: Query via Athena, or grant data access to third-party SIEMs (Splunk, Datadog, CrowdStrike)
  • Multi-account: Delegated administrator collects from all Organization member accounts automatically
  • Regions: Rollup regions — aggregate from multiple regions into one central region
  • Exam relevance: “Normalize logs from multiple sources into a unified schema” → Security Lake

CloudWatch Logs — Real-Time Analysis

  • Metric Filters: Parse log events → extract metrics → create alarms (e.g., count of “UnauthorizedAccess” → alarm if > 5/min)
  • Subscription Filters: Stream logs in real-time to Lambda, Kinesis, Firehose, or OpenSearch
  • Cross-Account Subscriptions: Source account creates subscription filter → sends to destination in central account (Kinesis/Firehose)
  • Insights Queries: SQL-like queries across log groups. Find patterns, anomalies, top talkers.
  • Data Protection: Mask sensitive data (SSN, credit cards) in logs automatically using data protection policies
  • Retention: Configure per log group (1 day to 10 years, or never expire). Exam: default is never expire (costs money!).

Log Protection — Integrity & Access Control

Control Implementation Purpose
Immutability S3 Object Lock (Governance or Compliance mode) Prevent log deletion/modification (WORM)
Encryption SSE-KMS with customer-managed key Encrypt logs at rest, control access via key policy
Integrity Validation CloudTrail log file validation (digest files) Detect if logs were tampered with
Access Separation Log Archive account with restricted access (separate from workload accounts) Least privilege — ops teams can’t delete logs
Alerting on Tampering EventBridge rule for StopLogging/DeleteTrail API calls Detect if someone tries to disable logging

Exam Tips

Exam Key Points
SCS-C03 “Centralized logging across all accounts” → Organization CloudTrail trail + S3 in Log Archive. “Normalize logs from multiple sources” → Security Lake (OCSF). “Real-time alerting on API calls” → CloudTrail → CloudWatch Logs → Metric Filter → Alarm. “Prevent log tampering” → S3 Object Lock + separate Log Archive account + log file integrity validation. “Detect disabled logging” → EventBridge rule on StopLogging. “Third-party SIEM integration” → Security Lake subscriber or Kinesis Firehose.
SAP-C02 “Multi-account logging strategy” → Organization trail + dedicated Log Archive account. “Query logs across accounts” → Athena on centralized S3 or Security Lake.

AWS Certification Exam Practice Questions

Question 1:

A security engineer needs to ensure that API activity logs from all 50 AWS accounts in the organization cannot be modified or deleted, even by administrators in those accounts. The logs must be retained for 7 years. Which solution meets these requirements?

  1. Create individual CloudTrail trails in each account sending to a local S3 bucket with versioning enabled
  2. Create an organization trail sending to an S3 bucket in a dedicated Log Archive account with S3 Object Lock in Compliance mode
  3. Create an organization trail sending to CloudWatch Logs with a 7-year retention policy
  4. Create individual trails with log file integrity validation enabled and MFA Delete on each bucket
Show Answer

Answer: B — An organization trail automatically collects logs from ALL member accounts. Storing in a separate Log Archive account means workload account admins cannot access the bucket. S3 Object Lock in Compliance mode prevents ANYONE (including root) from deleting objects until retention expires (7 years). Member accounts cannot modify or delete the organization trail. Individual trails (A, D) can be modified by account admins.

Question 2:

A company needs to detect within 1 minute when someone disables CloudTrail logging in any account. The detection must trigger an automated Lambda function to re-enable the trail. Which approach achieves this?

  1. AWS Config rule checking CloudTrail status with auto-remediation via SSM
  2. Organization trail → CloudWatch Logs → metric filter for StopLogging → alarm → SNS → Lambda
  3. EventBridge rule in each member account for StopLogging/DeleteTrail events → central event bus → Lambda
  4. GuardDuty finding for “Stealth:IAMUser/CloudTrailLoggingDisabled” → EventBridge → Lambda
Show Answer

Answer: C — EventBridge rules can detect CloudTrail API events (StopLogging, DeleteTrail) in near real-time. With organization-wide EventBridge rules forwarding to a central event bus, the Lambda function can re-enable the trail immediately. GuardDuty (D) also detects this but has a delay (typically 5-15 minutes). Config (A) checks periodically (not within 1 minute). CloudWatch metric filter (B) works but requires CloudTrail to be sending to CloudWatch Logs first — if the trail is stopped, no new events flow.

Question 3:

A company wants to aggregate security logs from CloudTrail, VPC Flow Logs, Route 53 DNS logs, and GuardDuty findings into a single data store. They need to query all sources with a unified schema. Third-party security tools must also access this data. Which solution provides this?

  1. Send all logs to a central S3 bucket, create Glue crawlers for each source, query with Athena
  2. Send all logs to CloudWatch Logs in a central account, use CloudWatch Logs Insights
  3. Enable Amazon Security Lake with delegated administrator, configure subscriber access for third-party tools
  4. Send all logs to Amazon OpenSearch Service with custom index templates per source
Show Answer

Answer: C — Security Lake automatically collects from all listed sources, normalizes to OCSF (unified schema), stores in S3 with Apache Iceberg tables, and supports subscribers (third-party SIEMs get direct data access). Option A requires manual schema management per source (no unified schema). CloudWatch Insights (B) doesn’t provide a unified schema or third-party access. OpenSearch (D) requires custom integration for each source.

Question 4:

A security team needs to analyze VPC Flow Logs across 100 accounts to find connections to known malicious IPs. The logs are stored in S3 in a central account. They want the lowest-cost query solution that doesn’t require infrastructure management. Which approach is best?

  1. Import logs into Amazon OpenSearch Service and create dashboards
  2. Use Amazon Athena with partitioned tables (by account, date, region) to query directly from S3
  3. Stream to Amazon Kinesis Data Analytics for real-time threat detection
  4. Load into Amazon Redshift for analytics queries
Show Answer

Answer: B — Athena is serverless (no infrastructure), queries S3 directly, and charges only per data scanned. Partitioning by account/date/region minimizes scan cost. OpenSearch (A) and Redshift (D) require provisioned infrastructure. Kinesis (C) is for real-time streaming, not ad-hoc historical analysis. This is the standard pattern for cost-effective log analysis.

Question 5:

A company’s CloudWatch Logs contain sensitive PII (Social Security numbers) from application logs. The security team needs to ensure PII is masked in log output while still allowing full log access for authorized incident responders. Which approach meets both requirements?

  1. Create a Lambda function to process logs before ingestion, redacting PII patterns
  2. Configure CloudWatch Logs data protection policy to mask SSN patterns, grant unmask permission to incident response IAM role
  3. Encrypt logs with KMS key accessible only to incident responders
  4. Create two separate log groups — one with PII (restricted) and one without (general access)
Show Answer

Answer: B — CloudWatch Logs data protection policies automatically detect and mask sensitive data (SSN, credit cards, etc.) using managed data identifiers. The logs:Unmask permission can be granted to specific IAM roles — allowing incident responders to see full data while regular users see masked output. This is a built-in feature requiring no custom code (unlike A) and doesn’t require separate log groups (unlike D).

Related Posts

References

Frequently Asked Questions

What is the difference between CloudTrail and VPC Flow Logs?

CloudTrail logs API calls (who created/modified/deleted AWS resources). VPC Flow Logs capture network traffic metadata (source/destination IPs, ports, accepted/rejected). CloudTrail tells you “who changed the security group rule.” Flow Logs tell you “what traffic is flowing through the network.” Both are essential for security — they answer different questions.

Security Lake vs manually sending logs to S3?

Security Lake automatically collects from 80+ sources, normalizes everything to the OCSF schema (unified format), partitions data for efficient querying, and supports direct subscriber access for SIEMs. Manual S3 aggregation requires you to set up each source individually, manage different schemas, and build custom integrations. Security Lake is the managed approach for organizations with multiple log sources and SIEM requirements.

How do I protect logs from being deleted by compromised admin accounts?

Three layers: (1) Separate Log Archive account — workload account admins have no access. (2) S3 Object Lock Compliance mode — even root cannot delete until retention expires. (3) Organization trail — member accounts cannot modify or delete it. Additionally, enable log file integrity validation to detect tampering, and create EventBridge rules to alert on any StopLogging/DeleteTrail API calls.

AWS Migration Architecture – 7Rs, Migration Hub & Application Migration Service

AWS Migration Architecture — Overview

Migration to AWS follows a structured lifecycle: Assess → Mobilize → Migrate → Modernize. AWS provides purpose-built tools for each phase. Domain 4 of SAP-C02 (20% of the exam) focuses entirely on migration strategy selection, tool choice, and modernization decisions.

AWS Migration Lifecycle & Tools
ASSESS
Migration Hub
Discovery Service
Migration Evaluator
(TCO analysis)
Portfolio assessment
→
MOBILIZE
Landing Zone (Control Tower)
Direct Connect
IAM/SSO setup
Migration Factory
Wave planning
→
MIGRATE
Application Migration Svc
Database Migration (DMS)
DataSync / Transfer Family
Snow Family (offline)
VMware Cloud on AWS
→
MODERNIZE
Containers (ECS/EKS)
Serverless (Lambda)
Managed databases
Event-driven
Microservices
Migration Hub — Central tracking across all tools | 7 Rs — Strategy per workload | Wave Planning — Group by dependency

The 7 Rs — Migration Strategy Selection

Strategy What Example When
Rehost (Lift & Shift) Move as-is to EC2 On-prem VM → EC2 instance Speed priority, no app changes, large-scale migrations
Replatform (Lift & Reshape) Minor optimizations during move MySQL → RDS MySQL, self-managed → managed Quick wins without refactoring (managed DB, Elastic Beanstalk)
Refactor (Re-architect) Redesign for cloud-native Monolith → microservices on ECS/Lambda Business need for agility, scale, or cloud-native features
Repurchase Move to SaaS On-prem CRM → Salesforce, Email → SES Commercial product is better than self-managed
Relocate Move VMware to AWS without changes VMware vSphere → VMware Cloud on AWS VMware investment, need speed, keep same operations
Retain Keep on-premises (not ready yet) Mainframe with 1000+ dependencies Too complex, regulatory, or not cost-justified to move now
Retire Decommission Legacy app with 5 users No longer needed, redundant, or being replaced

Discovery & Assessment Tools

Tool How It Works Data Collected
Agentless Collector (OVA) Deploy virtual appliance in VMware vCenter VM inventory, CPU/RAM utilization, disk allocation (no network/process data)
Discovery Agent Install on each server (Windows/Linux) CPU, RAM, disk, network connections, running processes — full detail
Migration Hub Central dashboard for all migration tracking Server grouping, application mapping, migration status per tool
Migration Evaluator TCO analysis and business case Cost comparison: on-prem vs AWS for your specific workloads

Exam tip: Agentless Collector = VMware only, less detailed. Discovery Agent = any OS, full detail (processes, network connections). Use Agent when you need network dependency mapping to group servers into applications.

Migration Tools — Which to Use When

Tool Migrates How Best For
Application Migration Service (MGN) Entire servers (OS + apps + data) Continuous block-level replication → launch EC2 on cutover Rehost (lift & shift) of physical/virtual servers
Database Migration Service (DMS) Databases Full load + CDC (ongoing changes) Database migration with minimal downtime
AWS DataSync Files / NFS / SMB / HDFS / object storage Agent-based, scheduled or one-time transfer NAS migration, file server to S3/EFS/FSx, ongoing sync
Snow Family Large data (TBs to PBs) Physical device shipped, load data → ship to AWS Limited bandwidth, 10TB+, edge computing
Transfer Family Files via SFTP/FTPS/FTP Managed SFTP endpoint → S3/EFS Partners using legacy file transfer protocols
VMware Cloud on AWS VMware workloads vMotion or HCX (live migration) Relocate strategy — keep VMware operations as-is

Large-Scale Migration Patterns

Wave Planning

Group servers into migration waves based on dependencies and priority:

  • Wave 1: Simple, independent apps (prove the process)
  • Wave 2-N: Increasingly complex apps, grouped by dependency
  • Final wave: Most critical/complex applications

Migration Factory

Standardized, repeatable migration process for large-scale (100+ servers):

  • Playbooks — Step-by-step runbooks per application type
  • Automation — CloudFormation/CDK for landing zone, MGN for replication, SSM for post-migration config
  • Testing — Non-disruptive test launches from MGN before cutover
  • Cutover windows — Scheduled maintenance windows with rollback plan

Zero-Downtime Server Migration (MGN)

  1. Install replication agent on source servers → continuous block replication to AWS staging area
  2. Test launches — Launch test EC2 instances from replicated data. Validate. Terminate test instances.
  3. Cutover — Stop source server → Final sync (seconds) → Launch production EC2 → Update DNS/LB
  4. Downtime — Only during final sync + DNS switch (minutes)

Data Transfer Decision Guide

Data Size Available Bandwidth Recommended Tool
<10 TB Internet / Direct Connect DataSync (over network)
10-80 TB Limited (<100 Mbps) Snowball Edge
80 TB – PB Any Snowball Edge (multiple) or Snowmobile
Ongoing sync Direct Connect / VPN DataSync (scheduled) or DMS CDC (for databases)

Rule of thumb: If transfer over network takes >1 week, consider Snow Family. Formula: Data(TB) × 1024 × 8 / Bandwidth(Mbps) / 86400 = days.

Post-Migration Modernization Path

  • Rehost first, then modernize: Get to AWS fast (lift & shift), then iteratively improve
  • Database: EC2-hosted DB → RDS (managed) → Aurora Serverless (auto-scale) → DynamoDB (if key-value)
  • Compute: EC2 → Containers (ECS/Fargate) → Serverless (Lambda) where appropriate
  • Decouple: Monolith → Extract services using SQS/SNS/EventBridge for async communication
  • Storage: Block (EBS) → Object (S3) for unstructured data, shared file (EFS/FSx) for lift-and-shift NAS

Exam Tips

Exam Key Points
SAP-C02 “Lift and shift servers” → Application Migration Service (MGN). “Migrate database with minimal downtime” → DMS + CDC. “Migrate file servers” → DataSync. “50TB+ limited bandwidth” → Snow Family. “VMware to AWS without changes” → VMware Cloud on AWS (Relocate). “Understand dependencies” → Discovery Agent (not Agentless). “Track all migrations” → Migration Hub. “Minimize code changes” = Rehost/Replatform. “Cloud-native benefits” = Refactor.

AWS Certification Exam Practice Questions

Question 1:

A company needs to migrate 500 on-premises VMs to AWS with minimal downtime. They want to replicate servers continuously and perform non-disruptive test launches before the actual cutover. Which service provides this?

  1. AWS DataSync with scheduled replication
  2. AWS Application Migration Service (MGN) with continuous replication and test mode
  3. VM Import/Export to create AMIs from each VM
  4. AWS Database Migration Service with full load
Show Answer

Answer: B — Application Migration Service (MGN) continuously replicates server block storage to AWS. You can launch test instances at any time without affecting the source servers (non-disruptive testing). At cutover, it performs a final sync and launches production instances. This is the standard tool for rehost (lift-and-shift) migrations at scale. DataSync is for files/NFS. VM Import creates static AMIs (no continuous replication).

Question 2:

A company has 80TB of file data on an on-premises NAS (NFS). Their internet bandwidth is 200 Mbps. They need the data in S3 within 2 weeks and want ongoing daily synchronization after the initial transfer. What approach is MOST efficient?

  1. AWS DataSync over the internet for initial + ongoing sync
  2. AWS Snowball Edge for initial bulk load + DataSync for ongoing daily sync
  3. S3 Transfer Acceleration for initial upload + S3 replication for ongoing
  4. Direct Connect provisioning + DataSync over Direct Connect
Show Answer

Answer: B — At 200 Mbps, transferring 80TB over network would take: 80,000 GB × 8 / 200 Mbps / 86,400 = ~37 days. Exceeds the 2-week deadline. Snowball Edge (80TB capacity) handles the initial bulk load in ~1 week (load + ship + import). Once initial data is in S3, DataSync handles ongoing daily incremental sync over the 200 Mbps link (only new/changed files). Direct Connect takes weeks to provision — won’t help the deadline.

Question 3:

A company is planning migration of 1,000 servers across 50 applications. They need to understand server dependencies (which servers communicate with which) to group them into migration waves. Their infrastructure is a mix of physical servers and VMware VMs. Which discovery approach provides this information?

  1. Deploy the Agentless Collector virtual appliance in VMware vCenter
  2. Deploy the AWS Application Discovery Agent on each server
  3. Use AWS Migration Hub import template with manually gathered data
  4. Run AWS Config in the on-premises environment
Show Answer

Answer: B — The Discovery Agent collects network connections (which servers talk to which, on which ports), running processes, CPU, RAM, and disk details. This network dependency data is essential for grouping servers into applications for wave planning. The Agentless Collector only works for VMware VMs (not physical servers) and doesn’t capture network connections or processes. The company has physical servers too.

Question 4:

A company runs 200 VMware VMs on-premises. Their operations team is heavily invested in VMware tools (vCenter, NSX, vSAN). They want to move to AWS quickly without retraining the team or changing their operational model. Which migration strategy and service fits?

  1. Rehost — Use Application Migration Service to migrate each VM to EC2
  2. Relocate — Use VMware Cloud on AWS with HCX for live migration
  3. Replatform — Convert VMs to containers on ECS Fargate
  4. Refactor — Rebuild applications as serverless on Lambda
Show Answer

Answer: B — Relocate strategy uses VMware Cloud on AWS, which runs the full VMware stack (vCenter, NSX, vSAN) on dedicated AWS hardware. HCX enables live migration (vMotion) of VMs with zero downtime. The ops team continues using the same VMware tools — no retraining. Application Migration Service (Rehost) would move to EC2 instances, changing the operational model away from VMware.

Question 5:

After migrating a monolithic web application to EC2 (rehost), a company wants to modernize it incrementally. The application has a tightly coupled order processing module that causes cascading failures. What is the recommended FIRST modernization step?

  1. Rewrite the entire application as Lambda functions
  2. Extract the order processing module into a separate service, decouple with SQS
  3. Move the entire application to EKS with microservices
  4. Replace the application with a SaaS solution
Show Answer

Answer: B — The Strangler Fig pattern: extract one service at a time from the monolith, starting with the one causing the most problems. Decoupling with SQS prevents cascading failures (if order processing is slow/down, the main app continues — orders queue). This is incremental modernization without the risk of a full rewrite. Complete rewrites (A, C) are high-risk and unnecessary when you can modernize incrementally.

Related Posts

References

Frequently Asked Questions

What is the difference between Application Migration Service and DMS?

Application Migration Service (MGN) migrates entire servers (OS, applications, data) by replicating block storage — the result is an EC2 instance running the same workload. DMS migrates only database data between database engines with optional schema conversion. Use MGN for server migration (lift-and-shift). Use DMS for database-specific migration with schema conversion or engine change.

When should I use Snowball vs DataSync?

Use DataSync when your network can transfer the data within your timeframe (typically <10TB or adequate bandwidth). Use Snowball when network transfer would take too long (>1 week at available bandwidth) or when you have 10TB+ with limited connectivity. The break-even point depends on your bandwidth — calculate transfer time first.

How do I start a migration to AWS?

Follow the migration lifecycle: (1) Assess — Deploy Discovery Agent/Agentless Collector, gather data in Migration Hub, evaluate TCO with Migration Evaluator. (2) Decide strategy — Apply 7Rs per application (most will be Rehost initially). (3) Set up landing zone — Control Tower for multi-account, networking, security baseline. (4) Pilot — Migrate 2-3 simple apps to validate process. (5) Scale — Migration Factory for remaining waves.