AWS Cloud Security: Securing Cloud Infrastructure

I’m continuing my AWS Cloud Security Foundations journey, and this module shifted my attention from identity and access management to the network itself.

If the previous module was about who gets to do what, this one was about understanding the walls, routes, gates, and checkpoints around where cloud resources actually live.

One of my biggest takeaways is that cloud security is not simply about restricting access. It requires understanding how resources are connected, how traffic moves, and how infrastructure can be designed to operate securely without unnecessary exposure.

Cloud infrastructure brings together compute, networking, storage, and security components that allow applications and services to operate.

I’m beginning to see why security needs to be considered during infrastructure design rather than added after resources have already been deployed.

I explored how applications can be separated into:

• Presentation layer
• Application/business logic layer
• Data layer

Separating these layers can help with security, scalability, organization, and maintenance.

A Virtual Private Cloud (VPC) provides an isolated network environment within AWS.

I worked with concepts such as:

10.0.0.0/16 → VPC CIDR range
10.0.1.0/24 → example subnet range

Understanding CIDR notation also helped me better visualize how larger network ranges can be divided into smaller subnets.

This was one of the concepts that became much clearer through the lab.

A public subnet can have a route to an Internet Gateway, while a private subnet does not have a direct route to the internet.

For private resources that need outbound internet access, a NAT Gateway can provide that connectivity without making the private resource directly reachable from the internet.

I learned how route tables determine where network traffic goes.

For example:

represents a default route for IPv4 traffic when no more specific route applies.

Seeing these routes in an actual VPC made the relationship between subnets, gateways, and traffic flow much easier to understand.

This was probably my biggest networking takeaway.

Security Groups operate at the instance/network-interface level. They are stateful and use allow rules.

Network ACLs operate at the subnet level. They are stateless, support both allow and deny rules, and evaluate rules in numerical order.

The hands-on lab made this distinction much more meaningful because I could actually change the rules, test connectivity, and observe the results.

The practical exercise took me through:

• Examining a VPC and its subnets
• Reviewing route tables and NAT Gateway configuration
• Testing HTTP connectivity between EC2 instances
• Restricting access using a specific private IP
• Replacing IP-based access with a Security Group reference
• Using a Network ACL to block and allow HTTP traffic
• Configuring a bastion host for SSH access
• Connecting to a private EC2 instance through SSH agent forwarding
• Connecting directly to the private instance using AWS Systems Manager Session Manager
• Modifying the application hosted on the private instance through Session Manager

The progression from IP-based access → Security Group-based access → bastion access → Session Manager was particularly useful because it showed how different approaches affect scalability and security.

I also learned about Elastic Load Balancing, including how load balancers distribute traffic across targets and perform health checks, as well as how they can improve application availability and scalability.

Another interesting topic was Amazon Inspector, which can help identify vulnerabilities in EC2 environments and applications.

Before this module, concepts such as VPCs, CIDR, subnets, routing, gateways, Security Groups, and NACLs felt like separate pieces.

I’m now beginning to see the bigger picture:

The lab reinforced something important for me: securing cloud infrastructure is not about simply putting restrictions everywhere. It is about understanding what needs to communicate, allowing only the necessary access, and designing the environment so that resources are not unnecessarily exposed.

Another module completed, another layer added to my understanding of AWS cloud security.