Virtual Private Cloud (VPC)

Natasha Ong
This is some text inside of a div block.
4 min read

In a nutshell:

Amazon Virtual Private Cloud (VPC) lets you create an isolated section of the AWS Cloud. This isolated section is called a private network.
The public (internet-accessible) and private (internal) grouping of resources (e.g. EC2 instances) are known as subnets. Subnets take up ranges of IP addresses in your VPC.
To set up an encrypted VPN connection to your private private subnet, you would need to attach a virtual private gateway to your VPC.
AWS Direct Connect is a service that lets you to set up a dedicated private connection between your data centre and your VPC in AWS. This bypasses the public internet.
Network access control lists (NACLs) are virtual firewalls that control inbound and outbound traffic at the subnet level.
Security groups act as virtual firewalls for specific C2 instances.
NACLs and security groups use protocols and ports to define rules for traffic, determining what is allowed or denied.


Welcome to your beautiful city! πŸŒ†

In the big wide world of AWS, think of Amazon VPC as your very own city where you're the city planner.

Amazon VPC is all about organisation, efficiency, and security, making sure different activities happen in the right places, and everyone follows the rules.

Here's how it all comes together...


Amazon Virtual Private Cloud (Amazon VPC)

Amazon VPC is your personal city that you shape as you see fit. You decide where to build your roads, lay the power lines, and set up buildings.

  • Now, you can't just randomly throw some buildings to different parts of the city and call it a day! In your city, you create different neighbourhoods (subnets) where different types of activities happen. Imagine a bustling shopping area (public subnet) where everyone can see and visit shops, and private gated areas (private subnet) behind the scenes. These subnets are like distinct parts of your city, and each one covers a range of streets (IP addresses).
  • In your city, you also have to figure out where to place the different buildings (EC2 instances) like schools or houses, and Β your traffic controllers (ELBs). You decide whether they should be located at the shopping area where people can see them (public subnet), or tucked away in the private gates areas (private subnet). It's all about controlling access and visibility.

Now let's revisit the concept of VPC, purely with an AWS lens:

  • Amazon VPC is your own private network within AWS.
  • A VPC lets you set up your private IP range* and group resources like EC2 instances and ELBs.
