Build a Well-Architected AWS Infrastructure

Introduction

30 Second Summary

You know how every building needs a solid foundation before you add walls, plumbing, and wiring? Cloud infrastructure works the same way.

In this project, you will build a secure mini-infrastructure on AWS from scratch, configuring networking, security, and monitoring while connecting every decision to the CLF-C02 exam frameworks.

What You'll Build

A production-style mini-infrastructure with a custom VPC, EC2 instance, S3 bucket, IAM policies, and monitoring alerts, all built by hand in the AWS Console.

By the end of this project, you'll have:

• A custom VPC with public and private subnets, an Internet Gateway, and route tables you configured yourself.
• An EC2 instance secured with least-privilege IAM and security groups, plus an S3 bucket with access controls and encryption.
• CloudWatch alarms and AWS Budgets alerts for monitoring your infrastructure and tracking costs.
• Secret Mission: Add a NAT Gateway to your private subnet and compare the Shared Responsibility Model across different AWS service types.

Are there any prerequisites?

You need an AWS Free Tier account to complete this project. The outline assumes you already have one set up.

Existing familiarity with AWS services like EC2, S3, or Redshift as a user is helpful but not required. This project focuses on configuring infrastructure from scratch rather than using pre-built services.

Understand the Exam Landscape and Conceptual Foundations

You already use AWS services like EC2, S3, and Redshift daily. But using a service and understanding why it's configured a certain way are two very different skills.

The CLF-C02 exam tests conceptual understanding, not implementation. Before you build anything, you need to know the three frameworks that tie every AWS decision together: the exam domains, the Well-Architected Framework, and the Shared Responsibility Model.

In this step, get ready to:

• Map the four CLF-C02 exam domains to the infrastructure you'll build.
• Learn the 6 pillars of the Well-Architected Framework.
• Understand the Shared Responsibility Model and how it shifts across service types.

Map the CLF-C02 exam domains to your project

The CLF-C02 exam is organized into four domains, each with a different weight. Knowing which domains carry the most marks tells you where to focus your energy.

• Review the four exam domains and their percentage weights:

• Domain 1: Cloud Concepts (24%).
• Domain 2: Security and Compliance (30%).
• Domain 3: Cloud Technology and Services (34%).
• Domain 4: Billing, Pricing, and Support (12%).

Domains 2 and 3 together make up 64% of the exam. This project specifically targets both of those domains through hands-on networking, security, and service configuration.

How does this project map to the exam?

The infrastructure you'll build covers all four domains. VPC, EC2, S3, and IAM fall under Domain 3. Security groups, encryption, and bucket policies fall under Domain 2. Budgets and pricing models fall under Domain 4. The Well-Architected Framework and Shared Responsibility Model fall under Domain 1.

Learn the Well-Architected Framework's 6 pillars

The Well-Architected Framework is AWS's guide for building secure, high-performing, resilient, and efficient infrastructure. It's organized into six pillars that you'll reference every time you make a design decision in this project.

• Read through each pillar and its one-sentence definition:

• Operational Excellence — The ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value.
• Security — The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture.
• Reliability — The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it's expected to.
• Performance Efficiency — The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve.
• Cost Optimization — The ability to run systems to deliver business value at the lowest price point.
• Sustainability — The ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload by maximizing the benefits from the provisioned resources and minimizing the total resources required.

Why are there 6 pillars, not 5?

The Sustainability pillar was added in 2021. Older study materials may only reference five pillars. The CLF-C02 exam tests all six, so make sure your study resources are up to date.

You don't need to memorize definitions

The exam tests whether you can identify which pillar a given scenario relates to. As you build infrastructure in the next steps, you'll naturally connect each configuration choice to a pillar. That hands-on connection is far more effective than rote memorization.

Understand the Shared Responsibility Model

The Shared Responsibility Model defines who is responsible for what in AWS. This is one of the most heavily tested concepts on the exam.

• Understand the core split:

• AWS is responsible for security "of" the cloud. This means hardware, software, networking, and facilities that run AWS Cloud services.
• You (the customer) are responsible for security "in" the cloud. This means guest OS, application software, security group configuration, data encryption, and IAM.

The tricky part is that the exact split varies depending on which type of service you use. The more managed the service, the less you are responsible for.

• Review how responsibility shifts across three service types:

• EC2 (Infrastructure as a Service) — You manage the most. You are responsible for the guest OS, patching, application software, security groups, and network configuration.
• S3 and DynamoDB (Abstracted services) — AWS operates the infrastructure, OS, and platform. You manage data, encryption options, and access control (bucket policies, IAM permissions).
• Lambda (Serverless) — AWS handles nearly everything. You manage your code and IAM permissions.

Why does this matter for the exam?

The exam frequently asks "who is responsible for X?" questions. The answer always depends on the service type. For EC2, you patch the OS. For Lambda, AWS patches the OS.

As you configure security groups, IAM policies, and bucket policies in the next steps, you'll be practicing exactly the responsibilities that fall on your side of the model.

You now have the conceptual foundation that ties everything together. Next up, you'll put these frameworks into practice by building a custom VPC from scratch.

Build Your VPC from Scratch

You now understand the conceptual frameworks that underpin every AWS architecture decision. It is time to put that knowledge into practice.

