Chapter 3

Networking, Security, and the Shared Responsibility Model

AWS Certified Cloud Practitioner (CLF-C02) Study GuideBased on the AWS CLF-C02 exam objectives

The network is the first place the cloud becomes real — and the first place security lives or dies.

---

Why This Chapter Matters More Than It Looks

Ask a new AWS learner what the cloud is, and they'll talk about EC2 instances and S3 buckets. Ask an experienced architect what the cloud is, and they'll talk about the network. Every service you've met so far — compute, storage, databases — runs on top of a network. Every security boundary you will ever draw on AWS is drawn on the network. And the exam knows this: roughly a quarter of CLF-C02 questions touch networking and security, and the Shared Responsibility Model shows up constantly because it reframes almost everything else.

The story of this chapter is the story of a simple question: who protects what? On your own hardware, the answer was "you, all of it." In the cloud, the answer is split — AWS handles the foundation, you handle what you put on it. That split is the Shared Responsibility Model, and once you understand it, dozens of exam questions answer themselves.

We'll build the network piece by piece — VPCs, subnets, gateways — then layer security on top of it, and finish with the services that watch, audit, and prove your compliance.

---

Your Own Private Cloud: The VPC

A Virtual Private Cloud (VPC) is your own isolated network inside AWS — a private slice of the AWS cloud that only your resources can see by default. Think of AWS as a giant apartment building. A VPC is your apartment: the walls are yours, you decide who gets a key, and your neighbors can't wander in.

Every AWS region comes with a default VPC already created — it has public subnets in each availability zone, an internet gateway attached, and main route table entries that let resources talk to the internet. It's convenient for experiments, but for real work (and for the exam's way of thinking), you'll build custom VPCs where you control every detail.

A VPC lives in one region and spans all of that region's availability zones. You assign it an IPv4 CIDR block when you create it — for example, 10.0.0.0/16. That gives you 65,536 addresses to carve up. The key rule: a VPC's CIDR block cannot be changed after creation. Choose it carefully. Companies that plan to connect their AWS VPC to their on-premises network must make sure the ranges don't overlap, because overlapping address space makes routing impossible.

Subnets: Dividing Your Apartment Into Rooms

A subnet is a subdivision of your VPC's address range, and — critically — each subnet lives in exactly one availability zone. This is one of the most tested facts in all of networking on this exam. A VPC spans multiple AZs; a subnet sits in one AZ.

Continuing the apartment metaphor: if the VPC is the apartment, subnets are the rooms. And here's why rooms matter: you can put a locked door on a room.

There are two kinds of subnets:

• Public subnets have a route to an internet gateway in their route table. Resources in them — with a public IP address — can talk to the internet directly.
• Private subnets have no such route. Resources in them cannot be reached from the internet, and by default cannot reach out either.

The standard architecture the exam expects you to recognize: web servers (or a load balancer) in public subnets, application servers and databases in private subnets. The database that holds customer records should never be directly reachable from the internet — that's what private subnets are for.

Route Tables: The Building Directory

A route table is a set of rules that tells network traffic where to go. Every subnet is associated with exactly one route table (if you don't specify one, it uses the VPC's main route table). Each rule has a destination (a CIDR block) and a target (where traffic for that destination goes).

The route that makes a subnet "public" looks like this: destination 0.0.0.0/0 (meaning "everywhere") → target igw-xxxx (the internet gateway). That's it. One line in a route table is the difference between public and private.

Internet Gateways: The Front Door

An internet gateway (IGW) is a horizontally scaled, redundant component that allows communication between your VPC and the internet. You attach one IGW per VPC. It's the front door of the apartment — without it, nobody gets in from outside and nobody gets out.

But here's a subtlety the exam tests: attaching an internet gateway is not enough by itself. A resource in a public subnet needs three things to reach the internet: the IGW attached to the VPC, a route to it in the subnet's route table, and a public IP address (or an Elastic IP). Miss any one of the three and it won't work. This "three things" pattern is a classic troubleshooting question.