*An IP address is like a digital address for devices on a network, similar to a house address. It's a unique number used to identify and locate devices, such as computers, in a network. Servers, like EC2 instances, have IP addresses too.
A private IP range is a reserved set of digital addresses within a network that cannot be directly accessible from the public internet. It's like having a set of secret phone numbers that only work within your company or home, but not for the outside world.
  • Subnets are chunks of IP addresses in your VPC that help you group resources together. Subnets and networking rules (which you'll learn about in a minute) control whether resources are either publicly or privately available.
  • Public subnets contain resources that need to be accessible by the public i.e. anyone on the internet, such as an online store’s website.
  • Private subnets contain resources that should be accessible only through your private network, e.g. an online store's customer or order database. Only authorised people that can enter your private network can access it.
  • In a VPC, subnets can communicate with each other. For example, an app with EC2 instances in a public subnet can exchange information with databases in a private subnet.


Connectivity to AWS

Your city isn't an island and can't survive on its own - it needs connections to the outside world! These connections are like the roads and highways that bring people in and out of your city:

  • If there's a part of your city that's open to the public, like your bustling shopping area, you need entrances and exits that let people come and go – think of these as Internet Gateways.
  • For the hidden, restricted areas in your city, you'd prefer a different kind of connection – like a private road that only a few authorised people can access. This is your Virtual Private Gateway.
  • Picture a dedicated, high-speed underground train connecting your city directly to AWS. That's AWS Direct Connect – it's your exclusive, fast lane with no traffic jams or detours, perfect for secure and rapid travel.

Awesome! Now let's take a look at what they mean in AWS terms:

  • One VPC might have multiple types of gateways attached for its different subnets.
  • Public resources (e.g. websites) require an Internet Gateway (IGW) to connect to the public internet. IGW's allow traffic from the internet to flow into and out of your VPC.
  • For private resources, a virtual private gateway creates a secure VPN connection (VPN)* between your VPC and another private network. A VPN only allows traffic into the VPC only if it is coming from an approved network.
*A VPN (virtual private network) connection protects your internet traffic. It's like travelling with a security guard that fends off anyone that wants to see the information you're sending. Once your traffic reaches its destination network, the virtual private gateway there will verify your traffic can enter into their VPC.
  • The approved private network could be:
  • Your on-premise data centre i.e. you'd use VPNs to allow resources in your company's physical data centre to communicate with your AWS resources.
  • Another private network your company has set up. For example, global companies often set up different private networks for different office locations.
  • External private network i.e. other companies. For example, you can set up VPNs with partners or suppliers to share data.
  • VPN connections are private and encrypted, but they still use a regular internet connection that is being shared by many people using the internet.
  • AWS Direct Connect establishes a dedicated, secure connection from your on-premise data centre to your AWS VPC, reducing network costs and increasing bandwidth. Traffic is no longer travelling through the public internet. Direct Connect = the lowest latency and highest security possible. This also helps companies meet any strict data privacy rules.
  • Direct Connect provides a physical line that connects your network to your AWS VPC. Companies will need to work with a Direct Connect partner in their area to dig the ground, lay down this line and establish the connection.

Here's an example of how a VPC, private subnet, public subnet, internet gateway and resource all fit together!

P.S. you've actually seen this diagram before - back when we did our EC2 autoscaling and load balancing exercise! Now, you're able to understand the key components of this diagram. Isn't that awesome?!



Let's zoom into the street-level details of your city:

  • You've stationed security posts (network access control lists) all across your city, controlling the traffic entering and leaving neighbourhoods (subnets).
  • You also hire private security guards (security groups) for specific buildings (EC2 instances). Each building can have its own set of security rules, specifying which types of traffic are allowed and which are denied.

Awesome! Now let's take a look at VPC's security features in AWS terms:

  • When a customer requests data from an app hosted in the cloud with AWS, this request is sent as a packet. A packet is a unit of data sent over the internet or a network.
  • This request packet enters into a VPC through an internet gateway.
  • Before a packet can enter or exit any of the VPC's subnets, the network access control list (NACL, or network ACL) checks for the packet's permissions. These permissions include who sent the packet and what the packet is trying to get from resources in a subnet. If the packet's sender is not approved (or has been explicitly banned), they can't access the subnet.
  • When configuring your VPC, you can use AWS' default network ACL or create custom network ACLs.
  • The default NACL allows all inbound and outbound traffic.
  • For custom NACLs, all inbound and outbound traffic is denied until you add rules to specify which traffic to allow.
  • After a packet has entered a subnet, a security group checks for the packet's permissions before it talks with an EC2 instance.


Hmmm... so what's the difference between those two?

In summary, security groups are like building-specific security guards, while NACLs control city-wide traffic and safety rules in your AWS city. Let's dive into the differences between them in detail, learning a few more concepts about them along the way:

‍Network Access Control Lists (NACLs):

  1. NACLs operate at the network (IP) layer*. This means NACL control the flow of data packets based on the source and destination IP addresses, port ranges, and protocols. More on port ranges and protocols in a second!
*The network (IP) layer = the address and routing system for data packets on the internet.
  1. Stateless: Network ACLs perform stateless packet filtering. Network ACLs check packets that cross the subnet border each way: inbound and outbound.
  2. Let's say an EC2 instance in one subnet sends a request packet to a database in a different subnet.
  3. When the database's response for that request comes back to the EC2's subnet, the network ACL does not remember what happened (i.e. it does not remember that the EC2 instance asked for this information).
  4. The network ACL still checks the packet against its list of rules to determine whether to allow or deny it into the EC2 instance's subnet.
  5. Coverage: NACLs apply to all resources within a VPC. You can't assign different NACLs to individual resources. If you don't explicitly associate a subnet with a network ACL, the subnet automatically gets the default network ACL.
  6. Explicit allow/deny: All NACLs have an explicit deny rule by default. This means there is always a rule that says "if a packet doesn’t match any of my other rules, we'll deny it straight away." This doesn't really matter for default NACLs, since it allows all incoming/outgoing traffic anyway. But for custom NACLs, you will have to create custom rules to allow specific types of traffic wanting to enter/leave your subnets (explicit allow).


Security groups:
  1. Security groups operate at the instance (host) layer, which means they're like the security checkpoint at a building's entrance. Security groups determine who or what is allowed to enter and exit a specific server, like an EC2 instance, based on rules and permissions that you set.
  2. They filter traffic based on instance-specific rules. Note that when we say instance, we mean an EC2 server! This means you assign a security group to a specific building in the city.
  3. Stateful: Security groups are stateful, so they remember previous decisions made for packets. If you allow outbound traffic, inbound response traffic is automatically allowed for that connection. Going back to the EC2 instance and database's example, a security group would allow the response packet in immediately. This is because the security group would remember the EC2's previous request.
  4. Coverage: You assign specific security groups to individual instances, giving you specific control over each instance's security.
  5. Explicit allow/deny: By default, new security groups start with just one rule that allows all outbound traffic but blocks all inbound traffic. You must add rules to enable any inbound traffic (explicit allow) or to restrict outbound traffic (explicit deny).


Protocols and Ports

Now, let's talk about protocols and ports.

You'll come across different protocols and ports when setting up your NACLs and security groups (which we'll be doing in the exercise)! They are the language the NACls and security groups use to specify what types of traffic are allowed or denied.


