Posted on by miro

Virtual Private Cloud

What Is a Virtual Private Cloud?

  • A VPC resembles private data centers or corporate networks
  • Scalable infrastructure
  • Ability to extend corporate/home network to the cloud as if it were part of your network

Virtual Private Cloud (VPC):

  • A private network within AWS. It’s your private data center inside the AWS platform.
  • Can be configured to be public/private or a mixture
  • Regional (can’t span regions), highly available, and can be connected to your data center and corporate networks
  • Isolated from other VPCs by default
  • VPC and subnet: max /16 (65,536 IPs) and min /28 (16 IPs)
  • VPC subnets can’t span AZs (1:1 mapping)
  • Certain IPs are reserved in subnets (see architecture diagram)

Region Default VPC:

  • Required for some services, used as a default for most
  • Pre-configured with all required networking/security
  • Configured using a /16 CIDR block (172.31.0.0/16)
  • A /20 public subnet in each AZ, allocating a public IP by default
  • Attached Internet gateway with a “main” route table sending all IPv4 traffic to the Internet gateway using a 0.0.0.0/0 route
  • A default DHCP option set attached.
  • SG: Default — all from itself, all outbound
  • NACL: Default — allow all inbound and outbound

Understanding the Default VPC:

  • Size /16 CIDR block (172.31.0.0/16)
  • Default subnet in each AZ using /20 subnet mask
  • Internet gateway
  • Main route table sending all IPv4 traffic for 0.0.0.0/0 to the Internet gateway
  • Default security group allowing all traffic
  • Default network ACL (NACL) allowing all traffic
  • Default DHCP option set

VPC IP Reservations:

AWS reserves the first four IP and the last IP addresses. In a 10.0.0.0/24, the fol-lowing IPs are reserved:

  • 10.0.0.0: Network address
  • 10.0.0.1: Reserved by AWS for the Amazon VPC router
  • 10.0.0.2: Reserved by AWS. The IP address of the DNS server is always the base of the Amazon VPC network range; however, the base of each subnet range is also reserved.
  • 10.0.0.3: Reserved by AWS for future use
  • 10.0.0.255: Network broadcast address. AWS does not support broadcast in an Ania/on VPC; therefore, they reserve this address.

Custom VPC:

  • Can be designed and configured in any valid way
  • You need to allocate IP ranges, create subnets, and provision gateways and networking, as well as design and implement security.
  • When you need multiple tiers or a more complex set of networking
  • Best practice is to not use default for most production things

VPC Implementation:

  • Logically isolated from other networks on AWS
  • VPCs can’t span regions
  • Size can range from /16 to a /28 netmask (65,536 to 16 IP addresses)
  • Subnets can’t span Availability Zones

Benefits of a VPC:

  • Ability to launch instances into a subnet
  • Ability to define custom IP address ranges inside of each subnet (private and public subnets)
  • Ability to configure route tables between subnets
  • Ability to configure Internet gateways and attach them to subnets
  • Ability to create a layered network of resources
  • Extending our network with VPN/VPG controlled access
  • Ability to use security groups and subnet network ACLs

VPC Scenarios:

  • VPC with public subnet only: Single-tier apps
  • VPC with public and private subnets: Resources that don’t need public Internet access/layered apps
  • VPC with public and private subnets and hardware-connected VPN: Extending to on-premises
  • VPC with a private subnet only and hardware VPN access

 

VPC Routing:

  • Every VPC has a virtual routing device called the VPC router.
  • It has an interface in any VPC subnet known as the “subnet+1” address — for 10.0.1.0/24, this would be 10.0.1.1/32.
  • The router is highly available, scalable, and controls data entering and leaving the VPC and its subnets.
  • Each VPC has a “main” route table, which is allocated to all subnets in the VPC by default. A subnet must have one route table.
  • Additional “custom” route tables can be created and associated with subnets — but only one route table (RT) per subnet.
  • A route table controls what the VPC router does with traffic leaving a subnet.
  • An Internet gateway is created and attached to a VPC (1:1). It can route traffic for public IPs to and from the Internet.