NAT Gateways: Letting Private Resources Call Out

Private subnets can't reach the internet — but sometimes they need to. Your application server in a private subnet might need to download a software update, or call an external payment API. A NAT gateway (Network Address Translation gateway) solves this: it sits in a public subnet and lets resources in private subnets initiate outbound connections to the internet, while blocking any inbound connections from the internet.

The direction matters. NAT is one-way glass: private resources can reach out, but the internet cannot reach in. This is the difference between a NAT gateway and an internet gateway, and the exam will test whether you know which one to use. "Private instances need to download patches but must not be reachable from the internet" = NAT gateway.

VPC Endpoints: Reaching AWS Services Without the Internet

Here's a scenario the exam is fond of: your private EC2 instances need to read from S3, but company policy says no internet traffic at all — not even through a NAT gateway. A VPC endpoint solves this. It creates a private connection between your VPC and another AWS service (like S3 or DynamoDB) that never leaves the AWS network.

There are two types, but for CLF-C02 you mainly need the concept: a gateway endpoint (for S3 and DynamoDB) is added to your route table, while an interface endpoint (powered by PrivateLink) creates an elastic network interface with a private IP in your subnet for most other services. The exam-level takeaway: VPC endpoints let private resources use AWS services privately, with no internet gateway, no NAT gateway, and no public IPs.

---

The Shared Responsibility Model: Who Protects What

Now the centerpiece of the chapter. AWS and the customer share security duties, and the dividing line is the most important concept in CLF-C02.

AWS is responsible for security OF the cloud: the physical buildings, the hardware, the network infrastructure, the virtualization layer, and the managed services themselves. The customer is responsible for security IN the cloud: their data, their applications, their configurations, their access management.

Picture a house you rent. The landlord (AWS) is responsible for the foundation, the walls, the roof, the locks on the front door of the building. You're responsible for locking your apartment door, deciding who gets a key, and what you keep inside. AWS secures the building; you secure your apartment.

The Sliding Line: IaaS vs PaaS vs SaaS

The customer's share of responsibility shrinks as AWS manages more of the stack:

• IaaS (EC2): You manage the most. AWS handles the physical host and virtualization; you handle the operating system, patches, applications, data, firewall rules, and access. If you don't patch your EC2 instance's OS and it gets compromised, that's on you.
• PaaS (RDS, Elastic Beanstalk): AWS takes over the OS and patching. You still handle your data, your application code, and who can access it.
• SaaS (S3 as a file store, or fully managed services): AWS handles nearly everything below your data. You handle the data itself, who can access it, and encryption choices.

The line slides, but one thing never moves: the customer is always responsible for their data. No matter how managed the service, your data is your responsibility. The exam will ask this directly, sometimes phrased as "which of the following is always the customer's responsibility?" — the answer is data (and access management).

What This Means in Practice

A few scenarios the exam loves:

• Unpatched EC2 instance gets hacked. Customer's fault — patching the guest OS on EC2 is the customer's job.
• Someone guesses an S3 bucket is public and reads the data. Customer's fault — bucket policies and access configuration are the customer's job.
• A physical break-in at an AWS data center. AWS's responsibility — physical security is theirs.
• A zero-day in the hypervisor. AWS's responsibility — the virtualization layer is theirs.
• An employee's AWS credentials are stolen because MFA wasn't enabled. Customer's fault — identity management is always the customer's job.

---

IAM: The Keys to the Kingdom

Identity and Access Management (IAM) is the service that controls who can do what on AWS. If the Shared Responsibility Model is the theory, IAM is the practice. AWS gives you one root account when you sign up — and the single most important security rule on all of AWS is: don't use the root account for daily work.

The root user has unrestricted access to everything and cannot be restricted by policies. If its credentials are compromised, the attacker owns the entire account. Best practice: lock the root credentials away, enable MFA on root, and create individual IAM users or use IAM Identity Center for everyone else.