In this step, you will build a VPC from scratch in the AWS Console. This means creating the network, the subnets, the gateway, and the routing rules yourself. No wizards, no shortcuts.

In this step, get ready to:

• Create a custom VPC with a public subnet.
• Attach an Internet Gateway and configure routing.
• Create a private subnet with no internet access.

Create a custom VPC

Every AWS account comes with a default VPC, but it hides how networking actually works. By creating one from scratch, you will understand every component the exam tests.

• In the AWS Console, type VPC into the search bar at the top and select VPC from the results.
• In the left sidebar, click Your VPCs.
• Click the Create VPC button.
• For Resources to create, select VPC only.
• For Name tag, enter WellArchitected-VPC.
• For IPv4 CIDR block, select IPv4 CIDR manual input and enter 10.0.0.0/16.
• Leave all other settings as their defaults.
• Click Create VPC.

Why VPC only instead of the wizard?

AWS offers a "VPC and more" wizard that auto-creates subnets, route tables, and gateways for you. That is great for production speed, but terrible for learning.

The CLF-C02 exam tests whether you understand what each component does and how they connect. Building each piece manually gives you that understanding.

Now create the public subnet inside your new VPC.

• In the left sidebar, click Subnets.
• Click Create subnet.
• For VPC ID, select the VPC you just created (WellArchitected-VPC).
• For Subnet name, enter Public-Subnet.
• For Availability Zone, pick any available zone from the dropdown.
• For IPv4 subnet CIDR block, enter 10.0.1.0/24.
• Click Create subnet.

What is a CIDR block?

A CIDR block defines a range of IP addresses. 10.0.0.0/16 gives your VPC 65,536 addresses. 10.0.1.0/24 carves out 256 of those for the public subnet.

Think of it like a building (the VPC) with floors (the subnets). Each floor gets a portion of the overall address space.

You should now see both WellArchitected-VPC in your VPCs list and Public-Subnet in your Subnets list.

Don't see your VPC or subnet?

Make sure you are in the correct Region. Check the Region selector in the top-right corner of the Console. Your resources only appear in the Region where you created them.

help me find my VPC in the AWS Console

Attach an Internet Gateway and configure routing

A subnet is not public just because you named it "public." It becomes public only when its route table points to an Internet Gateway. Without this gateway, nothing in the subnet can reach the internet.

• In the left sidebar, click Internet gateways.
• Click Create internet gateway.
• For Name tag, enter WellArchitected-IGW.
• Click Create internet gateway.
• You will land on the Internet Gateway details page. Click Actions, then Attach to VPC.
• Select WellArchitected-VPC from the dropdown and click Attach internet gateway.

The Internet Gateway is now attached, but your subnet still cannot reach the internet. You need a route table that sends traffic through the gateway.

• In the left sidebar, click Route tables.
• Click Create route table.
• For Name, enter Public-RT.
• For VPC, select WellArchitected-VPC.
• Click Create route table.

Now add the internet route to this route table.

• On the route table details page, click the Routes tab.
• Click Edit routes.
• Click Add route.
• For Destination, enter 0.0.0.0/0.
• For Target, select Internet Gateway, then select WellArchitected-IGW.
• Click Save changes.

Finally, associate this route table with your public subnet.

• Click the Subnet associations tab.
• Click Edit subnet associations.
• Check the box next to Public-Subnet.
• Click Save associations.

What makes a subnet public?

Three things together make a subnet public: an Internet Gateway attached to the VPC, a route table with a 0.0.0.0/0 route pointing to that gateway, and that route table associated with the subnet.

Remove any one of those pieces and the subnet becomes private. The exam tests this exact understanding.

Verify your setup by checking the Routes tab of Public-RT. You should see two routes: the local route (10.0.0.0/16) and the internet route (0.0.0.0/0 targeting the Internet Gateway).

Route table shows only the local route?

If you only see the 10.0.0.0/16 local route, click Edit routes again and make sure you added 0.0.0.0/0 as the destination with the Internet Gateway as the target.

help me configure my route table to point to my Internet Gateway

Create a private subnet

Your public subnet has a path to the internet. Now you need a private subnet that deliberately has no internet access. Resources here are shielded from direct external traffic.

• In the left sidebar, click Subnets.
• Click Create subnet.
• For VPC ID, select WellArchitected-VPC.
• For Subnet name, enter Private-Subnet.
• For Availability Zone, pick any available zone.
• For IPv4 subnet CIDR block, enter 10.0.2.0/24.
• Click Create subnet.

Why is this subnet private?

You did not associate this subnet with your Public-RT route table. It stays associated with the VPC's default (main) route table, which has no route to an Internet Gateway.

No Internet Gateway route means no direct internet access. That is what makes it private.

Verify by clicking on Private-Subnet, then the Route table tab. You should see only the local route (10.0.0.0/16) with no 0.0.0.0/0 entry.

Private subnet showing an internet route?

If you see a 0.0.0.0/0 route on the private subnet's route table, you may have accidentally associated it with Public-RT. Go to Route tables, select Public-RT, click Subnet associations, and confirm only Public-Subnet is checked.

help me fix my private subnet routing

Your network foundation is complete. You have a VPC with clear separation between public-facing and private resources. Next, you will launch an EC2 instance into this network and lock it down with proper security.