Routes:

  • A RT is a collection of routes that are used when traffic from a subnet arrives at the VPC router.
  • Every route table has a local route, which matches the CIDR of the VPC and lets traffic be routed between subnets.
  • A route contains a destination and a target. Traffic is forwarded to the target if its destination matches the route destination.
  • If multiple routes apply, the most specific is chosen. A /32 is chosen before a /24, before a /16.
  • Default routes (0.0.0.0/0 v4 and ::/0 v6) can be added that match any traffic not already matched.
  • Targets can be IPs or AWS networking gateways/objects
  • A subnet is a public subnet if it is
    • (1) configured to allocate public IPs,
    • (2) if the VPC has an associated Internet gateway, and
    • (3) if that subnet has a default route to that Internet gateway.

 

VPC peering allows you to set up direct network routing between different VPCs using private IP addresses.

  • Instances will communicate with each other as if they were on the same private network.
  • VPC peering can occur between different AWS accounts as well as VPCs in other regions using Inter-Region VPC Peering.
  • All inter-region traffic is encrypted.
  • Traffic remains on the global AWS backbone.

Scenarios:

  • Peering two VPCs: Company runs multiple AWS accounts and you need to link all the resources as if they were all under one private network
  • Peering to a VPC: Multiple VPCs connect to a central VPC, but they can only communicate with the central VPC (file sharing, customer access, Active Directory) and not each other.

Limitations:

  • Can’t peer VPC with matching or overlapping CIDR blocks
  • VPC peering connections are 1:1 between VPCs — transitive peering is not supported (see Transit Gateway)
  • One peering connection between the same two VPCs
  • Tags applied to the peering connection are only applied in the account and region in which you create them
  • Security groups can’t reference peer VPC security groups across regions
  • IPv6 across regions is not supported
  • DNS resolution for private hostnames must be enabled manually. If in different accounts, must be enabled in both accounts

 

VPC Flow Logs allows you to capture metadata about IP traffic going in and out of your network interfaces.

  • Data is stored in CloudWatch Logs;  Each network interface has a unique log stream
  • Can be created for a VPC, subnet, or network interface; When choosing VPC, each network interface and subnet in that VPC is monitored
  • Flow log records consist of fields describing the traffic for that network interface
  • For security reasons, EC2 instances can’t receive or sniff traffic destined for a different instance
  • Delay of several minutes — flow logs do not capture real-time log streams
  • Ability to create multiple flow logs per interface (e.g., accepted vs. rejected traffic)
  • Launching new EC2 instances after creating flow logs will automatically create logs for each new network interface
  • Create flow logs for network interfaces created by other AWS services: Elastic Load Balancing, Amazon RDS, Amazon ElastiCache, Amazon Redshift, Amazon WorkSpaces

Flow Log Record Syntax:

  • version
  • account-id
  • interface-id
  • srcaddr
  • dstaddr
  • srcport
  • dstport
  • protocol
  • packets
  • bytes
  • start
  • end
  • action
  • log-status

What’s NOT Logged:

  • Amazon DNS server traffic
  • Amazon Windows license activation
  • Instance metadata to/from 169.254.169.254
  • Amazon Time Sync to/from 169.254.169.123
  • DHCP traffic
  • Traffic to/from the default VPC router reserved IP address
  • Traffic between an endpoint network interface and a Network Load Balancer network interface

 

Bastion Hosts (or Jumpboxes):

  • A host that sits at the perimeter of a VPC
  • It functions as an entry point to the VPC for trusted admins.
  • Allows for updates or configuration tweaks remotely while allowing the VPC to stay private and protected
  • Generally connected to via SSH (Linux) or RDP (Windows)
  • Bastion hosts must be kept updated, and security hardened and audited regularly
  • Multifactor authentication, ID federation, and/or IP blocks.

 

