AWS VPC Intro and Best Practices
What is an AWS VPC?
An AWS Virtual Private Cloud (VPC) is a logical virtual network specific to you within your AWS account. It allows you to control all your resources in your own virtual network, from choosing your own IP ranges, creation of subnets and defining route tables. It also allows you to secure your resources by isolating them from the open internet or by controlling who can access them using private subnets, security groups and NACLs (Network Access Control Lists).
Historically you were only able to launch an EC2-Classic instance in a single flat network that you share with other customers. However, since 2009 Amazon made the use of VPCs compulsory and has defined a default VPC in each AWS Region of our account.
Why use a VPC?
Well, as we saw above, because you have to. But lets really see how we can take advantage of the low cost and flexibility of the AWS VPC.
When you deploy your services in the cloud, they are essentially exposed to the open internet. Using a VPC allows you to deploy your resources and services in a virtual network in the AWS cloud. This allows you to define your own network space, and control how your network and the resources inside your network are exposed to the internet. You can also leverage the enhanced security options in Amazon VPC to provide more granular access to and from your resources in your virtual network.
Let’s explore some concepts…..
Subnets
A subnet is a logical subdivision of an IP network. AWS VPC allows you to define two types of subnets, private and public subnets, the main difference being that a public subnet has routing via an Internet Gateway where a private subnet does not. All resources within a VPC, whether in a private or public subnet have access to each other using their private IPs. You can also define multiple subnets in the same Availability Zone.
Public Subnet
A public subnet is internet facing. All its traffic is routed via the Internet Gateway. It has both access to and from the internet. You would place instances or resources that needs to be accessed from outside your VPC in a public subnet, client-facing web servers for example.
Private Subnet
A private subnet on the other hand, has no access to and from the internet, it only has access to local resources within your VPC, this would be ideal to place your backend systems such as databases or application servers. If however, you do need access to the internet you can do so by using a NAT Gateway and define the routing in the subnet route table.
Availability Zones
AWS VPCs are hosted in multiple locations world-wide. These locations are composed of Regions, Availability Zones, Local Zones, AWS Outposts and Wavelength Zones. For now we will take a look at Availability Zones.
An Availability Zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity within an AWS Region. AZ’s give you the ability to operate production applications and databases that are more highly available, fault tolerant, and scalable than would be possible from a single data center. If you application is partitioned across multiple AZ’s, you are better isolated and protected from issues such as power outages, lightning strikes, tornadoes, earthquakes, and more.
Route Tables
A route table contains a set of rules, called routes, that are used to determine where network traffic from your subnet or gateway is directed. In other words, a route table tells network packets which way they need to go in order to reach their destination. Every VPC has an implicit router that uses route tables to direct the network traffic.
When creating a VPC, default route tables are created called main route tables. You can of course create your own custom route tables which you can then associate with a subnet, this is called route table association. Every subnet needs to have an associated route table. Otherwise it is assigned the default route table. A subnet can only be associated with one route table but one route table can be associated with multiple subnets.
Route tables are made up of destination and target where the destination can be a single IP address or a range of IP addresses where you want traffic to go. The target defines the gateway, network interface, or connection through which to send the destination traffic; for example, a NAT GW. Every route table should also have the local route that is the default route for all communication within the VPC.
NAT Gateway
A Network Address Translation (NAT) Gateway allows instances in a private subnet to connect to the internet or any other AWS services, at the same time prevents access from the open internet. A NAT device transparently changes the origination address of traffic coming through it before passing it to the internet. When defining a NAT GW you need to define which public subnet it will reside in as well as assign it an Elastic IP.
AWS also takes care of managing and scaling the NAT GW. It supports 5 Gbps of bandwidth and automatically scales up to 45 Gbps, of course if you need more, you can spread your workload across multiple NAT GWs in multiple subnets.
As an added benefit, all traffic from a private subnet that is routed through a NAT GW will have the same source IP, the Elastic IP of the NAT GW, which allows you to grant access to instances within your private subnet to any service or server outside of your VPC by simply whitelisting the IP of the NAT GW.
Security Groups and Network ACLs
AWS provides features that you can use to monitor and increase the security for your VPC, mainly security groups and Network ACLs.
Security Groups
Security groups act as a firewall for associated EC2 instances, ALBs and other resources, controlling both inbound and outbound traffic at the instance level. When launching an instance, you can either associate the instance with up to five security groups that you’ve already created, or create a new security group. If you do not specify a security group when you launch an instance, the instance will be automatically associated with a default security group.
After you launch an instance you can change and update its security groups while the instance in running.
Security groups are stateful, meaning, if an inbound request passes then the outbound request will pass as well. Even if there is a rule denying any traffic out of the EC2 instance.
Network access control lists (ACLs)
Network ACLs are like a firewall which control traffic to and from associated subnets. Default NACLs allow all inbound and outbound traffic and you can only define one NACL per subnet.
Network ACLs are stateless, meaning, all inbound and outbound rules passing through the subnet will be evaluated.
NACLs use rules for evaluation of the traffic. Each rule gets a number (1–32766) and gives higher precedence to a lower number. The last rule will always be assigned and asterisk (*) and denies a request in the case that no rules match. As an example: If you define #100 Allow <IP> and #200 Deny <IP> then the IP will be allowed.
Costs
Amongst all of the enhanced security options that the AWS VPC provides us with, costs are also important and cannot be ignored. When launching new instances or resources within your VPC it is important to take into consideration how you can keep your running costs as low as possible by leveraging the abilities of the AWS VPC.
AWS does not only charge you for the running of your instances but also for data transfer.
In order to keep a precise accounting of all your AWS data transfer costs or if you want to optimize your AWS architecture before deploying it, you first need to know exactly how data transfers are charged. This can be a little bit tricky as some data transfer types are charged only one-way (either in or out), others have a fee for inbound traffic and another fee for outbound traffic, such as when transferring data between EC2 instances in different Availability Zones, VPCs, or Regions.
In general, AWS charges users for data transfers in either of two ways: into and out of AWS Regions and the internet, and within the AWS cloud.
Let’s take a look at both.
Data transfer costs into or out of AWS regions
Data transfer into all AWS Regions from the internet is free.
Transfers that send data out over the internet are billed at region-specific and tiered data transfer rates. You can view the latest region-specific, tiered pricing for data transfer to the internet for all AWS regions here. As an example, see the screenshot below of the tiered pricing for data transfer out to the internet from the AWS N. Virginia Region as of January 2021.
Data transfer costs within the AWS Cloud
There are a few ways in which you can move data around within the AWS cloud.
Inter-Region data transfers: Inter-region data transfer fees are charged at the source region rates. You can find all the source-specific region rates here. No fees have to be paid for the incoming traffic at the destination region. As an example, see the screenshot below for outbound data transfer from the AWS N. Virginia Region to other AWS Regions as of January 2021.
AWS Data transfer costs within the same region: Any time AWS resources or services communicate with each other within the same Region, there could be a potential fee attached to it. This is the type of AWS data transfer cost that can be a little trickier to keep track of and understand.
Data transferred between instances, containers, Elastic Network Interfaces or VPC peering connections across Availability Zones via public, private or Elastic IPv4, or IPv6 addresses is charged at $0.01 per GB for outbound traffic and $0.01 per GB for inbound traffic.
Data transferred between EC2 instances or containers, or Elastic Network Interfaces in the same Availability Zone and same VPC over private IPv4 or IPv6 addresses are free.
So as you can see, it is important to understand the data transfer costs and consider how you can leverage the AWS VPC capabilities in order to build better cost-efficient cloud infrastructure.
Some Best Practices and Tips
- When creating your VPC it is recommended that you create 2 private and 2 public subnets in different Availability Zones to ensure high availability.
- In order to keep security groups relatively small and specific you can nest security groups within security groups.
- When defining Network ACLs, it is recommended that your rules are added in increments of 100.
- If you need to route traffic to a NAT GW from a public subnet you need to ensure that the NAT GW does not reside in that same subnet, otherwise the routing will by default be routed to the internet gateway.
- It is recommended that you create custom route tables for your private subnets as well as create separate route tables for each subnet.
- Routing traffic to an Elastic Load Balancer (ELB) — ELB’s do not have an Elastic IP and therefore cannot be defined in a route table as a destination. But with a newly released service called AWS Global Accelerator you can setup your ELB to use the service which will automatically provides you with two global static customer facing IPs to simplify traffic management. You can find out more in the post here.
Thank you! Other articles you might like
If you have feedback, corrections, questions, or just want to connect, please reach out to me on LinkedIn⭐
