In Part 1, we covered identity and access. In Part 2, we went through the security services that protect, detect, and audit your environment. Now comes the last piece of Domain 1 — protecting the data itself and building a secure network around it.

This part has two halves: encryption and secrets management (how you protect data at rest and in transit) and VPC networking (how you control the flow of traffic). Both show up heavily on the exam.

Server-Side Encryption — Three Flavors#

When you store data in AWS (S3 being the most common case), you have three options for server-side encryption:

SSE-S3 — AWS manages everything. Each object is encrypted with a unique key, which is itself encrypted by a root key that AWS rotates automatically. You don’t manage any keys. The request header is x-amz-server-side-encryption: AES256. No per-request KMS API limits to worry about.

SSE-KMS — uses AWS Key Management Service. You can use an AWS-managed KMS key or a customer-managed one. The big advantage here is audit trails — every use of the key is logged in CloudTrail. You also get key policies, grants, and the ability to revoke access or control rotation. The trade-off: KMS has API rate limits, so very high-throughput workloads might hit throttling.

SSE-C — you supply the encryption key with each request. AWS uses it to encrypt/decrypt but never stores your key. TLS is required (HTTPS only). This gives you full control over keys, but you’re responsible for managing and storing them yourself.

Encryption Type Key Management Audit Trail Use Case
SSE-S3 Fully AWS-managed Minimal Default, simple workloads
SSE-KMS KMS (AWS or customer key) CloudTrail logged Compliance, audit, key control
SSE-C You supply per request None from AWS Full key ownership required

For data in transit, TLS/HTTPS is the standard — HTTPS for S3 APIs, TLS for RDS connections, and so on. Client-side encryption is also an option where you encrypt before uploading — AWS never sees the plaintext.

KMS Key Types#

KMS keys come in three ownership models, and knowing the differences matters for exam questions about control and compliance:

AWS Owned Keys — a shared pool of keys managed by AWS. You can’t view, use, or audit them directly. They’re used by some services internally with no customer visibility. Minimal control, minimal audit.

AWS Managed Keys — visible in your account with an alias like aws/s3 or aws/rds. AWS handles rotation automatically (yearly). You can see them in the console and audit their usage, but you can’t change the rotation schedule or key policies.

Customer Managed Keys — full control. You set the rotation schedule, define key policies, create grants, share cross-account, and can disable or schedule deletion. More responsibility, but necessary for strict compliance requirements.

Single-Region vs Multi-Region Keys#

Single-region keys only work in the region where they were created. Simple and sufficient for most use cases.

Multi-region keys can be replicated from a primary to other regions. The replicas share the same key material and key ID, which means you can encrypt data in one region and decrypt it in another without re-encrypting. Useful for disaster recovery scenarios and global applications where data needs to move between regions.

Secrets Management#

AWS has two services for storing secrets and configuration, and the exam loves asking when to use which.

Parameter Store — part of AWS Systems Manager. Stores configuration data and parameters in a hierarchical format. Supports two tiers: Standard (free, up to 10,000 parameters, 4 KB max size) and Advanced (paid, up to 100,000 parameters, 8 KB max, parameter policies). You can optionally encrypt values with KMS. There’s no built-in rotation automation — if you need rotation, you’d have to wire up a Lambda function yourself.

Secrets Manager — purpose-built for secrets that need lifecycle management. It has native rotation support for RDS, Redshift, DocumentDB, and custom services. You define a rotation schedule, and Secrets Manager handles updating the secret and the database credentials automatically. Higher cost per secret than Parameter Store.

The decision rule is straightforward:

  • Dynamic credentials that need rotation → Secrets Manager
  • Static config, feature flags, or large volumes of non-secret parameters → Parameter Store

ACM — TLS Certificates#

AWS Certificate Manager (ACM) issues and auto-renews TLS/SSL certificates for free. Supports public certificates (issued by Amazon’s CA) and private certificates (if you set up a private CA).

ACM certificates can be attached to:

  • Elastic Load Balancers (ALB, NLB)
  • CloudFront distributions
  • API Gateway

You don’t install these on EC2 instances directly — ACM handles the deployment to supported services.

VPC Fundamentals#

A VPC (Virtual Private Cloud) is your private network in AWS. Everything runs inside a VPC, and understanding how VPC networking works is critical for the exam.

IP Types#

  • Private IP — within your VPC CIDR range, routable inside the VPC and peered networks. Stays with the instance for its lifetime.
  • Public IP — auto-assigned from AWS’s pool when you launch in a subnet with auto-assign enabled. Ephemeral — released when you stop the instance.
  • Elastic IP — a persistent public IPv4 address you own. You can remap it to a different instance on failover. But if an Elastic IP isn’t attached to a running instance, AWS charges you for it. They want you to use them, not hoard them.

Public vs Private Subnets#

The distinction is simple:

  • Public subnet — the route table has a route for 0.0.0.0/0 pointing to an Internet Gateway (IGW)
  • Private subnet — no route to an IGW. Outbound internet access goes through a NAT Gateway (or NAT Instance), or the subnet has no internet access at all

Best practice: keep your application and database tiers in private subnets. Only put things that need direct internet access (like a load balancer) in public subnets.

