← Fundamentals

▶ Play from here · 336 min

Starts this lesson and continues through 31 more to the end of certification prep.

General fundamentals — CIDR and subnets, Nitro, encryption at rest and in transit, DNS and DNSSEC

Why this lesson matters

Four pieces of general IT knowledge that the domain pages use without teaching. Each is named in a task statement (domain pages, fetched 2026-09-25):

What this lesson doesn't repeat: SAA0 lesson 4 covers the VPC and Route 53 FAQs (five reserved addresses, non-transitive peering, routing policies, alias records). SAA1 lessons 3 and 5 cover security groups vs NACLs, NAT, KMS key types and ACM. This lesson is the layer underneath those.

1 · Networking: CIDR, subnets, public vs private

CIDR in one paragraph

From VPC CIDR blocks, fetched 2026-09-25: "The IP addresses for your virtual private cloud (VPC) are represented using Classless Inter-Domain Routing (CIDR) notation."

The arithmetic (this is maths, not an AWS fact): an IPv4 address is 32 bits; in 10.0.0.0/16 the /16 says the first 16 bits are fixed, leaving 32 − 16 = 16 bits free, so the block holds 2¹⁶ = 65,536 addresses. Every +1 on the prefix halves the block.

The worked split, verbatim from Subnet CIDR blocks: "One subnet uses CIDR block 10.0.0.0/25 (for addresses 10.0.0.0 - 10.0.0.127) and the other uses CIDR block 10.0.0.128/25 (for addresses 10.0.0.128 - 10.0.0.255)."

⚠️ Usable ≠ total. "The first four IP addresses and the last IP address in each subnet CIDR block are not available for your use" — so a /28 subnet gives you 11. (SAA0 lesson 4 lists all five.)

VPC CIDR rules

From the VPC CIDR page, verbatim:

• "When you create a VPC, you must specify an IPv4 CIDR block for the VPC. The allowed block size is between a /16 netmask (65,536 IP addresses) and /28 netmask (16 IP addresses)."
• "we recommend that you specify a CIDR block from the private IPv4 address ranges as specified in RFC 1918" — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
• "You cannot increase or decrease the size of an existing CIDR block." But "After you've created your VPC, you can associate additional IPv4 CIDR blocks with the VPC."
• A secondary block "must not overlap with any existing CIDR block that's associated with the VPC."
• "Some AWS services use the 172.17.0.0/16 CIDR range… To avoid conflicts, don't use this range when creating your VPC."

⚠️ This closes an item SAA0's cheat sheet listed as unverified ("CIDR expansion"): you can't resize a block; you can add secondary blocks.

⚠️ Plan for overlap now. The same page: "If the VPC peering connection is active, you can add CIDR blocks to a VPC provided they do not overlap with a CIDR block of the peer VPC", and VPCs on a Direct Connect gateway "must not have overlapping CIDR blocks." Overlapping CIDRs are the most common reason two networks can't be joined later.

Subnets: zonal, and "public" is a routing fact

From Subnets for your VPC, fetched 2026-09-25:

"A subnet is a range of IP addresses in your VPC."

"Each subnet must reside entirely within one Availability Zone and cannot span zones."

"The subnet type is determined by how you configure routing for your subnets."

The types, verbatim:

⚠️ There is no "public" checkbox. A subnet is public because its route table sends traffic to an internet gateway. Change the route, and the same subnet becomes private. An exam option that says "make the subnet private" without touching routes is describing nothing.

The security recommendation, verbatim: "To protect your AWS resources, we recommend that you use private subnets. Use a bastion host or NAT device to provide internet access to resources, such as EC2 instances, in a private subnet."

And the default VPC, from How Amazon VPC works: "If your account was created after December 4, 2013, it comes with a default VPC in each Region. … it has a default subnet in each Availability Zone in the Region, an attached internet gateway, a route in the main route table that sends all traffic to the internet gateway… Therefore, an EC2 instance that is launched in a default subnet automatically has access to the internet."

⚠️ So default subnets are public subnets. "Launched into the default VPC" in a stem that also says "must not be reachable from the internet" is a problem to spot.

