AWS VPC

- 21 minutes read - 4292 words

AWS Virtual Private Cloud

Amazon Virtual Private Cloud (Amazon VPC) lets you provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. You can use both IPv4 and IPv6 in your VPC for secure and easy access to resources and applications.

You can easily customize the network configuration for your Amazon VPC. For example, you can create a public-facing subnet for your web servers that has access to the Internet, and place your backend systems such as databases or application servers in a private-facing subnet with no Internet access. You can leverage multiple layers of security, including security groups and network access control lists, to help control access to Amazon EC2 instances in each subnet.

Additionally, you can create a Hardware Virtual Private Network (VPN) connection between your corporate datacentre and your VPC and leverage the AWS cloud as an extension of your datacentre.

AWS VPC Overview

Key Components

Amazon VPC comprises a variety of objects that will be familiar to customers with existing networks:

  • A Virtual Private Cloud: A logically isolated virtual network in the AWS cloud. You define a VPC’s IP address space from ranges you select.
  • Subnet: A segment of a VPC’s IP address range where you can place groups of isolated resources.
  • Internet Gateway: The Amazon VPC side of a connection to the public Internet.
  • NAT Gateway: A highly available, managed Network Address Translation (NAT) service for your resources in a private subnet to access the Internet.
  • Virtual private gateway: The Amazon VPC side of a VPN connection.
  • Peering Connection: A peering connection enables you to route traffic via private IP addresses between two peered VPCs.
  • VPC Endpoints: Enables private connectivity to services hosted in AWS, from within your VPC without using an Internet Gateway, VPN, Network Address Translation (NAT) devices, or firewall proxies.
  • Egress-only Internet Gateway: A stateful gateway to provide egress only access for IPv6 traffic from the VPC to the Internet.

Creating a VPC

Default VPC

The default VPC is user friendly, allowing you to immediately deploy instances. When we create a default VPC, we do the following to set it up for you:

  • Create a VPC with a size /16 IPv4 CIDR block (e.g. 172.31.0.0/16). This provides up to 65,536 private IPv4 addresses.
  • Create a size /20 default subnet in each Availability Zone. This provides up to 4,096 addresses per subnet, a few of which are reserved for our use.
  • Create an internet gateway and connect it to your default VPC.
  • Create a default security group and associate it with your default VPC.
  • Create a default network access control list (ACL) and associate it with your default VPC.
  • Associate the default DHCP options set for your AWS account with your default VPC.

By default, a default subnet is a public subnet, because the main route table sends the subnet’s traffic that is destined for the internet to the internet gateway.

Custom VPC

When you create a custom VPC within an AWS region, you specify the IP address range in the form of a CIDR block. A VPC can be assigned at most 1 IP address range at any given time.

CIDR notation is a syntax for specifying IP addresses and their associated routing prefix in the format 10.0.0.0/28. The allowed block size is between a /28 netmask (16 IP addresses)

AWS /28 submask

and a /16 submask (65,536 IP addresses)

AWS /16 submask

You can’t change the size of a VPC after you create it. Amazon recommend you specify a CIDR range from the private (non-publicly routable) IP address ranges as specified in RFC 1918.

When you create a custom VPC, AWS automatically creates:

  • A route table that contains a local route for communication within the VPC over IPv4. If you’ve associated an IPv6 CIDR block with your VPC, your route tables contain a local route for the IPv6 CIDR block. You cannot modify or delete these routes.
Destination Target Status Propagated
10.0.0.0/16 local Active No
  • A network ACL that by default, allows all inbound and outbound IPv4 traffic and, if applicable, IPv6 traffic. Each network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn’t match any of the other numbered rules, it’s denied. You can’t modify or remove this rule.
Rule # Type Protocol Port Range Source Allow / Deny
100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
101 ALL Traffic ALL ALL ::/0 ALLOW
* ALL Traffic ALL ALL 0.0.0.0/0 DENY
* ALL Traffic ALL ALL ::/0 DENY
  • A security group that allows all inbound traffic from other instances associated with this security group only, and allows all outbound traffic to leave the instances

Inbound Rules

Type Protocol Port Range Source Description
All traffic All All (security group)

Outbound Rules

Type Protocol Port Range Destination Description
All traffic All All 0.0.0.0/0

Subnets

VPCs can be sub-divided into separate logical sub-networks known as subnets. Each subnet has its own range of IP addresses specified by a CIDR block.

