A stateless firewall does not track any connection. It checks every packet individually with no memory of previous traffic. Because of this, it needs explicit rules for both directions. If you allow inbound traffic on a stateless system, you must also allow the outbound return path, including the ephemeral port range. AWS Network ACLs (NACLs) are stateless.

NACLs operate at the subnet level and are evaluated in rule number order, from the lowest number to the highest. The first matching rule wins. NACLs can allow or deny traffic. A default NACL allows all inbound and all outbound traffic, and contains no explicit deny rules. All traffic passes because the rules match before reaching the implicit deny at the end. A custom NACL starts with no rules and effectively denies all traffic until you add allow rules.

A stateless design means both inbound and outbound rules must be configured for communication between subnets if the NACL is custom or restrictive. Subnets inside a VPC can communicate freely by default, but custom NACLs can block that communication unless rules are added.

Ephemeral ports are temporary ports used for return traffic, usually in the 1024–65535 range. When using NACLs, you must explicitly allow these ports in the opposite direction for responses to succeed.

In AWS architecture, Security Groups control traffic at the instance level with stateful behavior, while NACLs control traffic at the subnet level with stateless behavior. Understanding both is fundamental for the Solutions Architect Associate exam.

While studying AWS networking, a detailed exploration was carried out on how a Virtual Private Cloud (VPC) is structured and how public subnets communicate with the internet. The focus was on understanding subnet design, routing, and how connectivity is managed securely across multiple Availability Zones.

What Is a VPC?

A Virtual Private Cloud (VPC) is a logically isolated network within the AWS cloud.
Think of it as your own private data center inside AWS, where you control every aspect of the network — including IP address ranges, routing, and access to the internet.

When you create a VPC, AWS gives you:

• A dedicated IP address range (CIDR block)

• The ability to create subnets (small networks within your VPC)

• Control over route tables, security, and connectivity

• Access to gateways that connect your private cloud to the outside world

Essentially, it’s your private slice of AWS’s global network.

Inside the VPC: The Main Components

A typical VPC is divided into several key parts:

1. CIDR Block

This is the range of IP addresses your VPC can use — for example, 10.16.0.0/16.
This means all subnets you create inside the VPC will fall within this IP range.

2. Availability Zones (AZs)

Each AWS region is divided into multiple Availability Zones, which are isolated data centers designed for redundancy and high availability.

In the example diagram, there are three AZs:

• AZ A

• AZ B

• AZ C

Each AZ contains its own set of subnets so that even if one zone fails, your application remains available.

3. Subnets

Subnets are smaller network segments within your VPC. They allow you to group resources based on purpose and security level.

In a standard three-tier architecture, we usually have:

• Web Tier (Public Subnets) → for internet-facing resources (like EC2 web servers).

• App Tier (Private Subnets) → for backend logic and processing.

• Database Tier (Private Subnets) → for secure data storage.

Each subnet is assigned its own CIDR block (for example, 10.16.48.0/20) and exists within one specific AZ.

4. Internet Gateway (IGW)

The Internet Gateway is what allows resources in your VPC to connect to the public internet.
It acts as the bridge between your private AWS network and the outside world.

However, attaching an IGW doesn’t automatically make your instances public — they must also belong to a subnet with a route that directs traffic through the IGW.

5. Route Tables

A Route Table defines how traffic is directed within your VPC.
It contains rules (called routes) that tell the network where to send traffic.

For example:

The 0.0.0.0/0 route is the “default route,” meaning any traffic not destined for inside the VPC goes to the internet.

6. VPC Router

The VPC Router is managed automatically by AWS. It’s responsible for directing traffic according to the rules in your route tables.
Every subnet in a VPC must be associated with a route table — this is how AWS knows where to send packets next.

7. Reserved and Spare Capacity

In the diagram, you might notice “Reserved Tier” and “Spare Capacity for Future AZ.”

• The Reserved Tier is a portion of the IP range kept aside — often used for future expansion or system-level operations.

• The Spare Capacity area is designed to accommodate a new Availability Zone if AWS adds one in the future, ensuring your CIDR layout remains flexible and scalable.

🌐 Public vs Private Subnets

A subnet is considered public if its route table includes a route to the Internet Gateway (0.0.0.0/0).
Instances launched in these subnets can send and receive internet traffic — provided they also have a public IP addressor Elastic IP.

By contrast, a private subnet has no direct route to the internet. Resources in private subnets can still reach the internet, but only through a NAT Gateway, which allows outbound traffic without exposing those instances publicly.

Security in the VPC

Security in a VPC is handled at two main levels:

• Security Groups – These act as virtual firewalls at the instance level, controlling inbound and outbound traffic.

• Network ACLs (NACLs) – These provide an additional layer of control at the subnet level.

This layered approach ensures that even if one control fails, another is in place to protect your infrastructure.

Key Takeaways

• A VPC is your own private section of the AWS network.

• Subnets divide your VPC into smaller, logical zones for organization and security.

• Route Tables decide where traffic goes, both within and outside the VPC.

• An Internet Gateway allows public connectivity, but only if routes and IPs are configured properly.

• The Reserved Tier and spare capacity help prepare for future scaling.

• Security is layered, using both Security Groups and NACLs.

Final Thoughts

Understanding the structure of a VPC is essential for designing secure, scalable, and reliable cloud architectures.
It’s not just about connecting resources — it’s about controlling how data moves and ensuring every component communicates safely and efficiently.

Once the fundamentals of VPC design make sense, it becomes much easier to understand higher-level AWS concepts like NAT Gateways, Load Balancers, VPC Peering, and Transit Gateways — all of which build on these same foundations.

Creating the S3 Bucket

I logged into the AWS Management Console and opened the S3 service.
I clicked “Create bucket,” gave it a unique name, selected a region, and left the default settings for simplicity.
Once I created the bucket, I confirmed that versioning was off and default encryption was disabled so I could manually configure each method later. After creating the bucket, I uploaded three images — one for each encryption type.
Here’s how I implemented them:

Next, I uploaded the second image using SSE-KMS.

I selected “AWS KMS keys (SSE-KMS)” and chose the AWS-managed key from the dropdown.
After uploading, I checked the object details to confirm that AWS KMS had encrypted the file.

Before testing it, I opened the KMS console, located the key used for encryption, and edited its key policy.
I used an inline policy to grant my IAM user explicit permissions to use the key for encryption and decryption.
This step helped me understand how KMS key policies control which users or roles can access encrypted data.

Client-Side Encryption – Encrypting Before Upload

Finally, I tested Client-Side Encryption.
Before uploading the third image, I used a local encryption tool to encrypt it on my machine.
I then uploaded the already-encrypted file to S3.
Since the data was encrypted before leaving my system, AWS only stored the encrypted version — not the key.

After uploading all three files, I opened each object’s Properties tab and verified the encryption type.
S3 clearly displayed the encryption method used for each object, confirming that my setup worked as intended.
This visual confirmation helped me understand how encryption metadata appears in AWS.

What I Learned

By performing this hands-on lab, I gained a deeper understanding of how AWS secures data at rest and how much control each encryption method offers:

• SSE-S3: AWS handles everything automatically.

• SSE-KMS: More granular key management and access control.

• Client-Side Encryption: Maximum control and responsibility.

Encryption isn’t just about compliance — it’s about understanding where your data is protected and who controls the keys. As a Cloud or DevOps Engineer, knowing this is essential for securing cloud workloads and designing compliant architectures.