The standard tiered layout that Task 3.4 means by "subnet tiers" follows directly: public subnets for the load balancer and NAT, private subnets for application and database, one of each per AZ — because a subnet is zonal (lesson 3).

2 · Virtualisation and Nitro

Task 4.2 names "virtualization" next to instance families. What you need is the vocabulary.

From Instances built on the AWS Nitro System, fetched 2026-09-25:

"The Nitro System is a collection of hardware and software components built by AWS that enable high performance, high availability, and high security."

"Nitro hypervisor - A lightweight hypervisor that manages memory and CPU allocation and delivers performance that is indistinguishable from bare metal for most workloads."

"The Nitro System provides bare metal capabilities that eliminate virtualization overhead and support workloads that require full access to host hardware."

Bare metal is for, verbatim: "Workloads that require access to low-level hardware features (for example, Intel VT) that are not available or fully supported in virtualized environments" and "Applications that require a non-virtualized environment for licensing or support."

⚠️ That second bullet is the exam trigger. "Licensing requires a non-virtualized environment" → bare metal instance.

From the whitepaper The components of the Nitro System: "the Nitro System consists of three primary components: Purpose-built Nitro Cards · The Nitro Security Chip · The Nitro Hypervisor." The Nitro Cards "provide all I/O interfaces, such as those needed to provide software-defined networking, Amazon EBS storage, and instance storage" — which is why EBS and networking don't steal CPU from your instance. And on the hypervisor: "there is, by design, no networking stack, no general-purpose file system implementations, and no peripheral device driver support. … it is not a general-purpose system and includes neither a shell nor any type of interactive access mode."

Tie to lesson 4: "By design the Nitro System has no operator access."

⚠️ The instance-type page is a moving list — it names Nitro v2 through v6 and which families are on each. Don't memorise it; know that current-generation families are Nitro-based and that bare metal exists for the two reasons above.

3 · Encryption at rest vs in transit

Definitions from the Well-Architected Security Pillar, fetched 2026-09-25:

At rest — "Data at rest represents any data that you persist in non-volatile storage for any duration in your workload. This includes block storage, object storage, databases, archives, IoT devices, and any other storage medium on which data is persisted." (Protecting data at rest)

In transit — "Data in transit is any data that is sent from one system to another. This includes communication between resources within your workload as well as communication between other services and your end users." (Protecting data in transit)

The exam guide's own pairing (Task 1.3): at rest → KMS; in transit → ACM using TLS.

What each service does by default, from pages fetched 2026-09-25:

⚠️ EBS encryption covers both. From Amazon EBS encryption: "Encryption operations occur on the servers that host EC2 instances, ensuring the security of both data-at-rest and data-in-transit between an instance and its attached EBS storage." And a one-way door: "You cannot remove encryption from an encrypted volume or snapshot."

⚠️ The SSE-C default change (April 2026) is newer than most study material. If a practice question assumes SSE-C "just works" on a new bucket, the page says otherwise — "applications that need SSE-C encryption must deliberately enable SSE-C by using the PutBucketEncryption API operation."

In transit on S3, verbatim: "You can protect data in transit by using Secure Socket Layer/Transport Layer Security (SSL/TLS)… or client-side encryption." SAA1 lesson 5 covers ACM and the KMS key types; this lesson stops at the definitions.

4 · DNS, and DNSSEC in Route 53

DNS vocabulary, from Route 53's own glossary

From Amazon Route 53 concepts, fetched 2026-09-25, verbatim:

Route 53 does three jobs, from What is Amazon Route 53?: "domain registration, DNS routing, and health checking."

⚠️ TTL is the reason DNS failover is never instant. Resolvers keep the old answer until the TTL expires. That's the setup for SAA2's point that Global Accelerator "avoids caching issues that can occur with DNS systems".

DNSSEC signing — what it protects, and the key split

From Configuring DNSSEC signing in Amazon Route 53, fetched 2026-09-25:

"Domain Name System Security Extensions (DNSSEC) signing lets DNS resolvers validate that a DNS response came from Amazon Route 53 and has not been tampered with. When you use DNSSEC signing, every response for a hosted zone is signed using public key cryptography."