The first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use, and cannot be assigned to an instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP addresses are reserved:

  • 10.0.0.0: Network address.
  • 10.0.0.1: Reserved by AWS for the VPC router.
  • 10.0.0.2: Reserved by AWS. The IP address of the DNS server is always the base of the VPC network range plus two; however, we also reserve the base of each subnet range plus two. For VPCs with multiple CIDR blocks, the IP address of the DNS server is located in the primary CIDR. For more information, see Amazon DNS Server.
  • 10.0.0.3: Reserved by AWS for future use.
  • 10.0.0.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.

When you create a subnet, you specify the VPC it resides in, as well as the availability zone. A VPC can span multiple availability zones. Each subnet can be classed as a public or a private subnet. To make your subnet a public subnet, you must add a route to an Internet Gateway.

Internet Gateway

An Internet Gateway is a virtual route that connects a VPC to the Internet. An Internet Gateway serves two purposes:

  • To provide a target in your VPC route tables for Internet-routable traffic
  • To perform network address translation (NAT) for instances that have been assigned public IP addresses

You create an Internet Gateway, and then attach it to a VPC. You can only have one Internet Gateway attached to a VPC. You can however have 5 Internet Gateways per REGION. If you test this within AWS VPC section, you’ll see you can create multiple IGW’s, however you’re only able to ASSOCIATE it with one VPC.

Route Table

A route table contains a set of rules, called routes, that are used to determine where network traffic is directed. Each subnet in your VPC must be associated with a route table; the table controls the routing for the subnet. A subnet can only be associated with one route table at a time, but you can associate multiple subnets with the same route table.

Each route table contains a local route that enables communication within a VPC. You cannot modify or delete this route.

Your VPC can have route tables other than the default table. One way to protect your VPC is to leave the main route table in its original default state (with only the local route), and explicitly associate each new subnet you create with one of the custom route tables you’ve created. This ensures that you explicitly control how each subnet routes outbound traffic.

The route table below shows a local route, and a route to an Internet Gateway, making this a Public Subnet.

Destination Target Status
10.0.0.0/16 local Active
0.0.0.0/0 igw-4vsshs Active

The route table below shows a local route, and a route to a NAT Gateway, making this a Private Subnet.

Destination Target Status
10.0.0.0/16 local Active
0.0.0.0/0 nat-4vsshs Active

External Internet Access

NAT Instance

Previously to get outbound traffic from a private subnet you needed to configure a NAT Instance.

You can use a network address translation (NAT) instance in a public subnet in your VPC to enable instances in the private subnet to initiate outbound IPv4 traffic to the Internet or other AWS services, but prevent the instances from receiving inbound traffic initiated by someone on the Internet.

Each EC2 instance performs source/destination checks by default. This means that the instance must be the source or destination of any traffic it sends or receives. However, a NAT instance must be able to send and receive traffic when the source or destination is not itself. Therefore, you must disable source/destination checks on the NAT instance.

NAT Gateway

You can use a network address translation (NAT) gateway to enable instances in a private subnet to connect to the internet or other AWS services, but prevent the internet from initiating a connection with those instances. NAT gateways are not supported for IPv6 traffic—use an egress-only internet gateway instead. To create a NAT gateway, you must specify the public subnet in which the NAT gateway should reside. Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone. You have a limit on the number of NAT gateways you can create in an Availability Zone.

Egress Only Internet Gateway

An egress-only Internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows outbound communication over IPv6 from instances in your VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with your instances. An egress-only Internet gateway is for use with IPv6 traffic only. To enable outbound-only Internet communication over IPv4, use a NAT gateway instead.

IPv6 addresses are globally unique, and are therefore public by default. If you want your instance to be able to access the Internet, but you want to prevent resources on the Internet from initiating communication with your instance, you can use an egress-only Internet gateway. To do this, create an egress-only Internet gateway in your VPC, and then add a route to your route table that points all IPv6 traffic (::/0) or a specific range of IPv6 address to the egress-only Internet gateway. IPv6 traffic in the subnet that’s associated with the route table is routed to the egress-only Internet gateway.

An egress-only Internet gateway is stateful: it forwards traffic from the instances in the subnet to the Internet or other AWS services, and then sends the response back to the instances.

Security in your VPC

Amazon VPC provides features that you can use to increase and monitor the security for your VPC:

  • Security groups — Act as a firewall for associated Amazon EC2 instances, controlling both inbound and outbound traffic at the instance level
  • Network access control lists (ACLs) — Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level
  • Flow logs — Capture information about the IP traffic going to and from network interfaces in your VPC

When you launch an instance in a VPC, you can associate one or more security groups that you’ve created. Each instance in your VPC could belong to a different set of security groups. If you don’t specify a security group when you launch an instance, the instance automatically belongs to the default security group for the VPC

Comparison of Security Groups and Network ACLs

The following table summarises the basic difference.

Security Group v Network ACL

Your VPC comes with a default Network ACL, that by default allows all inbound and outbound traffic. You can create a custom NACL. When you create a custom NACL, all inbound and outbound traffic are automatically denied.

Each subnet in your VPC must be associated with a NACL. If you don’t explicitly associate a subnet with a NACL it be associated with the default NACL. You can associate a network ACL with multiple subnets; however, a subnet can only be associated with one NACL at any time.

NACLs are stateless, which means that return request traffic must have an allow rule set up for that return traffic to enter or leave the subnet.

A NACL contains a numbered list of rules that is evaluated in order, starting with the lowest numbered rule. In addition, as rules are being evaluated, if a matching allow/deny rule is found, it is immediately executed. Meaning that if you have both an allow rule and a deny rule for the same type of traffic, the rule with the lower rule number will be executed and the other will be ignored.

A NACL has separate inbound and outbound rules, and each rule can either allow or deny traffic.

If an instance in your VPC is the client initiating a request, your network ACL must have an inbound rule to enable traffic destined for the ephemeral ports specific to the type of instance (Amazon Linux, Windows Server 2008, and so on).

In practice, to cover the different types of clients that might initiate traffic to public-facing instances in your VPC, you can open ephemeral ports 1024-65535. However, you can also add rules to the ACL to deny traffic on any malicious ports within that range. Ensure that you place the DENY rules earlier in the table than the ALLOW rules that open the wide range of ephemeral ports.

Security groups

A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. When you launch an instance in a VPC, you can assign up to five security groups to the instance. Security groups act at the instance level, not the subnet level. Therefore, each instance in a subnet in your VPC could be assigned to a different set of security groups. If you don’t specify a particular group at launch time, the instance is automatically assigned to the default security group for the VPC.

For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic.

Your VPC automatically comes with a default security group. Each EC2 instance that you launch in your VPC is automatically associated with the default security group if you don’t specify a different security group when you launch the instance.

By default, new security groups start with only an outbound rule that allows all traffic to leave the instances. You must add rules to enable any inbound traffic or to restrict the outbound traffic.

  • You have limits on the number of security groups that you can create per VPC, the number of rules that you can add to each security group, and the number of security groups you can associate with a network interface.
  • You can specify allow rules, but not deny rules.
  • You can specify separate rules for inbound and outbound traffic.
  • When you create a security group, it has no inbound rules. Therefore, no inbound traffic originating from another host to your instance is allowed until you add inbound rules to the security group.
  • By default, a security group includes an outbound rule that allows all outbound traffic. You can remove the rule and add outbound rules that allow specific outbound traffic only. If your security group has no outbound rules, no outbound traffic originating from your instance is allowed.
  • Security groups are stateful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.
  • Instances associated with a security group can’t talk to each other unless you add rules allowing it (exception: the default security group has these rules by default).
  • Security groups are associated with network interfaces

Network ACL

A network access control list (ACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. You might set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your VPC.

  • Your VPC automatically comes with a modifiable default network ACL. By default, it allows all inbound and outbound IPv4 traffic and, if applicable, IPv6 traffic.
  • You can create a custom network ACL and associate it with a subnet. By default, each custom network ACL denies all inbound and outbound traffic until you add rules.
  • Each subnet in your VPC must be associated with a network ACL. If you don’t explicitly associate a subnet with a network ACL, the subnet is automatically associated with the default network ACL.
  • You can associate a network ACL with multiple subnets; however, a subnet can be associated with only one network ACL at a time. When you associate a network ACL with a subnet, the previous association is removed.
  • A network ACL contains a numbered list of rules that we evaluate in order, starting with the lowest numbered rule, to determine whether traffic is allowed in or out of any subnet associated with the network ACL. As soon as a rule matches traffic, it’s applied regardless of any higher-numbered rule that may contradict it.
  • A network ACL has separate inbound and outbound rules, and each rule can either allow or deny traffic
  • Network ACLs are stateless; responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).

Flow Logs

VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data is stored using Amazon CloudWatch Logs. After you’ve created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs.

Flow logs can help you with a number of tasks; for example, to troubleshoot why specific traffic is not reaching an instance, which in turn helps you diagnose overly restrictive security group rules. You can also use flow logs as a security tool to monitor the traffic that is reaching your instance.

There is no additional charge for using flow logs; however, standard CloudWatch Logs charges apply.

You can create a flow log at three different levels:

  • VPC
  • Subnet
  • Network Interface Level

