I used Amazon VPC to create a secure and isolated network environment
Author: Darryl Brown
Email: darrylbrown1991@gmail.com
Amazon VPC (Virtual Private Cloud) is a service that lets you provision a logically isolated section of the AWS cloud where you can launch AWS resources in a virtual network you define. It is useful because it gives you full control over network configuration, including IP address ranges, subnets, route tables, and security settings, enabling secure and scalable cloud architectures.
In today's project, I used Amazon VPC to create a secure and isolated network environment for my application, defining subnets, route tables, and security settings to control traffic flow and ensure proper connectivity between resources.
One thing I didn't expect in this project was for EC2 Global View to work and summarize resources as quickly as it did.
This project took me not much time, maybe about 30-40 minutes. The longest parts of this project was just double and triple checking making sure configurations where set properly.
In cloud networking route tables are, especially AWS, route tables are configuration tables that tell a network where to send traffic. Basically a set of rules that decide how network traffic moves inside and outside your VPC.
Routes tables are needed to make a subnet public because they control where outbound traffic from that subnet goes. A subnet becomes public only when its route table contains a route that sends 0.0.0.0/0 (all internet-bound traffic) to an Internet Gateway (IGW).
Routes are defined by their destination and target. In destination the IP range (CIDR block) the traffic is trying to reach. It tells AWS what traffic this route applies to. In target it's the next hop or where AWS should send the traffic for that destination, it tells AWS how to get there.
The route in my route table that directed internet-bound traffic to my internet gateway had a destination of 0.0.0.0/0 and a target of my created internet gateway. With a 2nd route of 10.0.0.0/16 to "local", meaning any traffic whose IP falls within that CIDR range can communicate between subnets inside the VPC automatically.
Security groups are responsible for checking who comes in and out. They have strict rules about what kind of traffic can enter or leave the resource based on its IP address, protocols and port numbers.
Inbound rules control the data that can enter the resources in your security group, while outbound rules control that data that my resources can send out. I configured an inbound rule that allows anyone on the internet (any IPv4 address) to send HTTP traffic (port 80) to the resource.
Outbound rules control what traffic your resource is allowed to send out to other IP addresses, networks, or services. By default, my security group's outbound rule allowed to send any type of traffic to any IPv4 address.
In short, Network ACLs are stateless firewalls that control inbound and outbound traffic at the subnet level, providing an extra layer of security for all resources within the subnet.
The difference between a security group and a network ACL is that a security group acts as a virtual firewall at the instance level, controlling inbound and outbound traffic, while a network ACL operates at the subnet level, controlling traffic entering and leaving the subnet. Additionally, security groups are stateful, meaning return traffic is automatically allowed. Whereas network ACLs are stateless meaning return traffic must be explicitly allowed.
By default, the network ACL's that AWS create allow all inbound and outbound traffic.
A custom network ACL’s inbound/outbound rules explicitly allow or deny specific traffic based on protocol, port range, and source/destination IP addresses. In contrast, a default network ACL’s inbound and outbound rules are automatically set to allow all traffic.
I created additional VPC, Internet Gateway, and Security Groups. Instead of my usual region, I used us-west-2. Teams would use multiple regions to improve latency for their end users, which means apps run faster because resources are physically closer to the users location. Protect themselves from natural disasters and other risks. If one Region experiences an outage, other Regions can maintain operations.
EC2 Global View is a tool where you can find a consolidated view of all your EC2 instances across multiple regions in one place. I could even narrow down my search by instance type, region, or tags. Without EC2 Global View, I'd have to manually switch between regions in the AWS console to track my instances.
I would use EC2 Global View if I need a centralized overview of all my EC2 instances across multiple regions, such as for monitoring, auditing, or managing resources efficiently without switching between regions individually. It’s especially useful for spotting underutilized instances, ensuring compliance, or coordinating global deployments.