⚠️ Read what that sentence promises: origin and integrity. Nothing on the DNSSEC pages I fetched describes DNSSEC as hiding or encrypting DNS queries. If an option says "enable DNSSEC to encrypt DNS traffic", it's claiming something the Route 53 docs don't.

The key split — examinable, verbatim:

"There are two kinds of keys in DNSSEC: a key-signing key (KSK) and a zone-signing key (ZSK). In Route 53 DNSSEC signing, each KSK is based on an asymmetric customer managed key in AWS KMS that you own. You are responsible for KSK management, which includes rotating it if needed. ZSK management is performed by Route 53."

That is a Shared Responsibility Model in miniature (lesson 4): AWS runs the ZSK; the KSK is yours.

The KMS key requirements, from Working with customer managed keys for DNSSEC:

"The customer managed key that you use with DNSSEC signing must be in the US East (N. Virginia) Region."

"The customer managed key must be an asymmetric customer managed key with an ECC_NIST_P256 key spec."

⚠️ us-east-1 again — consistent with lesson 3's point that Route 53's control plane lives there.

Other constraints on the same page, verbatim:

• "When you enable DNSSEC signing for a hosted zone, Route 53 limits the TTL to one week."
• "When you use DNSSEC signing, multi-vendor configurations are not supported."
• "If your parent zone is hosted by a DNS provider who does not support DS queries… when you enable DNSSEC in its child zone, the child zone will become unresolvable."
• "We strongly recommend that you set up a CloudWatch alarm that alerts you whenever a DNSSECInternalFailure or DNSSECKeySigningKeysNeedingAction error is detected."

The chain of trust

From Enabling DNSSEC signing and establishing a chain of trust: "There are three steps to take to enable DNSSEC signing" — prepare, enable signing and create a KSK, establish chain of trust — and the chain is completed by inserting the Delegation Signer (DS) record in the parent zone. The page recommends first lowering the zone's maximum TTL "to 1 hour (3600 seconds)" so that "You can then roll back after only an hour if any resolver has problems."

⚠️ Signing your zone is half the job. Until the parent zone holds your DS record, resolvers have nothing to validate your signatures against.

DNSSEC validation — the other side

Signing is for zones you host. Validation is for answers your VPC receives. From Enabling DNSSEC validation:

"When you enable DNSSEC validation for a virtual private cloud (VPC) in Amazon Route 53, DNSSEC signatures are cryptographically checked to make sure that the response was not tampered with."

"Enabling DNSSEC validation can impact DNS resolution for public DNS records from AWS resources in a VPC, which could result in an outage."

Check yourself

1. How many addresses in a /20? How many usable in a /28 subnet?
2. What makes a subnet public?
3. You need a larger VPC range. Can you change 10.0.0.0/16 to 10.0.0.0/15?
4. A vendor's licence prohibits running in a virtualized environment. Which EC2 option?
5. In Route 53 DNSSEC signing, which key do you manage, where must its KMS key live, and which key does Route 53 manage?

Answers

1. 4,096 (2¹²). 11 usable in a /28 — 16 minus the five reserved.
2. Its route table — "The subnet has a direct route to an internet gateway." The type "is determined by how you configure routing."
3. No. "You cannot increase or decrease the size of an existing CIDR block." Associate a secondary CIDR block instead (non-overlapping).
4. A bare metal instance — for "Applications that require a non-virtualized environment for licensing or support."
5. You manage the KSK; its KMS key must be asymmetric ECC_NIST_P256 in US East (N. Virginia). Route 53 manages the ZSK.

Teaching this section

• Do CIDR arithmetic on the whiteboard until it's boring. /16, /20, /24, /28 — halve it each time. It pays off in every VPC question for the rest of the course.
• Demo "public is a routing fact": create a subnet, show it's private, add a 0.0.0.0/0 → igw route, show it's now public. Nothing else changed.
• The DNSSEC key split is the Shared Responsibility Model again — point that out; it links lessons 4 and 5.
• Watch for: "DNSSEC encrypts DNS"; "resize the VPC CIDR"; "a /28 has 16 usable addresses"; "the default VPC is private".
• Timing: 30 minutes. CIDR takes 10; don't rush it.