Virtual Private Cloud (VPC)

VPC Simplified:

VPC lets you provision a logically isolated section of the AWS cloud where you can launch services and systems within a virtual network that you define. By having the option of selecting which AWS resources are public facing and which are not, VPC provides much more granular control over security.

VPC Key Details:

• You can think of VPC as your own virtual data center in the cloud. You have complete control of your own network; including the IP range, the creation of sub-networks (subnets), the configuration of route tables and the network gateways used.
• You can then launch EC2 instances into a subnet of your choosing, select the IPs to be available for the instances, assign security groups for them, and create Network Access Control Lists (NACLs) for the subnets themselves as additional protection.
• This customization gives you much more control to specify and personalize your infrastructure setup. For example, you can have one public-facing subnet for your web servers to receive HTTP traffic and then a different private-facing subnet for your database server where internet access is forbidden.
• You use subnets to efficiently utilize networks that have a large number of hosts
• VPCs come with defense in depth by design. From the sub-network (NACLs) down to the individual server (security group) and further down to the application itself (secure coding practices), you can set up multiple levels of protection against malicious users and programs.
• The default VPC for your AWS environment permits all subnets to have a route out to the internet meaning all subnets in the default VPC are internet accessible. The default setting allows you to immediately deploy instances and each EC2 instance will have both a public and private IP address.
• There is one default VPC per region. However, you can have as many custom VPCs as you want and all are private by default.
• When you create a custom VPC, new subnets are not created by default. You must create them separately. The same is true for an internet gateway. If you want your VPC to have internet access, you need to also create the gateway so that the network can be reached publicly by the world.
• Because of this, when you create an IGW it will initially be in an detached state. You will need to manually assign it to the custom VPC.
• Once you create a custom VPC however, the following are created by default:
  • a route table
  • a NACL
  • a security group

• These components, which will be explained in further depth in case they are not already known, actually correspond to the traffic flow for how data will reach your instances. Whether the traffic originates from outside of the VPC or from within it, it must first go through the route table by way of the router in order to know where the desired destination is. Once that is known, the traffic then passes through subnet level security as described by the NACL. If the NACL deems the traffic as valid, the traffic then passes through to the instance level security as described by the security group. If the traffic hasn’t been dropped at this point, only then will it reach its intended instance.
• The VPC Wizard is an automated tool that is useful for creating custom VPCs.
• You can have your VPC on dedicated hardware so that the network is exclusive at the physical level, but this option is extremely expensive. Fortunately, if a VPC is on dedicated hosting it can always be changed back to the default hosting. This can be done via the AWS CLI, SDK or API. However, existing hosts on the dedicated hardware must first be in a stopped state.
• When you create a VPC, you must assign it an IPv4 CIDR block. This CIDR block is a range of private IPv4 addresses that will be inherited by your instances when you create them.
• The IP range of a default VPC is always /16.
• When creating IP ranges for your subnets, the /16 CIDR block is the largest range of IPs that can be used. This is because subnets must have just as many IPs or fewer IPs than the VPC it belongs to. A /28 CIDR block is the smallest IP range available for subnets.
• With CIDR in general, a /32 denotes a single IP address and /0 refers to the entire network The higher you go in CIDR, the more narrow the IP range will be.
• The above information about IPs is in regards to both public and private IP addresses.
• Private IP addresses are not reachable over the Internet and instead are used for communication between the instances in your VPC. When you launch an instance into a VPC, a private IP address from the IPv4 address range of the subnet is assigned to the default network interface (eth0) of the instance.
• This means that all instances within a VPC has a private IP, but only those selected to communicate with the external world have a public IP.
• When you launch an instance into a subnet that has public access via an Internet Gateway, both a public IP address and a private IP address are created. The public IP address is instead assigned to the primary network interface (eth0) that’s created for the instance. Externally, the public IP address is mapped to the private IP address through network address translation (NAT).
• You can optionally associate an IPv6 CIDR block with your VPC and subnets, and assign IPv6 addresses from that block to the resources in your VPC.
• VPCs are region specific and you can have up to five VPCs per region.
• By default, AWS is configured to have one subnet in each AZ of the regions where your application is.
• In an ideal and secure VPC architecture, you launch the web servers or elastic load balancers in the public subnet and the database servers in the private subnet.
• Here is an example of a hypothetical application sitting behind a typical VPC setup:

• Security groups can span subnets, but do not span VPCs. ICMP ensures that instances from one security group can ping others in a different security group. It is IPv4 and IPv6 compatible.

VPC Subnets:

• If a network has a large number of hosts without logically grouped subdivisions, managing the many hosts can be a tedious job. Therefore you use subnets to divide a network so that management becomes easier.
• When you create a subnet, be sure to specify which VPC you want to place it in. You can assign both IPv4 and IPv6 ranges to your subnets.
• The main benefits of subnets:
  • They improve traffic flow, and thus speed & performance of the entire network. An Internet gateway (IGW) receiving a packet and checking which of 5 subnets the packet should be delivered to is much faster than checking 100 instances individually. And if the destination of a packet is within the subnet from where it originates, the traffic stays inside the subnet and doesn’t clutter the rest of the VPC.
  • Subnets function as logical groups to put your entities inside of. It makes it much easier to configure similar resources as a group instead of for every individual instance.
• Amazon always reserves five IP addresses within a subnet. The first four IP addresses and the last IP address of each subnet CIDR block will always be unavailable for use.

Network Access Control Lists:

• Network Access Control Lists (or NACLs) are like security groups but for subnets rather than instances. The main difference between security groups and NACLs is that security groups are stateful, meaning you can perform both allow and deny rules that may be divergent, depending if traffic is inbound or outbound, for that rule.
• The following table highlights the differences between NACLs and Subnets.

• Because NACLs are stateless, you must also ensure that outbound rules exist alongside the inbound rules so that ingress and egress can flow smoothly.

• The default NACL that comes with a new VPC has a default rule to allow all inbounds and outbounds. This means that it exists, but doesn’t do anything as all traffic passes through it freely.

• However, when you create a new NACL (instead of using the default that comes with the VPC) the default rules will deny all inbounds and outbounds.

• If you create a new NACL, you must associate whichever desired subnets to it manually so that they can inherit the NACL’s rule set. If you don’t explicitly assign a subnet to an NACL, AWS will associate it with your default NACL.

• NACLs are evaluated before security groups and you block malicious IPs with NACLs, not security groups.

• A subnet can only follow the rules listed by one NACL at a time. However, a NACL can describe the rules for any number of subnets. The rules will take effect immediately.

• Network ACL rules are evaluated by rule number, from lowest to highest, and executed immediately when a matching allow/deny rule is found. Because of this, order matters with your rule numbers.

• The lower the number of a rule on the list, the more seniority that rule will have. List your rules accordingly.

• If you are using NAT Gateway along with your NACL, you must ensure the availability of the NAT Gateway ephemeral port range within the rules of your NACL. Because NAT Gateway traffic can appear on any of range’s ports for the duration of its connection, you must ensure that all possible ports are accounted for and open.

• NACL can have a small impact on how EC2 instances in a private subnet will communicate with any service, including VPC Endpoints.

NAT Instances vs. NAT Gateways:

• Attaching an Internet Gateway to a VPC allows instances with public IPs to directly access the internet. NAT does a similar thing, however it is for instances that do not have a public IP. It serves as an intermediate step which allow private instances to first masked their own private IP as the NAT’s public IP before accessing the internet.
• You would want your private instances to access the internet so that they can have normal software updates. NAT prevents any initiating of a connection from the internet.
• NAT instances are individual EC2 instances that perform the function of providing private subnets a means to securely access the internet.
• Because they are individual instances, High Availability is not a built-in feature and they can become a choke point in your VPC. They are not fault-tolerant and serve as a single point of failure. While it is possible to use auto-scaling groups, scripts to automate failover, etc. to prevent bottlenecking, it is far better to use the NAT Gateway as an alternative for a scalable solution.
• NAT Gateway is a managed service that is composed of multiple instances linked together within an availability zone in order to achieve HA by default.
• To achieve further HA and a zone-independent architecture, create a NAT gateway for each Availability Zone and configure your routing to ensure that resources use the NAT gateway in their corresponding Availability Zone.
• NAT instances are deprecated, but still useable. NAT Gateways are the preferred means to achieve Network Address Translation.
• There is no need to patch NAT Gateways as the service is managed by AWS. You do need to patch NAT Instances though because they’re just individual EC2 instances.
• Because communication must always be initiated from your private instances, you need a route rule to route traffic from a private subnet to your NAT gateway.
• Your NAT instance/gateway will have to live in a public subnet as your public subnet is the subnet configured to have internet access.
• When creating NAT instances, it is important to remember that EC2 instances have source/destination checks on them by default. What these checks do is ensure that any traffic it comes across must be either generated by the instance or be the intended recipient of that traffic. Otherwise, the traffic is dropped because the EC2 instance is neither the source nor the destination.
• So because NAT instances act as a sort of proxy, you must disable source/destination checks when musing a NAT instance.