Explore Networking and Global Infrastructure Concepts

You just built a full VPC from scratch with public and private subnets, an Internet Gateway, and route tables. That's real infrastructure.

Now it's time to step back and understand why each piece works the way it does. The CLF-C02 exam doesn't test whether you can click buttons in the console. It tests whether you understand the concepts behind what you just built.

In this step, get ready to:

• Understand what makes a subnet public vs. private and how Security Groups differ from NACLs.
• Map your VPC to AWS global infrastructure concepts like Regions and Availability Zones.
• Connect your networking decisions to the Well-Architected Framework pillars.

Reflect on what makes a subnet public vs. private

You created two subnets in the previous step. One is "public" and one is "private." But what actually makes them different?

• In the AWS Console, navigate to VPC and click Route tables in the left sidebar.
• Select your custom public route table and click the Routes tab.
• Notice the route 0.0.0.0/0 pointing to your Internet Gateway. This single route is what makes the associated subnet "public."
• Now select the main route table (associated with your private subnet) and look at its Routes tab.
• Notice it has no route to an Internet Gateway. That absence is what makes the subnet "private."

What makes a subnet public?

A subnet is public only when its route table has a route to an Internet Gateway. A private subnet simply has no such route. The subnet itself doesn't have a "public" or "private" toggle. It's entirely determined by the route table associated with it.

This is a common exam question. Remember: it's the route table that decides, not the subnet's name or CIDR block.

Beyond subnets, the exam also tests your understanding of two network security layers that protect resources inside your VPC.

What is the difference between Security Groups and NACLs?

Security Groups are stateful. When you allow inbound traffic on a port, the return traffic is automatically allowed. You don't need a separate outbound rule for responses.

NACLs (Network Access Control Lists) are stateless. You must explicitly configure rules for both inbound AND return traffic. If you allow inbound on port 80 but forget an outbound rule, the response never leaves.

The exam loves this distinction. Stateful = Security Groups. Stateless = NACLs.

Map your infrastructure to AWS global concepts

Your VPC doesn't float in space. It lives inside AWS's global infrastructure, and the exam tests whether you understand that hierarchy.

• Look at the top-right corner of your AWS Console. The Region name displayed there (for example, us-east-1) is where your entire VPC lives.
• Click Subnets in the VPC sidebar and look at the Availability Zone column for your subnets. Each subnet exists in a specific Availability Zone.

What are Regions and Availability Zones?

A Region is a geographic area (like US East or EU West) that contains multiple Availability Zones. Each Availability Zone is a physically separate data center with its own power, cooling, and networking.

Regions are fully independent of each other. A failure in one Region does not affect another. Deploying across multiple AZs within a Region provides high availability because if one data center goes down, your resources in other AZs keep running.

Your current infrastructure uses one AZ. In production, you'd spread subnets across at least two AZs for redundancy. The exam expects you to know this pattern.

Connect to the Well-Architected Framework

Every architectural decision you've made so far maps to a pillar of the Well-Architected Framework. Let's trace those connections.

• Think about which pillar your subnet design relates to. Consider these three mappings:

How does your VPC map to the Well-Architected pillars?

Reliability: You could deploy subnets across multiple Availability Zones for fault tolerance. If one AZ fails, resources in the other AZ continue serving traffic.

Security: Your private subnet provides network isolation. Resources placed there cannot be reached directly from the internet. This is defense in depth.

Performance Efficiency: Choosing the right Region reduces latency for your users. If your users are in Europe, deploying in a European Region serves them faster than a US Region.

You'll continue mapping infrastructure decisions to these pillars throughout the project. The exam frequently asks "which pillar does this decision support?" so building this mental model now saves you on exam day.

You now have a solid mental model of how networking, global infrastructure, and the Well-Architected Framework connect. Next up, you'll launch an EC2 instance inside your public subnet and lock it down with proper security.

Launch an EC2 Instance with Proper Security

Your VPC is built and your networking concepts are solid. Now it's time to put something inside that network.

In this step, you'll launch an EC2 instance into your public subnet and lock it down with a security group that follows the principle of least privilege. This is where the Security pillar of the Well-Architected Framework comes to life.

In this step, get ready to:

• Launch a t2.micro EC2 instance in your public subnet.
• Create a security group that only allows SSH from your IP.
• Create a key pair and confirm the instance is running.

Launch a t2.micro instance in your public subnet

You need a compute resource inside your VPC to prove the network actually works. A t2.micro instance is Free Tier eligible and perfect for this purpose.

• In the AWS Management Console, search for EC2 in the top search bar and select the EC2 service.
• From the EC2 dashboard, click Launch instance.
• Under Name and tags, enter WellArchitected-Instance as the name for your instance.
• Under Application and OS Images (Amazon Machine Image), click Quick Start and select Amazon Linux.
• Confirm the AMI shows Amazon Linux 2023 AMI and is marked Free Tier eligible.
• Under Instance type, select t2.micro (also marked Free Tier eligible).

Why t2.micro?

The t2.micro instance type gives you 750 hours per month free for 12 months under the AWS Free Tier. That is enough to keep one instance running 24/7 for a full month at no cost.

Create a security group with least privilege

A security group acts as a virtual firewall for your instance. You want to allow only the traffic you actually need and nothing more.