Network Access Control Lists (NACLs):

  • NACLs operate at Layer 4 of the OSI model (TCP/UDP and below).
  • A subnet has to be associated with a NACL — either the VPC default or a custom NACL.
  • NACLs only impact traffic crossing the boundary of a subnet.
  • NACLs are collections of rules that can explicitly allow or deny traffic based on its protocol, port range, and source/destination.
  • Rules are processed in number order, lowest first. When a match is found, that action is taken and processing stops.
  • The “*” rule is processed last and is an implicit deny.
  • NACLs have two sets of rules: inbound and outbound.

Ephemeral Ports:

  • When a client initiates communications with a server, it is to a well-known port number (e.g., tcp/443) on that server.
  • The response is from that well-known port to an ephemeral port on the client. The client decides the port.
  • NACLs are stateless, they have to consider both initiating and response traffic — state is a session-layer concept.

 

VPC Peering:

  • Allows direct communication between VPCs.
  • Services can communicate using private IPs from VPC to VPC.
  • VPC peers can span AWS accounts and even regions (with some limitations).
  • Data is encrypted and transits via the AWS global backbone.
  • VPC peers are used to link two VPCs at layer 3: company mergers, shared services, company and vendor, auditing.

Important Limits and Considerations:

  • VPC CIDR blocks cannot over lap.
  • VPC peers connect two VPCs — routing is not transitive.
  • Routes are required at both sides (remote CIDR -> peer connection).
  • NACLs and SGs can be used to control access.
  • SGs can be referenced but not cross-region.
  • IPv6 support is not available cross-region.
  • DNS resolution to private IPs can be enabled, but it’s a setting needed at both sides.

 

VPC endpoints are gateway objects created within a VPC. They can be used to connect to AWS public services without the need for the VPC to have an attached Internet gateway and be public.

VPC Endpoint Types:

  • Gateway endpoints: Can be used for DynamoDB and S3
  • Interface endpoints: Can be used for everything else (e.g., SNS, SQS)

When to Use a VPC Endpoint:

  • If the entire VPC is private with no IGW
  • If a specific instance has no public IP/NATGW and needs to access public services
  • To access resources restricted to specific VPCs or endpoints (private S3 bucket)

Limitations and Considerations:

  • Gateway endpoints are used via route table entries — they are gateway devices. Prefix lists for a service are used in the destination field with the gateway as the target.
  • Gateway endpoints can be restricted via policies.
  • Gateway endpoints are HA across AZs in a region.
  • Interface endpoints are interfaces in a specific subnet. For HA, you need to add multiple interfaces — one per AZ.
  • Interface endpoints are controlled via SGs on that interface. NACLs also impact traffic.
  • Interface endpoints add or replace the DNS for the service — no route table updates are required.
  • Code changes to use the endpoint DNS, or enable private DNS to override the default service DNS.

 

IP version 6 (IPv6) is supported within AWS but not across every product and not with every feature.

IPv6 VPC Setup:

  • It is currently opt-in — it is disabled by default.
  • To use it, the first step is to request an IPv6 allocation. Each VPC is allocated a /56 CIDR from the AWS pool — this cannot be adjusted.
  • With the VPC IPv6 range allocated, subnets can be allocated a /64 CIDR from within the /56 range.
  • Resources launched into a subnet with an IPv6 range can be allocated a IPv6 address via DHCP6.

Limitations and Considerations:

  • DNS names are not allocated to IPv6 addresses.
  • IPv6 addresses are all publicly routable — there is no concept of private vs. public with IPv6 (unlike IPv4 addresses).
  • With IPv6, the OS is configured with this public address via DHCP6.
  • Elastic IPs aren’t relevant with IPv6.
  • Not currently supported for VPNs, customer gateways, and VPC endpoints.

 

Egress-only Internet gateways provide IPv6 instances with outgoing access to the public Internet using IPv6 but prevent the instances from being accessed from the Internet.

NAT isn’t required with IPv6, and so NATGW’s aren’t compatible with IPv6. Egress-only gateways provide the outgoing-only access of a NATGW but do so without adjusting any IP addresses.

Architecturally, they are otherwise the same as an IGW.