Bastion Hosts:

• Bastion Hosts are special purpose computers designed and configured to withstand attacks. This server generally runs a single program and is stripped beyond this purpose in order to reduce attack vectors.
• The purpose of Bastion Hosts are to remotely access the instances behind the private subnet for system administration purposes without exposing the host via an internet gateway.
• The best way to implement a Bastion Host is to create a small EC2 instance that only has a security group rule for a single IP address. This ensures maximum security.
• It is perfectly fine to use a small instance rather than a large one because the instance will only be used as a jump server that connects different servers to each other.
• If you are going to RDP or SSH into the instances of your private subnet, use a Bastion Host. If you are going to be providing internet traffic into the instances of your private subnet, use a NAT.
• Similar to NAT Gateways and NAT Instances, Bastion Hosts live within a public-facing subnet.
• There are pre-baked Bastion Host AMIs.

Route Tables:

• Route tables are used to make sure that subnets can communicate with each other and that traffic knows where to go.
• Every subnet that you create is automatically associated with the main route table for the VPC.
• You can have multiple route tables. If you do not want your new subnet to be associated with the default route table, you must specify that you want it associated with a different route table.
• Because of this default behavior, there is a potential security concern to be aware of: if the default route table is public then the new subnets associated with it will also be public.
• The best practice is to ensure that the default route table where new subnets are associated with is private.
• This means you ensure that there is no route out to the internet for the default route table. Then, you can create a custom route table that is public instead. New subnets will automatically have no route out to the internet. If you want a new subnet to be publicly accessible, you can simply associate it with the custom route table.
• Route tables can be configured to access endpoints (public services accessed privately) and not just the internet.

Internet Gateway:

• If the Internet Gateway is not attached to the VPC, which is the prerequisite for instances to be accessed from the internet, then naturally instances in your VPC will not be reachable.
• If you want all of your VPC to remain private (and not just some subnets), then do not attach an IGW.
• When a Public IP address is assigned to an EC2 instance, it is effectively registered by the Internet Gateway as a valid public endpoint. However, each instance is only aware of its private IP and not its public IP. Only the IGW knows of the public IPs that belong to instances.
• When an EC2 instance initiates a connection to the public internet, the request is sent using the public IP as its source even though the instance doesn’t know a thing about it. This works because the IGW performs its own NAT translation where private IPs are mapped to public IPs and vice versa for traffic flowing into and out of the VPC.
• So when traffic from the internet is destined for an instance’s public IP endpoint, the IGW receives it and forwards the traffic onto the EC2 instance using its internal private IP.
• You can only have one IGW per VPC.
• Summary: IGW connects your VPC with the internet.

Virtual Private Networks (VPNs):

• VPCs can also serve as a bridge between your corporate data center and the AWS cloud. With a VPC Virtual Private Network (VPN), your VPC becomes an extension of your on-prem environment.
• Naturally, your instances that you launch in your VPC can’t communicate with your own on-premise servers. You can allow the access by first:
  • attaching a virtual private gateway to the VPC
  • creating a custom route table for the connection
  • updating your security group rules to allow traffic from the connection
  • creating the managed VPN connection itself.
