A brief (kind of!) introduction to VPC in AWS

As the cloud mimics a traditional IT architecture, one of the most valuable features of the cloud is the provision of the virtual private cloud (VPC).

This provides us with a number of benefits;

• We can provision a logically isolated section of the cloud.
• We determine where resources sit within our network, we're able to determine our IP range, subnets, route tables and how we organise network gateways.
• VPC's can span multiple Availability Zones as well as feature multiple subnets.

We're able to build these networks because of elastic network interfaces, which is is a virtualized network adapter.

So in the most simple form, a VPC is a cloud-based network with a private IP address space where we can deploy compute resources. In the diagram above we can see three EC2 instances and one RDS instance sitting within our VPC. However this example isn't revealing all the complexity present yet.

Now this diagram above provides a better insight into a VPC. It distinguishes between the different availability zones anc also shows us the necessity of gateways. But we can note, the EC2 instances within the private subnets have access to a external corporate data centre but with no NAT gateway, it remains completely isolated to the public internet.

The diagram luckily provides us with the key components we'd find in a VPC;

• Subnet – Subnets are logical network segments within your VPC. They enable you to subdivide your VPC network into smaller networks inside a single Availability Zone. A subnet is public if it is attached to an internet gateway, or private if it is not. A subnet is required to deploy an instance into a VPC.
• Security group – A security group is a set of firewall rules that secure instances. They allow or block inbound and outbound traffic into an instance (stateful). If you do not specify a particular group at launch time, an instance is automatically assigned to the default security group for the VPC. A security group is associated with an instance.
• Primary network interface (elastic network interface) – An elastic network interface is a virtual network interface (NIC) that connects an instance to a network. Each instance in a VPC has a default network interface, the primary network interface, which cannot be detached from the instance.
• Router – A router is a component that routes traffic within the VPC.
• Internet gateway – An internet gateway is a VPC component that enables communication between instances in a VPC and the internet.
• Virtual private gateway – A virtual private gateway is the component that is defined on the AWS side of a virtual private network (VPN) connection. A VPN connection provides a secure and encrypted tunnel between two network endpoints.
• Customer gateway – A customer gateway is a physical device or software application that is defined on the client side of a VPN connection.

VPCs have implicit routers directing traffic between subnets. Route tables determine where traffic goes, with rules specifying destinations and targets. Default route tables, created with VPCs, route local traffic within the IP range. Subnets automatically associate with the default table, but custom tables can be created for specific subnets. VPCs may have internet gateways for routing traffic to the internet.

The router reads the route like this: “Any traffic that goes to destination should be routed through target.”

Here we have a more straight forward visualization of the route tables. Between both, default and route, we see that traffic is allowed out of the subnet only to the IP addresses in the VPC’s address range (10.0.0.0/16). We note that this is local traffic, as distinguished on the target but also because it's also a range sitting within the private subnet (subnet 2), with no NAT gateway. 

We can see however in the public subnet (subnet 1), that all traffic (0.0.0.0/0) with target of the internet gateway means that traffic to any other IP addresses is also allowed.

AWS offers multiple connectivity options for VPCs, external endpoints, and AWS services. Key options include NAT devices for private subnet traffic, Cloud peering, AWS Direct Connect with VPN, and AWS VPN CloudHub. AWS provides recommended solutions categorized by Amazon EC2 instance connectivity, VPC-to-VPC, and network-to-VPC scenarios. Differentiation includes the use of VPN connectivity or VPC endpoints where applicable.We will explore each of these options in greater depth in the rest of this blog post.

The diagram above now presents us with an architecture featuring a NAT gateway. The main route table sends internet traffic from the instances in the private subnet to the NAT gateway. The NAT gateway sends the traffic to the internet gateway by using the NAT gateways' Elastic IP address as the source IP address. It is best practice if using multiple Availability Zones that you host a NAT gateway in each Availability Zone for enhanced availability.