If you create a flow log for a subnet or VPC, each network interface in the VPC or subnet is monitored. Flow log data is published to a log group in CloudWatch Logs, and each network interface has a unique log stream. Log streams contain flow log records, which are log events consisting of fields that describe the traffic for that network interface.

  • You cannot enable flow logs for VPCs that are peered with your VPC unless the peer VPC is in your account
  • You cannot tag a flow log
  • After you’ve created a flow log, you cannot change its configuration; for example, you can’t associate a different IAM role with the flow log
  • Not all traffic is monitored e.g. DHCP traffic, instance metadata URL

VPC Peering

A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account. The VPCs can be in different regions (also known as an inter-region VPC peering connection). All inter-region traffic is encrypted with no single point of failure, or bandwidth bottleneck. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and DDoS attacks.

AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck.

Each VPC has to be peered with each other, there is no transitive VPC peering. VPC peering only routes traffic between source and destination VPCs. VPC peering does not support edge to edge routing. This means you would not be able to take advantage of Direct Connect or an Internet Gateway in an account you are peered too.

  • Full private IP connectivity between two VPCs
  • Can peer VPC across regions
  • VPCs can be in different accounts
  • VPC CIDR ranges must not overlap

Security groups work the same if the VPCs are in the same region

  1. One VPC initiates a peering request
  2. The second VPC accepts the peering request
  3. The peering connection is setup. Both sides now need to set up routes to the peered connection

Transit Gateway

AWS Transit Gateway is a service that enables customers to connect their Amazon Virtual Private Clouds (VPCs) and their on-premises networks to a single gateway. As you grow the number of workloads running on AWS, you need to be able to scale your networks across multiple accounts and Amazon VPCs to keep up with the growth. Today, you can connect pairs of Amazon VPCs using peering. However, managing point-to-point connectivity across many Amazon VPCs, without the ability to centrally manage the connectivity policies, can be operationally costly and cumbersome. For on-premises connectivity, you need to attach your AWS VPN to each individual Amazon VPC. This solution can be time consuming to build and hard to manage when the number of VPCs grows into the hundreds.

With AWS Transit Gateway, you only have to create and manage a single connection from the central gateway in to each Amazon VPC, on-premises data center, or remote office across your network. Transit Gateway acts as a hub that controls how traffic is routed among all the connected networks which act like spokes. This hub and spoke model significantly simplifies management and reduces operational costs because each network only has to connect to the Transit Gateway and not to every other network. Any new VPC is simply connected to the Transit Gateway and is then automatically available to every other network that is connected to the Transit Gateway. This ease of connectivity makes it easy to scale your network as you grow.

VPC Endpoint

A VPC endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network.

Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic.

There are two types of VPC endpoints: interface endpoints and gateway endpoints.

Interface Endpoint An interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service (includes API Gateway, ECS)

Gateway Endpoint A gateway endpoint is a gateway that is a target for a specified route in your route table, used for traffic destined to a supported AWS service. Currently only S3 and DynamoDB are supported.

Amazon DNS

When you create a VPC, your new VPC is automatically configured with an Amazon provided DNS server which is used to resolve public DNS hostnames. It is used for DNS hostname resolution for instances in your VPC which are communicating over the internet.

The Amazon DNS server uses one of the reserved IP addresses in your VPC’s CIDR range.

If you do not want to use the Amazon provided DNS server and instead use a custom DNS server, you can disable this in the settings if your VPC. Go to DNS resolution and uncheck the box. Create a new Dynamic Host Configuration Protocol (DHCP) Options set to use your own custom DNS.

Connecting to on premises networks

AWS VPN

AWS Virtual Private Network (AWS VPN) lets you establish a secure and private tunnel from your network or device to the AWS global network. AWS VPN is comprised of two services: AWS Site-to-Site VPN and AWS Client VPN. AWS Site-to-Site VPN enables you to securely connect your on-premises network or branch office site to your Amazon Virtual Private Cloud (Amazon VPC). AWS Client VPN enables you to securely connect users to AWS or on-premises networks.

You will get your own networking device and set it up to act as a Customer Gateway. On the VPC you create a Virtual Private Gateway. You will then get two encrypted redundant IPSec tunnels over the internet. They should terminate in different availability zones. You then set up a route in the VPC to route any traffic for your corporate IP address range to the Virtual Private Gateway

AWS Direct Connect

AWS Direct Connect is a network service that provides an alternative to using the Internet to connect customer’s on premise sites to AWS.

Using AWS Direct Connect, data that would have previously been transported over the Internet can now be delivered through a private network connection between AWS and your datacenter or corporate network.

Each AWS Direct Connect connection can be configured with one or more virtual interfaces. Virtual interfaces may be configured to access AWS services such as Amazon EC2 and Amazon S3 using public IP space, or resources in a VPC using private IP space. This is using a private or public virtual interface.