• Still in the launch wizard, scroll down to Network settings and click Edit.
• For VPC, select the custom VPC you created earlier (with CIDR 10.0.0.0/16).
• For Subnet, select your public subnet (10.0.1.0/24).
• For Auto-assign public IP, select Enable. This gives your instance a public IP address so it can communicate with the internet through your Internet Gateway.
• Under Firewall (security groups), select Create security group.
• Give the security group the name WellArchitected-SG and a description like SSH from my IP only.
• For the inbound SSH rule, change the source from Anywhere to My IP. This restricts SSH access (port 22) to only your current IP address.
• Leave the outbound rules as the default (all traffic allowed).

What is least privilege?

Least privilege means granting only the permissions required to perform a task. By restricting SSH to your IP address, no one else on the internet can even attempt to connect to your instance.

This is a key Security pillar practice and a common CLF-C02 exam topic. The exam tests whether you understand that security groups should be as restrictive as possible.

Create a key pair and verify connectivity

A key pair is what proves your identity when you connect to the instance over SSH. AWS stores the public key on the instance, and you keep the private key.

• Scroll up to Key pair (login) and click Create new key pair.
• Enter WellArchitected-KeyPair as the name.
• For Key pair type, keep RSA selected.
• For Private key file format, choose .pem (for macOS/Linux) or .ppk (for Windows with PuTTY).
• Click Create key pair. The private key file downloads automatically to your computer.

Save your key pair file securely

Store this file somewhere safe. AWS does not keep a copy of your private key. If you lose it, you cannot recover it and will not be able to SSH into your instance.

• Back in the launch wizard, review the Summary panel on the right side.
• Click Launch instance.
• Click the instance ID link in the success notification to navigate to the Instances page.
• Wait for the Instance state column to change from pending to running.
• Confirm a Public IPv4 address appears on the Networking tab of your instance details.

What should I see?

Your instance should show a state of running and display a public IPv4 address (something like 34.242.148.128). This confirms your Internet Gateway and route table are working correctly.

Instance stuck in pending or terminated?

If your instance immediately goes to terminated instead of running, check that you selected the correct VPC and subnet (not the default VPC). Also confirm t2.micro is available in your region.

If you do not see a public IP, verify that Auto-assign public IP was set to Enable in your network settings.

help me troubleshoot my EC2 instance that won't launch or has no public IP

Your instance is live and locked down. Next up, you'll configure IAM with least-privilege policies to control who can access your AWS resources.

Configure IAM with Least Privilege

Your EC2 instance is secured with a tight security group, but security goes beyond network access. You also need to control who can interact with your AWS resources and what they can do.

AWS IAM (Identity and Access Management) lets you define users, groups, and policies that control permissions. The best practice is to assign permissions to groups, then add users to those groups. This way, managing access at scale becomes straightforward.

In this step, get ready to:

• Create an IAM group with a read-only S3 policy attached.
• Create an IAM user and add them to the group.
• Review the policy JSON to understand least privilege in action.

Create an IAM group and user

Instead of attaching permissions directly to individual users, you attach them to a group. Every user in that group automatically inherits the group's permissions.

• In the AWS Console, type IAM into the search bar at the top and select IAM from the results.
• In the left navigation pane, click User groups.
• Click Create group.
• For User group name, type S3ReadOnlyGroup.
• Scroll down to the Attach permissions policies section.
• In the search box, type AmazonS3ReadOnlyAccess and press Enter.
• Select the checkbox next to AmazonS3ReadOnlyAccess.
• Click Create group.

You should see a success message confirming your S3ReadOnlyGroup group has been created.

Why attach policies to groups instead of users?

When a team grows, you add new members to the group and they instantly get the right permissions. If the role changes, you update the group's policy once rather than editing every user individually.

This is the AWS best practice for managing permissions at scale.

Now create an IAM user and add them to your group.

• In the left navigation pane, click Users.
• Click Create user.
• For User name, type a name like s3-reader.
• Leave the Provide user access to the AWS Management Console checkbox unchecked (this user is for demonstration only).
• Click Next.
• On the Set permissions page, select Add user to group.
• Select the checkbox next to S3ReadOnlyGroup.
• Click Next.
• Review the summary, then click Create user.

You should see a success notification confirming the user has been created and added to S3ReadOnlyGroup.

Don't see AmazonS3ReadOnlyAccess in the policy list?

Make sure you typed the full policy name AmazonS3ReadOnlyAccess in the filter box. AWS managed policies have specific names. If you still cannot find it, try clearing the search box and scrolling through the list of AWS managed policies.

help me find the AmazonS3ReadOnlyAccess policy in the IAM console

Review the policy JSON to understand least privilege

The AmazonS3ReadOnlyAccess policy you just attached defines exactly what this group can do. Let's look at the actual permissions it grants.

• In the left navigation pane, click User groups.
• Click on S3ReadOnlyGroup to open the group details.
• Select the Permissions tab.
• Click on the policy name AmazonS3ReadOnlyAccess to view its details.
• Look at the JSON policy document.

The policy allows s3:Get* and s3:List* actions on all S3 resources. This means the user can read and list objects, but cannot upload, delete, or modify anything.

What is least privilege?