Users, Groups, and Roles

• IAM users represent people or applications that need long-term access. Each user gets credentials (password for console, access keys for API/CLI).
• IAM groups are collections of users. You attach permissions to the group, and members inherit them. Never attach permissions directly to individual users if you can avoid it — groups are how you manage permissions at scale. When someone changes teams, you move them between groups instead of rewriting their permissions.
• IAM roles are identities with permissions but no permanent credentials. Roles are assumed temporarily — by an EC2 instance that needs to read from S3, by a Lambda function, or by a person federating in from a corporate directory. Roles are the secure way to grant access to AWS resources because no long-lived secret keys are involved.

Policies: The Permission Documents

IAM policies are JSON documents that define permissions. They answer two questions: what actions are allowed (or denied), and on which resources. A policy might say "allow s3:GetObject on the bucket called customer-invoices."

Two critical rules:

1. Default deny. By default, an IAM identity can do nothing. Permissions must be explicitly granted. (An explicit deny always overrides an allow.)
2. Least privilege. Grant only the permissions needed to do the job — nothing more. This is the single most repeated security principle on the exam. If a question asks for the "best practice" for IAM permissions, the answer is almost always least privilege.

AWS provides managed policies (prebuilt, like ReadOnlyAccess or PowerUserAccess) and lets you write custom policies for fine-grained control.

MFA: The Cheapest Security Upgrade on Earth

Multi-factor authentication requires a second factor — typically a code from a phone app or hardware token — in addition to the password. Enable MFA on the root account and on all IAM users with console access. The exam treats MFA as the obvious answer whenever a question involves protecting privileged accounts or "adding an extra layer of authentication."

Credential Hygiene: Access Keys and What Not to Do

IAM users can have two kinds of credentials: a password for the console, and access keys for the API/CLI. Access keys are powerful and dangerous — anyone holding them can act as that user from anywhere. Best practices the exam expects you to know:

• Never embed access keys in application code. Use roles instead.
• Rotate access keys regularly and delete unused ones.
• Never share credentials between people — each human gets their own IAM user.
• If a key is ever exposed (pasted into a public code repository is the classic horror story), deactivate and delete it immediately and check CloudTrail for what was done with it.

IAM Access Analyzer helps here too: it identifies resources shared with external entities and flags unused access, so you can tighten permissions toward least privilege.

---

Security Groups vs NACLs: Two Layers of Firewall

AWS gives you two different firewall layers, and confusing them is one of the most common exam mistakes. They work at different levels and behave differently.

Security Groups: The Bouncer at the Instance Door

A security group acts as a virtual firewall for your instances — it controls inbound and outbound traffic at the instance level. Key properties:

• Stateful. If you allow inbound traffic, the return traffic is automatically allowed, even if no outbound rule permits it. The security group "remembers" the conversation.
• Allow rules only. You cannot write a deny rule in a security group. Everything not explicitly allowed is denied.
• Evaluated as a whole. All rules are checked together; the most permissive matching rule wins.

You attach security groups to ENIs (network interfaces) — effectively to instances. A typical web server security group allows inbound HTTP (port 80) and HTTPS (port 443) from anywhere, SSH (port 22) only from your office IP, and all outbound traffic.

NACLs: The Bouncer at the Subnet Door

A network access control list (NACL) acts as a firewall at the subnet level — it controls traffic entering and leaving an entire subnet. Key properties, and note how each is the opposite of security groups:

• Stateless. Return traffic must be explicitly allowed by outbound rules. If you allow inbound port 80, you must also allow the outbound ephemeral ports for the response.
• Allow AND deny rules. NACLs support both, evaluated in numbered order from lowest to highest.
• Applied to the subnet, affecting every instance in it.

Think of it as two checkpoints: the NACL guards the hallway (subnet), the security group guards the apartment door (instance). Traffic must pass both.

---

WAF, Shield, and DDoS Protection

AWS WAF: The Web Application Firewall

AWS WAF protects web applications from common web exploits — SQL injection, cross-site scripting (XSS), and similar Layer-7 attacks. You attach WAF to CloudFront distributions, Application Load Balancers, or API Gateway, and write rules (or use AWS managed rule groups) to block malicious request patterns.

The mental model: security groups and NACLs filter by IP and port (Layers 3–4). WAF inspects the actual content of web requests (Layer 7). A SQL injection attack arrives over perfectly legitimate port 443 — only something that reads the request body can catch it.

AWS Shield: DDoS Protection

A distributed denial-of-service (DDoS) attack floods your application with traffic to overwhelm it. AWS Shield provides the defense:

• Shield Standard is automatically enabled for all AWS customers at no extra cost. It protects against common network and transport layer DDoS attacks.
• Shield Advanced is a paid service with enhanced detection, 24/7 DDoS response team access, and cost protection against scaling charges during an attack.

Why does DDoS protection matter at the network layer specifically? Because a volumetric attack doesn't care about your application logic — it saturates the pipes. Shield operates where AWS controls the network fabric, absorbing attack traffic before it reaches your resources. That's also why Shield Standard can be free and automatic: it protects the shared infrastructure itself, squarely in AWS's "security of the cloud" territory.

---

Encryption and Key Management

KMS: Who Holds the Keys

AWS Key Management Service (KMS) is the managed service for creating and controlling cryptographic keys. You use KMS keys to encrypt data in S3, EBS, RDS, and dozens of other services. The important concepts:

• Envelope encryption: your data is encrypted with a data key, and the data key is encrypted with your KMS key. You never handle raw keys directly.
• You control the keys: you decide who can use them via IAM policies and key policies, you can rotate them, and you can disable or delete them (disabling a key makes the data it protects unreadable — a fact the exam occasionally tests).
• AWS managed vs customer managed keys: AWS can manage keys for you, or you can create and control your own for full auditability.

CloudHSM (Know It Exists)

AWS CloudHSM provides dedicated hardware security modules in the AWS cloud for customers who need their own single-tenant key storage (often for regulatory reasons). For CLF-C02, just know: KMS is multi-tenant and managed; CloudHSM is single-tenant hardware you control.

---

Watching Everything: CloudTrail vs CloudWatch

Two services with confusingly similar names that do completely different things. The exam tests this distinction relentlessly.

CloudTrail: Who Did What

AWS CloudTrail records API activity — every action taken in your account, who took it, when, and from where. "Which IAM user deleted that S3 bucket at 3 AM?" That's a CloudTrail question. CloudTrail is your audit log: it's about accountability and governance, and you enable it so you always have a record.

CloudWatch: How Are Things Performing

Amazon CloudWatch monitors metrics and logs — CPU utilization, network traffic, disk reads, application logs. You build dashboards, set alarms ("notify me if CPU exceeds 80% for 5 minutes"), and trigger automated responses. CloudWatch is about operational health.

The one-line distinction: CloudTrail tracks API calls (who did what); CloudWatch tracks performance (how things are running).

AWS Config: The Compliance Recorder

AWS Config records the configuration history of your resources — what your security group rules were last Tuesday, when that S3 bucket's encryption setting changed. While CloudTrail records who changed what, Config records what the configuration was at any point in time. Use Config for compliance auditing and answering "what changed?"

Config also powers conformance packs and Config rules: automated checks like "all EBS volumes must be encrypted" or "no security group may allow SSH from 0.0.0.0/0." When a resource drifts out of compliance, Config flags it — and can even auto-remediate. The exam-level distinction: CloudTrail = API activity log; Config = resource configuration timeline plus compliance rules.

Penetration Testing: Ask First (Mostly)