NACLs vs Security Groups#

This comparison comes up all the time. They both filter traffic, but they work differently at different levels.

Security Groups — stateful, attached at the ENI (instance) level:

  • Allow rules only — no explicit deny
  • Rule order doesn’t matter (all rules evaluated)
  • Stateful: if you allow inbound traffic, the return traffic is automatically allowed
  • Commonly used for most filtering

NACLs (Network Access Control Lists) — stateless, applied at the subnet level:

  • Both allow AND deny rules
  • Numbered rules evaluated in order (lowest number wins)
  • Stateless: you need explicit rules for both inbound and return traffic
  • Used for coarse subnet-level filtering or when you need an explicit deny
Feature Security Group NACL
Level ENI (instance) Subnet
State Stateful Stateless
Rules Allow only Allow + Deny
Evaluation All rules Numbered, in order
Return traffic Automatic Must be explicit

Use Security Groups for most things. Use NACLs when you need subnet-wide rules or an explicit deny (which Security Groups can’t do).

NAT Solutions#

Private subnets can’t reach the internet by default. If instances in a private subnet need outbound internet access (for updates, API calls, etc.), you need a NAT solution.

NAT Gateway — the managed option. AWS handles availability, scaling, and patching. Supports up to 45+ Gbps. Deployed per-AZ (you need one in each AZ for high availability). Charges hourly plus per-GB of data processed.

NAT Instance — an EC2 instance you configure as a NAT device. You handle patching, scaling, and high availability yourself. You also need to disable the source/destination check on the instance. Cheaper for very low throughput scenarios, but more operational overhead.

Unless you’re extremely cost-sensitive with minimal traffic, use NAT Gateway.

Connecting to AWS#

This section covers how different networks connect to each other in AWS. There are several options depending on the use case.

VPC Peering — a direct connection between two VPCs. They can be in different accounts or regions. Important: peering is non-transitive. If VPC A peers with VPC B, and VPC B peers with VPC C — A cannot reach C through B. You’d need a direct peering between A and C. This means full mesh gets complex fast with many VPCs.

PrivateLink (Interface Endpoints) — lets you expose or consume services privately over the AWS network using ENIs. No route table changes needed in the consumer VPC. Great for publishing internal services to other VPCs without exposing them to the internet, or accessing AWS services privately.

Gateway Endpoints — specifically for S3 and DynamoDB. Instead of going through the internet, a gateway endpoint adds a route table entry that sends traffic directly to the service over the AWS network. Free to use. Only works for S3 and DynamoDB.

Direct Connect — a dedicated, private network link from your on-premises data center to AWS. Lower latency and more predictable bandwidth than going over the public internet. Takes weeks to set up (it’s a physical connection). Used when you need consistent network performance or when you’re moving large amounts of data.

Transit Gateway — a hub-and-spoke routing service. Instead of creating peering connections between every pair of VPCs, you connect all VPCs to a central Transit Gateway and it handles the routing. Also connects to VPNs and Direct Connect. Supports multicast and route domains. Combine Transit Gateway with Direct Connect for centralized distribution of on-premises connectivity across all your VPCs.

Solution Use Case Key Trait
VPC Peering Two VPCs need to talk Non-transitive
PrivateLink Private service access via ENIs No route table complexity
Gateway Endpoint Private S3/DynamoDB access Free, route table-based
Direct Connect On-prem to AWS dedicated link Physical connection, low latency
Transit Gateway Hub-and-spoke for many VPCs Replaces full mesh peering

Quick Exam Tips#

Networking and encryption patterns to watch for:

  • “Encrypt S3 with audit trail” → SSE-KMS
  • “Customer manages their own keys” → SSE-C or Customer Managed KMS key (depends on context)
  • “Rotate database credentials automatically” → Secrets Manager
  • “Store application config” → Parameter Store
  • “Private access to S3 without internet” → Gateway Endpoint
  • “Connect on-prem to AWS with dedicated line” → Direct Connect
  • “Many VPCs need to communicate” → Transit Gateway (avoid full mesh peering)
  • “VPC Peering” → remember it’s non-transitive
  • “Stateful vs stateless filtering” → Security Groups (stateful) vs NACLs (stateless)
  • “Explicit deny on network traffic” → NACLs (Security Groups can’t deny)
  • “Multi-region encryption” → Multi-Region KMS keys
  • “NAT for private subnets” → NAT Gateway (managed) unless ultra-cost-sensitive

Wrapping Up Domain 1#

That’s Domain 1 done — all three parts. Looking back at the full scope, the identity section was the densest. There’s a lot of overlap between STS, Cognito, and Identity Center, and understanding when to use each one takes a while to click. The security services were more distinct — each one has a clear lane. And the networking section is the most visual — it helps to draw out the VPC architectures to really see how subnets, route tables, NAT gateways, and endpoints fit together.

Domain 1 is 30% of the exam, and after going through all the material, I can see why. It touches almost everything else — you can’t design a resilient architecture (Domain 2) or a high-performing one (Domain 3) without understanding the security and networking foundations from Domain 1.

Next up in the series: Domain 2 — Design Resilient Architectures.

Series navigation: