Amazon Virtual Private Cloud (VPC)

Amazon Virtual Private Cloud (VPC) Overview

An Amazon Virtual Private Cloud (VPC) is a logically isolated space into which you can launch AWS resources.

You can create virtual networks called subnets within a VPC.

You have complete control over the virtual networking.

The components of a VPC include:

  • 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 (maps to an AZ, 1:1).
  • 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.
  • Hardware VPN Connection: A hardware-based VPN connection between your Amazon VPC and your datacenter, home network, or co-location facility.
  • Virtual Private Gateway: The Amazon VPC side of a VPN connection.
  • Customer Gateway: Your side of a VPN connection.
  • Router: Routers interconnect subnets and direct traffic between Internet gateways, virtual private gateways, NAT gateways, and subnets.
  • 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 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.

NOTE: The SysOps Administrator Exam focusses on some specific operational concepts associated with VPCs. For a more in-depth background on Amazon VPC see the cheats sheets for the Solutions Architect Associate here.

CIDR Blocks and IP Subnets for Amazon VPCs

When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block.

You can then define ranges of IP addresses within the VPC CIDR that can be assigned to subnets. AWS resources obtain addresses from these IP ranges.

AWS recommend that CIDR blocks of /16 or smaller are used.

It is recommended these come from the private IP ranges specified in RFC 1918:

  • 10.0.0.0 – 10.255.255.255 (10/8 prefix)
  • 172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
  • 192.168.0.0 – 192.168.255.255 (192.168/16 prefix)

However, it is possible to create a VPC with publicly routable CIDR block.

The allowed block size is between a /28 netmask and /16 netmask.

The CIDR blocks of the subnets within a VPC cannot overlap.

The first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use

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 route.
  • 10.0.0.2: Reserved by AWS.
  • 10.0.0.3: Reserved by AWS for future use.
  • 10.0.0.255: Network broadcast address (broadcast not supported).

For further information, check out this AWS article.

NAT Gateways and NAT Instances

NAT Gateways

NAT gateways are managed for you by AWS.

Fully-managed NAT service that replaces the need for NAT instances on EC2.

Must be created in a public subnet.

Uses an Elastic IP address for the public IP.

Private instances in private subnets must have a route to the NAT instance, usually the default route destination of 0.0.0.0/0.

Created in a specified AZ with redundancy in that zone.

For multi-AZ redundancy, create NAT Gateways in each AZ with routes for private subnets to use the local gateway.

Can’t use a NAT Gateway to access VPC peering, VPN or Direct Connect, so be sure to include specific routes to those in your route table.

NAT gateways are highly available in each AZ into which they are deployed.

Not associated with any security groups.

Automatically assigned a public IP address.

Remember to update route tables and point towards your gateway.

NAT Instances

NAT instances are managed by you.

Used to enable private subnet instances to access the Internet.

NAT instance must live on a public subnet with a route to an Internet Gateway.

Private instances in private subnets must have a route to the NAT instance, usually the default route destination of 0.0.0.0/0.

When creating NAT instances always disable the source/destination check on the instance.

NAT instances must be in a single public subnet.

NAT instances need to be assigned to security groups.

Security groups for NAT instances must allow HTTP/HTTPS inbound from the private subnet and outbound to 0.0.0.0/0.

There needs to be a route from a private subnet to the NAT instance for it to work.

The amount of traffic a NAT instance can support is based on the instance type.

Using a NAT instance can lead to bottlenecks (not highly available).

Performance is dependent on instance size.

Can scale up instance size or use enhanced networking.

Can scale out by using multiple NATs in multiple subnets.

Can also use as a bastion (jump) host.

NAT Gateway vs NAT Instance

Security Groups

Security groups act like a firewall at the instance level.

Specifically security groups operate at the network interface level.

Can only assign permit rules in a security group, cannot assign deny rules.

There is an implicit deny rule at the end of the security group.

All rules are evaluated until a permit is encountered or continues until the implicit deny.

Can control ingress and egress traffic.

Security groups are stateful.

You can use security group names/IDs as the source or destination in other security groups.

You can use the security group name/ID as a source in its own inbound rules.

Security group members can be within any AZ or subnet within the VPC.

Security group membership can be changed whilst instances are running.

Any changes made will take effect immediately.

You cannot block specific IP addresses using security groups, use NACLs instead.

Network ACL’s

Network ACL’s function at the subnet level.

With NACLs you can have permit and deny rules.

Network ACLs contain a numbered list of rules that are evaluated in order from the lowest number until the explicit deny.

Network ACLs have separate inbound and outbound rules and each rule can allow or deny traffic.

Network ACLs are stateless so responses are subject to the rules for the direction of traffic.

NACLs only apply to traffic that is ingress or egress to the subnet not to traffic within the subnet.

A VPC automatically comes with a default network ACL which allows all inbound/outbound traffic.

A custom NACL denies all traffic both inbound and outbound by default.

All subnets must be associated with a network ACL.

You can create custom network ACL’s. 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 do this manually it will be associated with the default network ACL.

You can associate a network ACL with multiple subnets; however a subnet can only be associated with one network ACL at a time.

Network ACLs do not filter traffic between instances in the same subnet.

NACLs are the preferred option for blocking specific IPs or ranges.

Security groups cannot be used to block specific ranges of IPs.

NACL is the first line of defence, the security group is the second line.

Changes to NACLs take effect immediately.

Security Groups vs NACLs

VPC Endpoints

Enables private connectivity from a VPC to supported AWS services and VPC endpoint services powered by AWS PrivateLink.

Does not require an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.

Endpoints are virtual devices.

They are horizontally scaled, redundant, and highly available.

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

Interface Endpoints

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

With an interface endpoint you remove the need for an internet gateway, NAT device, or virtual private gateway.

PC Endpoint - Interface Endpoint

Gateway Endpoints

A gateway endpoint is a gateway that you specify as a target for a route in your route table for traffic destined to a supported AWS service.

The following AWS services are supported:

  • Amazon S3.
  • DynamoDB.

VPC Endpoint - Gateway Endpoint

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).

Data sent between VPCs in different regions is encrypted (traffic charges apply).

For inter-region VPC peering there are some limitations:

  • You cannot create a security group rule that references a peer security group.
  • Cannot enable DNS resolution.
  • Maximum MTU is 1500 bytes (no jumbo frames support).
  • Limited region support.
  • 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.

A VPC peering connection helps you to facilitate the transfer of data.

Can only have one peering connection between any two VPCs at a time.

Can peer with other accounts (within or between regions).

Cannot have overlapping CIDR ranges.

A VPC peering connection is a one to one relationship between two VPCs.

You can create multiple VPC peering connections for each VPC that you own, but transitive peering relationships are not supported.

You do not have any peering relationship with VPCs that your VPC is not directly peered with.

DNS is supported.

Must update route tables to configure routing.

Must update the inbound and outbound rules for VPC security group to reference security groups in the peered VPC.

When creating a VPC peering connection with another account you need to enter the account ID and VPC ID from the other account.

Need to accept the pending access request in the peered VPC.

The VPC peering connection can be added to route tables – shows as a target starting with “pcx-“.

VPC Peering Setup

VPC Flow Logs

Flow logs can be created at the following levels:

  • VPC.
  • Subnet.
  • Network interface.

You can’t enable flow logs for VPC’s that are peered with your VPC unless the peer VPC is in your account.

You can’t tag a flow log.

You can’t change the configuration of a flow log after it’s been created.

After you’ve created a flow log, you cannot change its configuration (you need to delete and re-create).

Not all traffic is monitored, e.g. the following traffic is excluded:

  • Traffic that goes to Route53.
  • Traffic generated for Windows license activation.
  • Traffic to and from 169.254.169.254 (instance metadata).
  • Traffic to and from 169.254.169.123 for the Amazon Time Sync Service.
  • DHCP traffic.
  • Traffic to the reserved IP address for the default VPC router.

In the following example flow log connections to the SSH port (22) are being accepted and connections to the HTTP port (80) are being rejected:

Example VPC FLow Log

It’s important to understand the difference between the data that’s included in a VPC Flow Log vs the data in an Elastic Load Balancing (ELB) Access Log. The following image shows a log entry from a ELB access log. Note that application level information (HTTP GET request):

ELB Access Log

AWS Managed Virtual Private Network (VPN)

VPNs are quick, easy to deploy, and cost effective.

A Virtual Private Gateway (VGW) is required on the AWS side.

A Customer Gateway is required on the customer side.

AWS Managed VPN

AWS Direct Connect

AWS Direct Connect makes it easy to establish a dedicated connection from an on-premises network to Amazon VPC.

Using AWS Direct Connect, you can establish private connectivity between AWS and your data center, office, or collocated environment.

This private connection can reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than internet-based connections.

AWS Direct Connect lets you establish 1 Gbps or 10 Gbps dedicated network connections (or multiple connections) between AWS networks and one of the AWS Direct Connect locations.

It uses industry-standard VLANs to access Amazon Elastic Compute Cloud (Amazon EC2) instances running within an Amazon VPC using private IP addresses.

AWS Direct Connect does not encrypt your traffic that is in transit.

You can use the encryption options for the services that traverse AWS Direct Connect.

For more info on AWS Direct Connect check out the article here.

AWS Direct Connect

Scroll to Top