One security topic that surprises newcomers: you are allowed to penetration-test your own AWS resources, but there are boundaries. AWS permits testing against most of its services without prior approval, with a short list of prohibited activities (like DNS zone walking or denial-of-service testing, which could affect other customers). The exam occasionally asks whether permission is required — the safe answer is that AWS has a defined penetration testing policy, and certain test types remain prohibited.

---

Trusted Advisor and the Well-Architected Habit

AWS Trusted Advisor

Trusted Advisor is like an automated consultant that inspects your AWS environment and flags best-practice violations across categories: cost optimization (idle resources), performance, security (open security groups, MFA on root), fault tolerance, and service limits. The free tier includes core checks; the full set of checks requires a Business or Enterprise support plan.

AWS Artifact: Proof of Compliance

AWS Artifact is the portal where you download AWS compliance reports and certifications — SOC, PCI DSS, ISO, HIPAA attestations. When your auditor asks "prove AWS is compliant," you don't email AWS — you download the report from Artifact. Remember: Artifact is about AWS's compliance documentation, which supports your compliance story under the Shared Responsibility Model.

Artifact has two parts worth knowing: Artifact Reports (the downloadable third-party audit reports) and Artifact Agreements (for reviewing and accepting agreements such as the Business Associate Addendum for HIPAA workloads). For CLF-C02, the key association is simply: compliance reports → Artifact.

---

Putting It All Together: A Secure Three-Tier VPC

Let's assemble everything in this chapter into the architecture the exam wants you to picture:

1. A VPC (10.0.0.0/16) spanning two availability zones.
2. Public subnets in each AZ with a route to the internet gateway — home to an Application Load Balancer.
3. Private subnets in each AZ — home to EC2 application servers, reaching the internet for patches through a NAT gateway in the public subnet.
4. Database subnets (private, no NAT route needed) — home to RDS, reachable only from the app servers.
5. Security groups on each tier allowing only the necessary traffic (least privilege): the ALB accepts 443 from anywhere; app servers accept traffic only from the ALB's security group; the database accepts traffic only from the app servers' security group.
6. NACLs on the subnets as a second, stateless layer.
7. IAM roles on the EC2 instances (no hardcoded keys), MFA on all human users.
8. CloudTrail logging every API call, CloudWatch alarming on anomalies, Config recording configuration history.
9. WAF on the ALB blocking SQL injection; Shield Standard absorbing DDoS automatically.

Every piece of this chapter appears in that architecture. When an exam question describes part of it, you'll know exactly which service fits where — because you know why each one exists.

---

Chapter Summary

• A VPC is your isolated network in one region; subnets live in a single AZ; route tables determine public vs private; internet gateways connect to the internet; NAT gateways let private resources reach out without being reachable.
• Shared Responsibility: AWS = security of the cloud (physical, hardware, network, virtualization). Customer = security in the cloud (data, apps, OS patching on EC2, firewall config, IAM). Data is always the customer's responsibility.
• IAM: don't use root; users for people, groups for permission management, roles for temporary access (especially EC2 → AWS services); policies grant permissions; default deny; least privilege; MFA everywhere.
• Security groups = stateful, instance-level, allow-only. NACLs = stateless, subnet-level, allow + deny, numbered rules.
• WAF blocks web exploits (SQLi, XSS) at Layer 7. Shield (Standard free/automatic, Advanced paid) protects against DDoS.
• KMS manages encryption keys; CloudHSM for single-tenant hardware key storage.
• CloudTrail = API audit log (who did what). CloudWatch = metrics and alarms (how things perform). Config = configuration history.
• Trusted Advisor flags best-practice issues; Artifact provides AWS compliance reports.

---

End-of-Chapter Test

1. A company wants to ensure its database servers cannot be reached directly from the internet. Where should the database servers be placed? A. In a public subnet with a restrictive security group B. In a private subnet with no route to an internet gateway C. In a public subnet behind a NAT gateway D. In the default VPC with default settings

2. Under the AWS Shared Responsibility Model, which of the following is ALWAYS the customer's responsibility? A. Physical security of data centers B. Patching the hypervisor C. Protecting customer data stored in AWS D. Maintaining network infrastructure

3. An application running on an EC2 instance needs to read files from an S3 bucket. What is the MOST secure way to grant this access? A. Embed an IAM user's access key in the application code B. Attach an IAM role to the EC2 instance with S3 read permissions C. Make the S3 bucket public D. Share the root account credentials with the application

4. Which statement correctly describes the difference between security groups and NACLs? A. Security groups are stateless and NACLs are stateful B. Security groups operate at the subnet level and NACLs at the instance level C. Security groups are stateful and allow-only; NACLs are stateless and support allow and deny rules D. Security groups support deny rules and NACLs do not

5. A company needs to allow its private EC2 instances to download software updates from the internet, but the instances must NOT be directly reachable from the internet. Which should they use? A. An internet gateway B. A NAT gateway C. A VPC peering connection D. A second public subnet

6. Which AWS service records API calls made in an account for auditing purposes? A. Amazon CloudWatch B. AWS CloudTrail C. AWS Config D. AWS Trusted Advisor

7. A web application is experiencing SQL injection attacks. Which AWS service should be used to block these attacks? A. AWS Shield B. Security groups C. AWS WAF D. Network ACLs

8. What is the primary purpose of enabling MFA on the AWS root account? A. To reduce the cost of the account B. To add an additional layer of authentication protecting the most privileged account C. To allow multiple users to share the root account D. To enable API access for the root account

9. A company needs dedicated, single-tenant hardware for cryptographic key storage to meet compliance requirements. Which service should they use? A. AWS KMS B. AWS CloudHSM C. AWS Secrets Manager D. IAM

10. Which AWS service provides automated checks and recommendations for cost optimization, security, and fault tolerance best practices? A. AWS Artifact B. AWS Trusted Advisor C. Amazon Inspector D. AWS Systems Manager

---

Answer Key

1. B — Private subnets have no route to an internet gateway, so resources in them cannot be reached from the internet. A security group alone (A) doesn't change the subnet's routing. A NAT gateway (C) is for outbound access from private subnets, not for placing databases publicly.

2. C — Customer data is always the customer's responsibility regardless of service model. Physical security (A), hypervisor patching (B), and network infrastructure (D) are AWS's responsibilities under "security of the cloud."

3. B — IAM roles provide temporary credentials to EC2 instances without storing long-lived secrets. Embedding access keys (A) is a security anti-pattern the exam always marks wrong. Public buckets (C) and sharing root credentials (D) are never correct.

4. C — Security groups are stateful, applied at the instance (ENI) level, and support only allow rules. NACLs are stateless, applied at the subnet level, and support both allow and deny rules evaluated in number order.

5. B — A NAT gateway allows outbound-initiated connections from private subnets while blocking inbound connections. An internet gateway (A) would require the instances to be in public subnets with public IPs, making them reachable.

6. B — CloudTrail logs API activity (who did what, when). CloudWatch (A) monitors metrics and performance. Config (C) records configuration history. Trusted Advisor (D) gives best-practice recommendations.

7. C — AWS WAF inspects Layer-7 web traffic and blocks SQL injection and XSS. Shield (A) is for DDoS. Security groups (B) and NACLs (D) filter by IP/port, not request content.

8. B — MFA adds a second authentication factor, critical for the unrestricted root account. It doesn't affect cost (A), sharing root (C) is never recommended, and MFA doesn't enable API access (D).

9. B — CloudHSM provides dedicated single-tenant hardware security modules. KMS (A) is multi-tenant and managed by AWS. Secrets Manager (C) stores secrets but not on dedicated hardware. IAM (D) manages identities, not keys.

10. B — Trusted Advisor inspects your environment and recommends best practices across cost, security, performance, fault tolerance, and service limits. Artifact (A) hosts compliance reports; Inspector (C) scans for vulnerabilities; Systems Manager (D) is for operational management.