Least privilege means granting only the minimum permissions needed to perform a task. A user who only needs to read S3 data gets read-only access. They cannot accidentally (or maliciously) delete your files.

On the CLF-C02 exam, expect questions about why least privilege matters and how to implement it using IAM groups and policies.

Relate IAM to the Shared Responsibility Model

You just configured IAM users, groups, and policies. Under the Shared Responsibility Model, this is squarely your responsibility.

AWS provides the IAM service itself (the infrastructure, the API, the console). But how you configure users, groups, policies, and MFA is entirely on you.

Where does IAM fall in the Shared Responsibility Model?

AWS is responsible for security "of" the cloud: the hardware, software, networking, and facilities that run AWS Cloud services.

You are responsible for security "in" the cloud: guest OS configuration, application software, security group rules, data encryption, and IAM configuration.

The exam frequently tests this distinction. If a question asks who is responsible for creating IAM policies or enabling MFA, the answer is always the customer.

How does responsibility change across service types?

With EC2 (Infrastructure as a Service), you manage the most: guest OS, application software, security groups, and IAM.

With abstracted services like S3 or DynamoDB, AWS manages the infrastructure and operating system. You manage data, encryption options, and IAM permissions.

With serverless services like Lambda, AWS handles nearly everything. You manage your code and IAM permissions.

Your IAM is configured with least privilege. Next up, you'll create an S3 bucket and secure it with encryption and a bucket policy that enforces HTTPS.

Create and Secure an S3 Bucket

Your networking and compute layers are locked down. Now it's time to add storage to your infrastructure.

S3 is one of the most tested services on the CLF-C02 exam. In this step, you'll create a bucket with secure defaults, enforce HTTPS-only access with a bucket policy, and understand how the Shared Responsibility Model shifts when you use an abstracted service like S3 instead of an infrastructure service like EC2.

In this step, get ready to:

• Create an S3 bucket with encryption and upload a test file.
• Add a bucket policy that enforces HTTPS-only access.
• Understand S3 in the Shared Responsibility Model.

Create an S3 bucket with default encryption

Every object you store in S3 lives inside a bucket. You'll create one with secure defaults that protect your data both at rest (encryption) and from public exposure.

• In the AWS Console, search for S3 in the top search bar and select S3.
• Click Create bucket.
• Enter a unique bucket name. Bucket names are globally unique across all AWS accounts, so include your name or a random string (e.g. my-secure-bucket-yourname-2026).
• Leave Block all public access checked. This is the secure default that prevents accidental public exposure of your data.
• Under Default encryption, confirm that Server-side encryption with Amazon S3 managed keys (SSE-S3) is selected. This encrypts every object stored in the bucket at rest.
• Leave all other settings as defaults and click Create bucket.

What is SSE-S3?

SSE-S3 means Amazon manages the encryption keys for you. Every object is encrypted with a unique key, and that key itself is encrypted with a root key that AWS regularly rotates.

This is encryption at rest. It protects your data if the underlying physical storage were ever compromised.

Now upload a test file so you have an object to work with.

• Click your new bucket name to open it.
• Click Upload.
• Click Add files and select any small file from your computer (a text file or image works fine).
• Click Upload.
• You should see a green success banner confirming the upload.

Seeing a permissions error?

Make sure you're signed in with your root account or an IAM user that has S3 permissions. The IAM user you created in the previous step only has read-only access, so use your main account for bucket creation.

help me troubleshoot S3 bucket creation permissions

Add a bucket policy to enforce HTTPS

Encryption at rest protects stored data. Encryption in transit protects data while it travels over the network. You'll now add a bucket policy that denies any request not using HTTPS.

• Inside your bucket, click the Permissions tab.
• Scroll down to Bucket policy and click Edit.
• Copy the following policy and paste it into the policy editor. Replace DOC-EXAMPLE-BUCKET with your actual bucket name in both lines:

{
    "Id": "ExamplePolicy",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSSLRequestsOnly",
            "Action": "s3:*",
            "Effect": "Deny",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ],
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            },
            "Principal": "*"
        }
    ]
}

What does this policy do?

This policy uses the aws:SecureTransport condition key to check whether a request was made over HTTPS. If the value is false (meaning HTTP was used), the policy denies all S3 actions on your bucket.