• To bring up VPN connection, you must also define a customer gateway resource in AWS, which provides AWS information about your customer gateway device. And you have to set up an Internet-routable IP address of the customer gateway’s external interface.
• A customer gateway is a physical device or software application on the on-premise side of the VPN connection.
• Although the term “VPN connection” is a general concept, a VPN connection for AWS always refers to the connection between your VPC and your own network. AWS supports Internet Protocol security (IPsec) VPN connections.
• The following diagram illustrates a single VPN connection.

• The above VPC has an attached virtual private gateway (note: not an internet gateway) and there is a remote network that includes a customer gateway which you must configure to enable the VPN connection. You set up the routing so that any traffic from the VPC bound for your network is routed to the virtual private gateway.
• Summary: VPNs connect your on-prem with your VPC over the internet.

AWS DirectConnect:

• Direct Connect is an AWS service that establishes a dedicated network connection between your premises and AWS. You can create this private connectivity to reduce network costs, increase bandwidth, and provide more consistent network experience compared to regular internet-based connections.
• The use case for Direct Connect is high throughput workloads or if you need a stable or reliable connection
• VPN connects to your on-prem over the internet and DirectConnect connects to your on-prem off through a private tunnel.
• The steps for setting up an AWS DirectConnect connection:
  1. Create a virtual interface in the DirectConnect console. This is a public virtual interface.
  2. Go to the VPC console and then VPN connections. Create a customer gateway for your on-premise.
  3. Create a virtual private gateway and attach it to the desired VPC environment.
  4. Select VPN connections and create a new VPN connection. Select both the customer gateway and the virtual private gateway.
  5. Once the VPN connection is available, set up the VPN either on the customer gateway or the on-prem firewall itself
• Data flow into AWS via DirectConnect looks like the following: On-prem router -> dedicated line -> your own cage / DMZ -> cross connect line -> AWS Direct Connect Router -> AWS backbone -> AWS Cloud
• Summary: DirectConnect connects your on-prem with your VPC through a non-public tunnel.

VPC Endpoints:

• VPC Endpoints ensure that you can connect your VPC to supported AWS services without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect. Traffic between your VPC and other AWS services stay within the Amazon ecosystem and these Endpoints are virtual devices that are HA and without bandwidth constraints.
• These work basically by attaching an ENI to an EC2 instance that can easily communicate to a wide range of AWS services.
• Gateway Endpoints rely on creating entries in a route table and pointing them to private endpoints used for S3 or DynamoDB. Gateway Endpoints are mainly just a target that you set.
• Interface Endpoints use AWS PrivateLink and have a private IP address so they are their own entity and not just a target in a route table. Because of this, they cost $.01/hour. Gateway Endpoints are free as they’re just a new route in to set.
• Interface Endpoint provisions an Elastic Network interface or ENI (think network card) within your VPC. They serve as an entry and exit for traffic going to and from another supported AWS service. It uses a DNS record to direct your traffic to the private IP address of the interface. Gateway Endpoint uses route prefix in your route table to direct traffic meant for S3 or DynamoDB to the Gateway Endpoint (think 0.0.0.0/0 -> igw).
• To secure your Interface Endpoint, use Security Groups. But to secure Gateway Endpoint, use VPC Endpoint Policies.
• Summary: VPC Endpoints connect your VPC with AWS services through a non-public tunnel.

AWS PrivateLink:

• AWS PrivateLink simplifies the security of data shared with cloud-based applications by eliminating the exposure of data to the public Internet. AWS PrivateLink provides private connectivity between different VPCs, AWS services, and on-premises applications, securely on the Amazon network.
• It’s similar to the AWS Direct Connect service in that it establishes private connections to the AWS cloud, except Direct Connect links on-premises environments to AWS. PrivateLink, on the other hand, secures traffic from VPC environments which are already in AWS.
• This is useful because different AWS services often talk to each other over the internet. If you do not want that behavior and instead want AWS services to only communicate within the AWS network, use AWS PrivateLink. By not traversing the Internet, PrivateLink reduces the exposure to threat vectors such as brute force and distributed denial-of-service attacks.
• PrivateLink allows you to publish an “endpoint” that others can connect with from their own VPC. It’s similar to a normal VPC Endpoint, but instead of connecting to an AWS service, people can connect to your endpoint.
• Further, you’d want to use private IP connectivity and security groups so that your services function as though they were hosted directly on your private network.
• Remember that AWS PrivateLink applies to Applications/Services communicating with each other within the AWS network. For VPCs to communicate with each other within the AWS network, use VPC Peering.
• Summary: AWS PrivateLink connects your AWS services with other AWS services through a non-public tunnel.