A protocol is a set of rules that computers follow when communicating with each other. It defines how data should be transmitted and received. In your exercise, you'll encounter a few protocols:

  • HTTP (Hypertext Transfer Protocol): This is the standard protocol for transmitting web pages over the internet. It's used when you visit websites in your web browser - do you notice how website links often start with this? For example,
  • HTTPS (Hypertext Transfer Protocol Secure): This is like HTTP but with an extra layer of security. It encrypts the data as it's transmitted, making it more secure, and it's often used for websites that handle sensitive information, like online shopping or banking sites. You can also find an HTTPS version of the NextWork website link:
  • SSH (Secure Shell Protocol): Like HTTPS, SSH allows secure, encrypted communication with a physical server. While HTTPS is used for viewing websites in your browser, SSH is for securely managing and controlling servers, like setting up software, troubleshooting, and configuring server settings. It's not a tool that we use everyday, but SSH is super useful for those working in IT who need to access a server that's physically located somewhere else.



Servers have multiple ports to accommodate different types of communication and services.

  • Ports help the server identify different types of incoming and outgoing data and to route them to the appropriate services or processes inside the server.
  • It's like having different gates at an airport for various airlines (instead of having one big gate for all the flights taking off). Each gate handles passengers for a specific airline, just as different ports handle different types of data for specific services on a server.

Each port is typically associated with a specific protocol.

  • Port 80 is commonly used for HTTP
  • Port 443 for HTTPS
  • Port 22 for SSH.

By specifying port numbers in your NACLs and security groups, you control which types of traffic can enter and exit your resources.


An extra note for the curious

Let's take a look at how Direct Connect works in detail:

  • A company's data centre routes network traffic to an AWS Direct Connect location.
  • That traffic is then routed to a VPC through a virtual private gateway.
  • All network traffic between the company's data centre and VPC flows through this dedicated private connection.
  • The private connection that AWS Direct Connect provides helps the company reduce network costs and increase the amount of bandwidth that can travel through your network.


In comparison, a VPN connection still travels over the public internet, although virtual private gateways will verify that the traffic coming in is approved.

A corporate data center routes network traffic over a VPN connection to a virtual private gateway, which is attached to a VPC