VPCs in AWS are isolated to their region, but you can connect them using VPC peering, a networking link which allows for private IP traffic exchange between different VPCs. Peering works across Regions and AWS accounts without the need for gateways, relying on route tables for control. It ensures communication without a single point of failure or bandwidth bottleneck. Examples include allowing resources in different accounts to communicate and facilitating data transfer, such as creating a file-sharing network. The process involves establishing a two-way connection through the AWS Management Console, with both parties initializing and accepting the connection, and ensuring non-overlapping address spaces for routing.

AWS Direct Connect establishes a physical, secure connection between your data center and AWS, creating a dedicated endpoint. One end connects to your data center router, while the other connects to an AWS Direct Connect router. Virtual interfaces are then created to directly access AWS services or VPCs, bypassing ISPs in the network path. Public virtual interfaces enable access to services like Amazon S3, while private ones enable access to a VPC, connected to a virtual private gateway. Combining Direct Connect with Site-to-Site VPN adds IPsec encryption to enhance security.

AWS VPN CloudHub provides a cost-effective solution for multiple VPC-to-remote-site VPN connections using a hub-and-spoke model. If we wanted to implement AWS VPN CloudHub, we'd create a virtual private gateway with multiple customer gateways, each configured to advertise Border Gateway Patrol (BGP) routes over AWS Site-to-Site VPN connections, enabling data exchange between sites and the VPC. 

For example, a corporate headquarters in New York connects through AWS Direct Connect, while branch offices in Los Angeles and Miami use Site-to-Site VPN connections, all operating within the AWS VPN CloudHub model as shown in the diagram above.

To facilitate a gradual transition to the cloud, AWS offers various network-to-Amazon VPC connectivity options. The primary solutions include AWS Site-to-Site VPN, AWS Direct Connect plus VPN, and AWS VPN CloudHub. 

• AWS Site-to-Site VPN establishes a secure internet connection between your VPC and remote network using IPsec, requiring a virtual private gateway on the AWS side and a customer gateway on the remote side.
  
  
• AWS Direct Connect plus VPN combines AWS Direct Connect's dedicated private connection with AWS Site-to-Site VPN features. Direct Connect creates a private link from your data center to VPCs via a fiber-optic cable, providing enhanced privacy and bandwidth. This results in a secure IPSec-based connection.

VPC endpoints enable secure and private connections between a VPC and supported AWS services or VPC endpoint services via AWS PrivateLink. This method eliminates the need for an internet gateway, NAT device, VPN, or AWS Direct Connect. Two types of VPC endpoints exist:

1. Interface endpoint: Acts as a virtual network interface attached to an EC2 instance, allowing connection to services through AWS PrivateLink. Services, including custom ones, can be powered by AWS PrivateLink, referred to as VPC endpoint services.

2. Gateway endpoint: Provides direct access to Amazon S3 and DynamoDB resources without internet routing. It is configured in a route table, facilitating efficient connection to the target resource.

AWS PrivateLink ensures secure connections between VPCs and various services, including AWS services, third-party services on AWS Marketplace and custom services on AWS. The traffic uses private IP addresses, staying within the AWS network.

Supported AWS services accessible via interface endpoints include Amazon EC2, Elastic Load Balancing, and AWS Systems Manager. We can see the diagram above shows an instance i connected to three interface endpoints. The first connects to an AWS service (e.g., Systems Manager), the second to an AWS Marketplace service (potentially third-party), and the third to a custom service created by the consumer, exposed through AWS PrivateLink as a VPC endpoint service. Custom services are onboarded by setting up a Network Load Balancer in front of them, connecting the interface endpoint to the load balancer.

AWS Transit Gateway simplifies the complexity of interconnecting growing numbers of VPCs in the AWS Cloud environment. Unlike the exponential growth and operational challenges of peering connections, Transit Gateway offers a centralized solution. It acts as a hub, efficiently managing traffic routing among connected networks, serving as spokes. This hub-and-spoke model streamlines management and reduces operational costs, requiring each network only to connect to the Transit Gateway and not every other network.

Securing and Troubleshooting Your Network