VPC Peering:

• VPC peering allows you to connect one VPC with another via a direct network route using the Private IPs belonging to both. With VPC peering, instances in different VPCs behave as if they were on the same network.
• You can create a VPC peering connection between your own VPCs, regardless if they are in the same region or not, and with a VPC in an entirely different AWS account.
• VPC Peering is usually done in such a way that there is one central VPC that peers with others. Only the central VPC can talk to the other VPCs.
• You cannot do transitive peering for non-central VPCs. Non-central VPCs cannot go through the central VPC to get to another non-central VPC. You must set up a new portal between non-central nodes if you need them to talk to each other.
• The following diagram highlights the above idea. VPC B is free to communicate with VPC A with VPC Peering enabled between both. However, VPC B cannot continue the conversation with VPC C. Only VPC A can communicate with VPC C.

• It is worth knowing what VPC peering configurations are not supported:
  • Overlapping CIDR Blocks
  • Transitive Peering
  • Edge to Edge Routing through a gateway or connection device (VPN connection, Internet Gateway, AWS Direct Connect connection, etc.)
• You can peer across regions, but you cannot have one subnet stretched over multiple availability zones. However, you can have multiple subnets in the same availability zone.
• Summary: VPC Peering connects your VPC to another VPC through a non-public tunnel.

VPC Flow Logs:

• VPC Flow Logs is a feature that captures the IP information for all traffic flowing into and out of your VPC. Flow log data is sent to an S3 bucket or CloudWatch where you can view, retrieve, and manipulate this data.

• You can capture the traffic flow at various stages through its travel:

  • Traffic flowing into and out of the VPC (like at the IGW)
  • Traffic flowing into and out of the subnet
  • Traffic flowing into and out of the network interface of the EC2 instance (eth0, eth1, etc.)

• VPS Flow Logs capture packet metadata and not packet contents. Things like:

  • The source IP
  • The destination IP
  • The packet size
  • Anything which could be observed from outside of the packet.

• Your flow logs can be configured to log valid traffic, invalid traffic, or both

• You can have flow logs sourced from a different VPC compared to the VPC where your Flow Logs are. However, the other VPC must be peered via VPC Peering and under your account via AWS Organizations.

• You can customize your logs by tagging them.

• Once you create a Flow Log, you cannot change its config. You must make a new one.

• Not all IP traffic is monitored under VPC Flow Logs. The following is a list of things that are ignored by Flow Logs:

  • Query requests for instance metadata
  • DHCP traffic
  • Query requests to the AWS DNS server

  AWS Global Accelerator:

• AWS Global Accelerator accelerates connectivity to improve performance and availability for users. Global Accelerator sits on top of the AWS backbone and directs traffic to optimal endpoints worldwide. By default, Global Accelerator provides you two static IP addresses that you can make use of.

• Global Accelerator helps reduce the number of hops to get to your AWS resources. Your users just need to make it to an edge location and once there, everything will remain internal to the AWS global network. Normally, it takes many networks to reach the application in full and paths to and from the application may vary. With each hop, there is risk involved either in security or in failure.

• In summary, Global Accelerator is a fast/reliable pipeline between user and application.
• It’s like going on a trip (web traffic) and stopping to ask for directions in possibly unsafe parts of town (multiple networks are visited which can increase security risks) as opposed to having a GPS (global accelerator) that leads you directly where you want to go (endpoint) without having to make unnecessary stops.
• It can be confused with Cloudfront, but CloudFront is a cache for content stemming from a distant origin server.
• While CloudFront simply caches static content to the closest AWS Point Of Presence (POP) location, Global accelerator will use the same Amazon POP to accept initial requests and routes them directly to the services.
• Route53’s latency based routing might also appear similar to Global Accelerator, but Route 53 is for simply helping choose which region for the user to use. Route53 has nothing to do with actually providing a fast network path.
• Global Accelerator also provides fast regional failover.