The Principal is set to * so this applies to everyone. The Resource includes both the bucket itself and all objects inside it (/*).

• After pasting and replacing the bucket name, click Save changes.
• You should see the policy appear under the Bucket policy section on the Permissions tab.

Seeing a policy error on save?

Double-check that you replaced DOC-EXAMPLE-BUCKET in both lines with your exact bucket name. The bucket name in the ARN must match your bucket precisely. Also confirm there are no trailing commas or missing brackets in the JSON.

help me fix my S3 bucket policy syntax error

Why enforce HTTPS at the bucket level?

The CLF-C02 exam frequently tests encryption in transit. A bucket policy is a resource-based policy attached directly to the S3 bucket. It enforces rules regardless of which IAM user or role makes the request.

This is different from IAM policies, which are attached to users or roles. Bucket policies protect the resource itself.

Understand S3 in the Shared Responsibility Model

S3 is what AWS calls an abstracted service. The responsibility split is different from EC2.

• AWS manages: the infrastructure, operating system, and platform that S3 runs on. You never see or patch an S3 server.
• You manage: data management, encryption choices, access control (bucket policies and IAM), and classifying your assets.

How does this compare to EC2?

With EC2 (an infrastructure service), you also manage the guest operating system, application software, and security group configuration. That's more responsibility.

With S3, AWS handles all of that lower-level work. Your responsibility starts at the data layer: what you store, who can access it, and how it's encrypted. The exam tests this distinction frequently.

Think about what you just configured in this step. You chose SSE-S3 encryption (your responsibility to enable). You wrote a bucket policy enforcing HTTPS (your responsibility to configure access control). AWS handled everything underneath: the storage hardware, the network, and the S3 platform software.

Your S3 bucket is now encrypted at rest and enforces HTTPS in transit. Next up, you'll add monitoring and billing alerts to round out the operational excellence and cost optimization pillars.

Set Up Monitoring and Billing Alerts

Your infrastructure is secured with IAM policies and bucket controls. But how do you know if something goes wrong, or if costs start creeping up unexpectedly?

In this step, you'll set up proactive monitoring and billing alerts. These give you visibility into resource health and spending before problems escalate.

In this step, get ready to:

• Create a CloudWatch alarm on your EC2 instance's CPU usage.
• Set up an AWS Budget to catch unexpected charges.
• Learn the key monitoring service distinctions for exam day.

Create a CloudWatch alarm

CloudWatch collects metrics from your AWS resources automatically. You'll create an alarm that watches your EC2 instance's CPU usage and emails you if it spikes above 80%.

• In the AWS Console search bar, type CloudWatch and select the CloudWatch service.
• In the navigation pane on the left, choose Alarms, then All alarms.
• Click Create alarm.
• Click Select metric.
• In the All metrics tab, choose EC2.
• Choose Per-Instance Metrics.
• Find the row with your instance's ID in the InstanceId column and CPUUtilization in the Metric Name column. Select the checkbox next to it.
• Click Select metric.

You'll now see the Specify metric and conditions page.

• Under Statistic, choose Average.
• Under Period, choose 5 minutes.
• Under Conditions, for Threshold type, choose Static.
• For Whenever CPUUtilization is, choose Greater.
• Under than..., enter 80.
• Click Next.

Now you'll configure who gets notified when the alarm triggers.

• Under Notification, select In alarm.
• Choose Create new topic to create a new SNS topic.
• Enter a topic name (e.g. CPU-Alarm-Topic).
• Enter your email address in the Email endpoints field.
• Click Create topic.
• Click Next.
• Enter a name for your alarm (e.g. High-CPU-Alarm).
• Click Next.
• Review your settings under Preview and create, then click Create alarm.

What does this alarm do?

This alarm watches the average CPU usage of your EC2 instance every 5 minutes. If it exceeds 80% for one evaluation period, it transitions to the ALARM state and sends an email via your SNS topic.

This maps to the Operational Excellence pillar of the Well-Architected Framework. You're gaining insight into your workload's operations so you can respond before users are affected.

• Check your email inbox for a subscription confirmation from AWS. Click Confirm subscription in the email.

Don't see a confirmation email?

Check your spam or junk folder. The email comes from no-reply@sns.amazonaws.com. If you don't confirm the subscription, you won't receive alarm notifications.

Help me troubleshoot my CloudWatch alarm email subscription.

Create a budget in AWS Budgets

AWS Budgets lets you set custom spending thresholds so you get notified before costs pile up. You'll create a $1 budget to catch any unexpected charges from this project.

• In the AWS Console search bar, type Budgets and select AWS Budgets (under Billing and Cost Management).
• Click Create budget.
• Under Budget setup, choose Customize (advanced).
• Under Budget types, choose Cost budget. Then click Next.
• For Budget name, enter a name like My-Monthly-Budget.
• For Period, choose Monthly.
• For Budget renewal type, choose Recurring budget.
• For Budgeting method, choose Fixed.
• Enter 1 as the budgeted amount (this is $1 per month).
• Click Next.

Now configure the alert threshold.

• Click Add an alert threshold.
• Under Set alert threshold, for Threshold, enter 80.
• Next to the amount, choose % of budgeted amount.
• Next to the threshold, choose Actual to alert on actual spend.
• Enter your email address in the notification field.
• Click Next.
• Skip the Attach actions page by clicking Next again.
• Review your budget settings, then click Create budget.

Why set a $1 budget?

A $1 threshold is deliberately low to catch any unexpected charges early. Everything in this project is Free Tier eligible, so you should stay at $0. If something triggers a charge (like a NAT Gateway in the Secret Mission), this alert will notify you immediately.

This maps to the Cost Optimization pillar of the Well-Architected Framework. You're running systems to deliver business value at the lowest price point.

Don't see Budgets in your console?

If you're using an IAM user rather than the root account, you may not have billing access. The root account owner needs to enable IAM access to billing information in the account settings.

Help me get access to AWS Budgets from my IAM user.

Relate monitoring to exam concepts

The CLF-C02 exam frequently tests whether you can distinguish between AWS monitoring and management services. These are commonly confused, so let's lock in the differences.

What is the difference between CloudWatch, CloudTrail, AWS Config, Cost Explorer, and AWS Budgets?

• CloudWatch = metrics, logs, and alarms. It monitors your resources in real time (CPU usage, network traffic, custom metrics).
• CloudTrail = API call history. It records who did what and when, providing an audit trail of every action taken in your account.
• AWS Config = configuration compliance history. It tracks how your resource configurations change over time and whether they meet compliance rules.
• Cost Explorer = spend analysis and forecasting. It helps you visualize, understand, and manage your AWS costs over time.
• AWS Budgets = threshold alerts for spending. It notifies you when your costs cross a limit you defined.

A helpful way to remember: CloudWatch watches your resources. CloudTrail tracks your people. AWS Config checks your compliance. Cost Explorer shows your past spending. AWS Budgets warns about your future spending.

Why do exam questions confuse these services?

CloudWatch and CloudTrail both start with "Cloud" and relate to visibility, but they track completely different things. CloudWatch monitors performance metrics (how your resources behave). CloudTrail monitors API activity (who changed what). The exam tests this distinction repeatedly.

Similarly, Cost Explorer and AWS Budgets both relate to money but serve different purposes. Cost Explorer is for analysis (looking back at what you spent). AWS Budgets is for alerts (proactively warning you before you overspend).

Your infrastructure is now monitored and cost-protected. Next up, you'll bring everything together in a final conceptual review that maps every action back to the CLF-C02 exam domains.

Review Exam Readiness and Key Concepts

You now have a complete, secure infrastructure running in AWS. You built a VPC from scratch, locked down an EC2 instance, configured IAM with least privilege, secured an S3 bucket, and set up monitoring and billing alerts.

In this final step, you'll connect every action you took to the CLF-C02 exam domains. This is where hands-on experience transforms into exam-ready knowledge.

In this step, get ready to:

• Map your infrastructure to the four CLF-C02 exam domains.
• Review commonly confused service pairs that appear on the exam.
• Learn the four EC2 pricing models and when to use each one.

Map every action you took to an exam domain

The CLF-C02 exam has four domains, each weighted differently. Every piece of infrastructure you built maps directly to one of these domains.

• Think about which domain each resource belongs to. Use the mapping below as your reference.

How does your infrastructure map to exam domains?

Domain 3: Cloud Technology and Services (34%) covers everything you built hands-on. Your VPC, EC2 instance, S3 bucket, and IAM configuration all live here. This is the largest domain at 34%.

Domain 2: Security and Compliance (30%) covers the security decisions you made. Your security groups, IAM policies, S3 encryption, and bucket policies enforcing HTTPS all map here.

Domain 4: Billing, Pricing, and Support (12%) covers your AWS Budgets alert and Free Tier awareness. Domain 1: Cloud Concepts (24%) covers the Well-Architected Framework and Shared Responsibility Model you learned throughout this project.

Domains 2 and 3 are 64% of the exam

Security and Compliance (30%) plus Cloud Technology and Services (34%) together make up 64% of the CLF-C02 exam. The infrastructure you built in this project directly targets both of these high-weight domains.

Review high-yield service pairs for the exam

The CLF-C02 exam frequently tests whether you can distinguish between services that sound similar but serve different purposes. These commonly confused pairs appear in multiple-choice questions designed to trip you up.

• Review each service pair below. For each one, identify the key difference that separates them.

What are the commonly confused service pairs?

• CloudWatch vs. CloudTrail: CloudWatch monitors resource metrics (CPU, memory, alarms). CloudTrail records API call history for auditing (who did what, when).
• S3 vs. EBS: S3 is object storage (files accessed via HTTP). EBS is block storage attached directly to EC2 instances (like a hard drive).
• Security Groups vs. NACLs: Security Groups are stateful (return traffic automatically allowed). NACLs are stateless (you must explicitly allow return traffic).
• Route 53 vs. CloudFront: Route 53 is a DNS service (translates domain names to IP addresses). CloudFront is a CDN (caches content at edge locations for faster delivery).
• RDS vs. DynamoDB: RDS is managed relational databases (SQL, tables with relationships). DynamoDB is a NoSQL key-value and document database.
• Cost Explorer vs. AWS Budgets: Cost Explorer analyzes and visualizes past spending. AWS Budgets sets threshold alerts to notify you before you overspend.

The stateful vs. stateless trick

Security Groups vs. NACLs is one of the most common exam questions. Remember: Security Groups are stateful (if traffic is allowed in, the response is automatically allowed out). NACLs are stateless (you must write separate inbound and outbound rules). You configured a Security Group in this project.

Understand EC2 pricing models

EC2 pricing is a high-yield exam topic. The CLF-C02 tests whether you can match a business scenario to the correct pricing model.

• Review the four pricing models below. Focus on when you would choose each one.

What are the four EC2 pricing models?

• On-Demand: Pay per second with no commitment. Best for unpredictable workloads, short-term testing, or applications that cannot be interrupted. This is what your t2.micro instance uses right now.
• Reserved Instances: Commit to 1 or 3 years for up to 72% discount. Best for steady-state workloads where you know you need the capacity long-term (e.g., a production database server).
• Spot Instances: Use spare AWS capacity for up to 90% discount, but your instance can be interrupted with 2 minutes notice. Best for fault-tolerant workloads like batch processing, data analysis, or CI/CD builds.
• Savings Plans: Commit to a consistent hourly spend for 1 or 3 years. More flexible than Reserved Instances because the discount applies across instance families and Regions.

How do I match pricing to a scenario on the exam?

When you see a pricing question on the CLF-C02, use this decision process. Ask yourself: Can the workload be interrupted? If yes, Spot Instances give you the biggest discount.

Is the workload steady and predictable for 1+ years? If yes, Reserved Instances or Savings Plans. Is the workload short-term or unpredictable? On-Demand is the safe choice. The exam tests whether you can identify the constraint (interruptibility, commitment length, flexibility) and match it to the right model.

Extra for Experts: Why Savings Plans over Reserved Instances?

Savings Plans were introduced after Reserved Instances to solve a flexibility problem. Reserved Instances lock you into a specific instance type in a specific Region. Savings Plans let you commit to a dollar amount per hour and apply the discount across any instance family, size, OS, or Region. For the exam, know that both offer similar discounts, but Savings Plans are more flexible.

You have now mapped your entire infrastructure to the CLF-C02 exam. Every resource you built, every security decision you made, and every billing tool you configured connects directly to what you will see on exam day.

Secret mission

NAT Gateway and Shared Responsibility Deep Dive

Your private subnet is isolated from the internet. But what if instances in that subnet need to download updates or reach external APIs? A NAT Gateway solves this by letting outbound traffic flow without allowing inbound access. In this mission, you'll add one to your infrastructure and then build a deep comparison of the Shared Responsibility Model across three service types.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. All resources you created are Free Tier eligible, so there are no ongoing costs as long as you stay within Free Tier limits.

Cost warning

Your t2.micro instance uses 750 free hours per month (shared across all t2.micro instances in your account). If you have other EC2 instances running, you may exceed the Free Tier allowance.

The Free Tier expires 12 months after you created your AWS account. After that, all running resources will incur standard charges.

Resources you used:

• Custom VPC with public and private subnets, route tables, and Internet Gateway.
• EC2 instances (public and private t2.micro).
• Security group and key pair.
• IAM user and IAM group (S3ReadOnlyGroup).
• S3 bucket with test file.
• CloudWatch alarm and SNS topic.
• AWS Budget alert.

Keep everything running

No action needed. Choose this if you want to keep practising or exploring your infrastructure.

• Your t2.micro instance is covered by the Free Tier for 750 hours per month (shared across all t2.micro instances in your account).
• Your S3 bucket is covered for up to 5 GB of storage under the Free Tier.
• CloudWatch basic monitoring, the SNS topic, and the AWS Budget are free at this scale.
• Your IAM user and group have no cost.

Pause - I'll come back to this later

Stop your EC2 instances to free up compute hours while keeping all configuration intact.

• In the EC2 console, select your public subnet instance, click Instance state, then Stop instance.
• Repeat for the private subnet instance.
• Stopped instances do not consume compute hours. Your EBS volumes remain attached (included in Free Tier for up to 30 GB).
• All other resources (VPC, S3, IAM, CloudWatch, Budget) remain in place at no cost.
• When you return, select each instance, click Instance state, then Start instance.

Delete - I don't want to use this again

Remove all project resources completely. Follow this order to avoid dependency errors.

Terminate EC2 instances

• In the EC2 console, select both instances (public and private).
• Click Instance state, then Terminate instance.
• Wait until both instances show terminated status before continuing.

Delete the key pair

• In the EC2 console, go to Network & Security then Key Pairs.
• Select your key pair, click Actions, then Delete.

Empty and delete the S3 bucket

• In the S3 console, select your bucket.
• Click Empty, type permanently delete to confirm, then click Empty.
• Once empty, select the bucket again and click Delete.
• Type your bucket name to confirm deletion.

Delete the VPC and networking resources

• In the VPC console, select Your VPCs.
• Select your custom VPC (the one with CIDR 10.0.0.0/16).
• Click Actions, then Delete VPC.
• The console will show you the resources that will be deleted along with the VPC (subnets, route tables, Internet Gateway, and security groups). Confirm the deletion.

Delete the IAM user and group

• In the IAM console, go to Users.
• Select your IAM user and click Delete. Enter the username to confirm.
• Go to User groups, select S3ReadOnlyGroup, and click Delete. Enter the group name to confirm.

Delete CloudWatch alarm and SNS topic

• In the CloudWatch console, go to Alarms, then All alarms.
• Select your CPUUtilization alarm and click Actions, then Delete.
• In the SNS console, go to Topics, select your topic, and click Delete.

Delete the AWS Budget

• In the Billing and Cost Management console, go to Budgets.
• Select your budget and click Delete.

Nice Work!

Nice Work!

Congratulations! You just built a secure AWS infrastructure from scratch and connected every piece to the CLF-C02 exam frameworks.

You've learned how to:

• Built a custom VPC with public and private subnets, an Internet Gateway, and route tables configured from scratch.
• Secured your infrastructure with least-privilege IAM groups, a locked-down security group, and an S3 bucket policy enforcing HTTPS.
• Mapped every configuration decision to the CLF-C02 exam domains, the Well-Architected Framework, and the Shared Responsibility Model.
• Secret Mission: Added a NAT Gateway, verified private subnet routing, and created a Shared Responsibility comparison across EC2, RDS, and Lambda.

Ready to quiz yourself?