To enhance network security, adopting a layered design is crucial. This layered network approach leverages various components for effective control. Route tables play a key role in regulating traffic flow, while Network Access Control Lists (NACLS) are employed to control inbound and outbound traffic within networks. Security Groups (SGs) further manage traffic, focusing on hosts and services. Additionally, secure access for administration is achieved through the implementation of Bastion hosts, facilitating secure connections to Linux-based hosts and remote desktops (RDP) for Windows. 

When troubleshooting network issues, a systematic approach is the recommended path. It involves verifying the availability of the resource, checking for any potential blockages in NACLS or SGs, and ensuring correct routing for the specific host or service in question.

Your virtual network can and should be secured at several different levels:

1. Begin with broad security measures at the route table level, establishing private subnets to shield internal computing resources from unauthorized access.
2. The second level employs network access control lists (network ACLs) to set default security behaviors for subnets, typically overseen by the network security team.
3. Move to the third level, utilizing security groups to manage behavior at the instance or elastic network interface level.
4. Finally, at the fourth level, consider implementing third-party host-based detection software to monitor Amazon EC2 instances for specific threats like malware, operating system vulnerabilities, and security auditing.

A bastion host acts as a secure gateway, enabling access from the public internet to Amazon EC2 instances and resources in a private subnet. This setup allows public access to private resources while minimizing the attack surface of the private subnet. To ensure security, users must possess valid keys for both the bastion host and private instances. AWS strongly recommends using different key pairs for the bastion host and private subnet resources to prevent unauthorized access.

For Linux instances, SSH clients with agent forwarding support enable the passing of private keys from the client through the SSH connection with the bastion host to access private network resources.

For Windows instances, the Amazon EC2 console can be used to generate a login password with the private key. The Remote Desktop (RDP) client program is then employed to log in to the private instance using the generated password.

How do you configure security groups to allow the bastion host to access an instance in your private subnet?

Begin by configuring the bastion host to permit connections exclusively from within the corporate network, preventing external access. For instance, the bastion host in the example only accepts SSH connections from clients within the 17.5.0.0/16 address range.

Next, establish a rule in the private instance's security group, allowing incoming traffic solely from instances associated with the bastion host's security group. For example, if the bastion host has a security group named sg-192d536a, specify that the private subnet server permits incoming connections exclusively from instances in security group sg-192d536a. This rule ensures flexibility and reusability compared to restricting connections to the IP address of the bastion host.

When managing Microsoft Windows instances in Amazon EC2 via RDP, configuring security group rules for TCP port 3389 is essential. Following the principle of least privilege, it's recommended to allow connections only from specific IP addresses where administrators operate, denying all others. However, in cases where administrators connect from various locations, allowing every IP address (0.0.0.0/0) becomes a common, yet insecure practice.

To address this, a more secure solution involves implementing a Microsoft Remote Desktop (RD) Gateway server as a bastion host. Configured to accept HTTPS connections (TCP port 443) from any internet IP address, the RD Gateway then proxies these connections to other Windows instances through RDP port (TCP port 3389). Access to the protected Windows instances is restricted to users who authenticate through the RD Gateway, ensuring a secure network layer and enforcing the principle of least privilege.

A very typical problem is users not being able to connect to their EC2 instance. The most basic of troubleshooting steps are outlined herein:

Firstly, ensure the instance is running, and secondly, confirm that the security group permits connections on the relevant port(s) (e.g., port 22 for SSH or port 80/443 for web servers). Additionally, check if the public IP address has changed, especially after stopping and restarting an instance, and validate the correctness of internet gateway and route table settings.

Verify user login details, ensuring the correct username and password combination is used, as not all EC2 instances have an ec2-user defined. When connecting through SSH, confirm the accurate use of the private key with correct access permissions.

Lastly, leverage the ping tool, available in both Microsoft Windows and Linux, as a networking utility to test host reachability on the IP network. Addressing these aspects systematically can resolve common EC2 connectivity issues.

After setting up a NAT gateway or NAT instance, updating the associated subnet's route table is crucial. The route table should direct internet-bound traffic to the NAT gateway or instance, allowing private instances to communicate with the internet.

It's important to note that AWS-created NAT instances, when used, don't require troubleshooting by system administrators. This is especially relevant for companies modifying NAT instances to align with their security rules or processes.