Amazon Virtual Private Cloud or VPC, as it is popularly known, is a logically separated, isolated, and secure virtual network on the cloud, where you provision your infrastructure, such as Amazon RDS instances and Amazon EC2 instances. It is a core component of networking services on AWS cloud.
A VPC is dedicated to your AWS account. You can have one or more VPCs in your AWS account to logically isolate your resources from each other. By default, any resource provisioned in a VPC is not accessible by the internet unless you allow it through AWS-provided firewalls. A VPC spans an AWS region.
VPC is essentially your secure private cloud within AWS public cloud. It is specifically designed for users who require an extra layer of security to protect their resources on the cloud. It segregates your resources with other resources within your AWS account. You can define your network topology as per your requirements, such as if you want some of your resources hidden from public or if you want resources to be accessible from the internet.
Getting the design of your VPC right is absolutely critical for having a secure, fault-tolerant, and scalable architecture.
It resembles a traditional network in a physical data center in many ways, for example, having similar components such as subnets, routes, and firewalls; however, it is a software-defined network that performs the job of data centers, switches, and routers. It is primarily used to transport huge volume of packets into, out of, and across AWS regions in an optimized and secured way along with segregating your resources as per their access and connectivity requirements. And because of these features, VPC does not need most of the traditional networking and data center gear.
VPC gives you granular control to define what traffic flows in or out of your VPC.
In this lesson, we will deep dive into the security of AWS VPC. VPC is the most important component of networking services in AWS. Networking services are one of the foundation services on the AWS cloud. A secure network is imperative to ensure security in AWS for your resources.
We will look at components that make up VPC, such as subnets, security groups, various gateways, and so on. We will take a deep dive into the AWS VPC features and benefits such as simplicity, security, multiple connectivity options, and so on.
We will look at the following most popular use cases of VPC that use various security and connectivity features of VPC:
Hosting a public-facing website
Hosting multi-tier web applications
Creating branch office and business unit networks
Hosting web applications in AWS cloud that are connected with your data center
Extending corporate network on the cloud
AWS provides multiple measures to secure resources in VPC and monitor activities in VPC, such as security groups, network access control list (ACL), and VPC flow logs. We will dive deep into each of these measures.
Next, we'll walk through the process of creating a VPC. You can either choose to create a VPC through the wizard, through the console, or through the CLI.
Furthermore, we'll go through the following VPC connectivity options along with VPC limits in detail:
Network to AWS VPC
AWS VPC to AWS VPC
Internal user to AWS VPC
We'll wrap up this lesson with VPC best practices.
Throughout this lesson, we'll take a look at AWS architecture diagrams for various use cases, connectivity options, and features. The objective of this lesson is to familiarize you with AWS VPC and let you know about ways to secure your VPC.
AWS VPC is a logically separated network isolated from other networks. It lets you set your own IP address range and configure security settings and routing for all your traffic. AWS VPC is made up of several networking components, as shown in the following figure; some of them are as follows:
Elastic network interfaces
Elastic IP addresses
Let's take a closer look at these components:
A VPC spans an AWS region. A region contains two or more availability zones. A VPC contains subnets that are used to logically separate resources inside a region. A subnet cannot span across multiple availability zones. A subnet can either be a private subnet or a public subnet based on its accessibility from outside of VPC and if it can access resources outside of VPC.
Subnets are used for separating resources, such as web servers and database servers. They are also used for making your application highly available and fault-tolerant. By default, all resources in all subnets of a VPC can route (communicate) to each other using private IP addresses.
The ENI are available for EC2 instances running inside a VPC. An ENI can have many attributes, such as a primary private IPv4 address, a MAC address, one or more security groups, one or more IPv6 addresses, and so on. These attributes will move with ENI when an ENI is attached to an instance; when this ENI is detached from an instance, these attributes will be removed.
By default, every VPC has a network interface attached to every instance. This ENI is known as a primary network interface (eth0). This default ENI cannot be detached from an instance. You can, however, create and attach many additional ENIs to your instances inside a VPC.
One of the popular use cases of ENI is having secondary ENI attached to instances running network and security appliances, such as network address translation servers or load balancers. These ENIs can be configured with their own attributes, such as public and private IP address, security groups, and so on.
As you've learned about VPC, it essentially facilitates traffic in and out of a software-defined network. This traffic needs to know where to go, and this is achieved via route tables. A route table in VPC has rules or routes defined for the flow of traffic. Every VPC has a default route table that is known as the main route table. You can modify this main route table and you can create additional route tables.
Each subnet in VPC is associated with only one route table, however, one route table can be attached to multiple subnets. You use route tables to decide what data stays inside of VPC and what data should go outside of VPC, and that is where it plays a very important part in deciding data flow for a VPC.
In the following figure, you can see four route tables for two VPCs in my AWS account. You can see rules in the route table, and you see tabs for subnet associations as well:
An internet gateway allows communication between resources such as EC2 and RDS instances in your VPC and the Internet. It is highly available, redundant, and horizontally scalable; that is, you do not need to attach more than one internet gateway to your VPC in order to support an increase in traffic.
An internet gateway serves as a target for route table in VPC for all the traffic that is supposed to go out of VPC to the internet. Along with that, it also performs network address translation for all instances with public IPv4 addresses.
An Elastic IP Address is a public IPv4, static address that can be associated with any one instance or one network interface at a time within any VPC in your AWS account. When your application is dependent on an IP address, you would use an Elastic IP address instead of a regular public IP address because public IP addresses would be lost if the underlying instance shuts down for some reason. You can simply move your Elastic IP address to another instance that is up and running from a failed instance.
You first allocate an Elastic IP address and then associate it with your instance or network interface. Once you do not need it, you should disassociate it and then release it. If an Elastic IP address is allocated but not associated with any instance, then you will be charged by AWS on an hourly basis, so if you don't have a requirement for Elastic IP addresses, it is better to release them.
A VPC endpoints is a secure way to communicate with other AWS services without using the internet, Direct Connect, VPN Connection, or a NAT device. This communication happens within the Amazon network internally so your traffic never goes out of Amazon network. At present, endpoints are supported only for Simple Storage Service (S3). These endpoints are virtual devices supporting IPv4-only traffic.
An endpoint uses the private IP address of instances in your VPC to communicate with other services. You can have more than one endpoint in your VPC. You create a route in your route table for directing traffic from instance V2 in subnet 2 through your endpoint to your target service (such as S3), as shown in the following figure:
You will often have resources in your VPC that will reside in private subnets that are not accessible from the internet. However, these resources will need to access the internet occasionally for patch update, software upgrade, and so on. A NAT device is used exactly for this purpose, allowing resources in private subnet to connect with either the internet or other AWS services securely. NAT devices support only IPv4 traffic.
AWS offers a NAT gateway, a managed device, and a NAT instance as NAT devices. Depending on your use case, you will choose either of them. AWS recommends a NAT gateway over a NAT instance as it is a managed service that requires little or no administration, is highly available, and highly scalable.
You can connect your VPC with one or more VPCs in the same region through the VPCs peering option. This connection enables you to communicate with other VPC using private IPv4 or private IPv6 addresses. Since this is a networking connection, instances in these VPCs can communicate with each other as if they are in the same network.
You can peer with VPCs in your AWS account or VPCs in other AWS accounts as well. Transitive peering is not allowed and VPCs should not have overlapping or matching IPv4 or IPv6 CIDR blocks. The following figure shows VPC peering between VPC A and VPC B. Note that the CIDR blocks differ for these two VPCs:
AWS VPC offers many features and benefits to secure your resources in your own virtual network on the cloud. You can scale your resources and select resources as per your requirement in VPC just like you do in AWS, with the same level of reliability and additional security. Let's look at these features and benefits.
Your AWS VPC can be connected to a variety of resources, such as the internet, your on-premise data center, other VPCs in your AWS account, or VPCs in other AWS accounts; once connected, you can make your resources accessible or inaccessible in your VPC from outside of your VPC based on your requirement.
You can allow your instances in your VPC to connect with the internet directly by launching them in a subnet that is publicly accessible, also known as a public subnet. This way, your instances can send and receive traffic from the internet directly.
For instances in private subnets that are not publicly accessible, you can use a NAT device placed in a public subnet to access the internet without exposing their private IP address.
You can connect your VPC to your corporate data center by creating a secure VPN tunnel using encrypted IPsec hardware VPN connection. Once connected, all traffic between instances in your VPC and your corporate data center will be secured via this industry standard hardware VPN connection.
You can connect your VPC with other VPCs privately in the same region through the VPC peering feature. This way, you can share resources in your VPC with other virtual networks across your AWS accounts or other AWS accounts.
The VPC endpoint is used to connect to AWS services such as S3 without using internet gateway or NAT. You can also configure what users or resources are allowed to connect to these AWS services.
You can mix and match the mentioned options to support your business or application requirements. For example, you can connect VPC to your corporate data center using a hardware VPN connection, and you can allow instances in your public subnet to connect directly with the internet as well. You can configure route tables in your VPC to direct all traffic to its appropriate destination.
AWS VPC has security groups that act as an instance-level firewall and network ACLS that act as a subnet-level firewall. These advanced security features allow you to configure rules for incoming and outgoing traffic for your instances and subnets in your VPC.
With help of the VPC endpoint, you can enable access control for your data in AWS S3 so that only instances in your VPC can access that data. You can also launch dedicated instances to have isolation at the instance level; these instances have dedicated hardware for a single customer.
AWS VPC can be created using AWS Management Console in a couple of ways; you can either create it through
Start VPC Wizard, or you can create it manually as well. You can also create VPC from AWS command-line interface.
VPC wizard gives you multiple options to create VPC, as shown in the following figure; you can pick one that suits your requirements and customize it later if needed. When you create a VPC using VPC wizard, all components of VPC, such as security groups, route tables, subnets and so on, are automatically created by VPC wizard:
With VPC, you can control inbound and outbound access for your resources in your own virtual private network and connect your data center with AWS cloud securely along with other VPCs in your AWS accounts and VPCs in other AWS accounts. You can also securely access data on S3 from your resources in VPC without using the internet.
All these along with many other features make VPC a preferred choice for a variety of use cases, such as hosting development and testing environments in AWS VPC. You could also use VPC for creating environments for Proof of Concept (PoC). These environments can be created on short notice and could act as an isolated network accessible only by specific teams or other resources. Since VPC is a software-defined network, it brings loads of flexibility in designing, integrating, and securing your resources in AWS cloud.
Let's look at some of the most popular use cases for VPC.
You can host a public facing website, which could be a blog, a single tier simple web application, or just a simple website using VPC. You can create a public subnet using the VPC wizard and select the
VPC with a single public subnet only option, or you can create it manually. Secure your website using instance-level firewalls, known as security groups, allowing inbound traffic, either HTTP or HTTPS, from the internet and restricting outbound traffic to the internet when required at the same time.
Hosting a multi-tier web application requires stricter access control and more restrictions for communication between your servers for layers, such as web servers, app servers, and database servers. VPC is an ideal solution for such web applications as it has all functionalities built in.
In the following figure, there is one public subnet that contains the web server and the application server. These two instances need to have inbound and outbound access for internet traffic. This public subnet also has one NAT instance that is used to route traffic for database instance in the private subnet.
The private subnet holds instances that do not need to have access to the internet. They only need to communicate with instances in the public subnet. When an instance in the private subnet needs to access the internet for downloading patches or software update, it will do that via a NAT instance placed in the public subnet:
Access control for this sort of architecture is configured using network ACLs that act as a firewall for subnets. You will also use security groups for configuring access at the instance level, allowing inbound and outbound access.
The VPC wizard gives you an option, VPC with Public and Private Subnets, to support this use case; alternatively, you can create a VPC using AWS console manually or through a command-line interface.
Quite often, there is a requirement for connecting branch offices with their own, interconnected networks. This requirement can be fulfilled by provisioning instances within a VPC with a separate subnet for different branch offices. All resources within a VPC can communicate with each other through a private IP address by default, so all offices will be connected to each other and will also have their own local network within their own subnet.
If you need to limit communication across subnets for some instances, you can use security groups to configure access for such instances. These rules and designs can be applied to applications that are used by multiple offices within an organization. These common applications can be deployed within a VPC in a public subnet and can be configured so that they are accessible only from branch offices within an organization by configuring NACLs that acts as a firewall for subnets.
The following figure shows an example of using VPC for connecting multiple branch offices with their own local networks:
Through VPC, you can also support scenarios where instances in one subnet allow inbound and outbound access to the internet and instances in other subnet can communicate exclusively with resources in your corporate data center. You will secure these communications by creating an IPsec hardware VPN connection between your VPC and your corporate network.
In this scenario, you can host your web applications in the AWS cloud in VPC and you can sync data with databases in your corporate data center through the VPN tunnel securely.
You can create a VPC for this use case using the VPC wizard and selecting VPC with Public and Private Subnets and Hardware VPN Access. You can also create a VPC manually through the AWS console or through the CLI.
This use case is specifically useful if you have a consistent requirement for provisioning additional resources, such as compute, storage, or database capacity to your existing infrastructure based on your workload.
This use case is also applicable to all those data centers that have reached their peak capacity and don't have room to extend further.
You can extend your corporate networking resources in the AWS cloud and take all benefits of cloud computing such as elasticity, pay-as-you-go model, security, high availability, minimal or no capex, and instant provisioning of resources by connecting your VPC with your corporate network.
You can host your VPC behind the firewall of your corporate network and ensure you move your resources to the cloud without impacting user experience or the performance of your applications. You can keep your corporate network as is and scale your resources up or down in the AWS cloud based on your requirements.
You can define your own IP address range while creating an AWS VPC, so extending your network into a VPC is similar to extending your existing corporate network in your physical data center.
To support this use case, you can create a VPC by opting for the VPC with a Private Subnet Only and Hardware VPN Access option in the VPC wizard or create a VPC manually. You can either connect your VPC to your data center using hardware VPN or through AWS direct connect service. The following figure shows an example of a data center extended in AWS cloud through VPC using an existing internet connection. It uses a hardware VPN connection for connecting the data center with AWS VPC.
As part of your disaster recovery (DR) and business continuity plan, you will need to continuously back up your critical data to your DR site. You can use a VPC to host EC2 instances with EBS volumes and store data in S3 buckets as well as in EBS volumes attached to EC2 instances securely, which can be configured to be accessible only from your network.
As part of your business continuity plan, you might want to run a small set of EC2 instances in your VPC, and these EC2 instances could be scaled quickly to meet the demand of a production workload in the event of a disaster. When the disaster is over, you could replicate data back to your data center and use servers in the data center to run your workload. Post that, you can terminate additionally provisioned resources, such as EC2 instances and RDS instances in AWS VPC.
You can plan your disaster recovery and business continuity with AWS VPC at a fraction of the cost of a traditional co-location site using physical data center. Moreover, you can automate your disaster recovery and business continuity plan using the AWS CloudFormation service; this automation will drastically reduce your deployment and provisioning time in AWS VPC when compared with a traditional physical data center.
AWS VPC essentially carries out the task of moving IP traffic (packets) into, out of, and across AWS regions; so, the first line of defense for a VPC is to secure what traffic can enter and leave your VPC. All resources can communicate with each other within a VPC unless explicitly configured not to do that, so this leaves us primarily with securing communication outside of your VPC with resources inside your VPC and vice versa.
AWS VPC provides multiple features for securing your VPC and securing resources inside your VPC, such as security groups, network ACL, VPC Flow Logs, and controlling access for VPC. These features act as additional layers of defense while designing your VPC architecture and are used to increase security and monitor your VPC. Apart from these features, you have a routing layer available in the form of route tables.
These features enable us to implement a layered defense for an in-depth security architecture for AWS VPC that involves all layers in a network. These security features also align security controls with the application requirement of scalability, availability, and performance.
Let's look at these security features in detail.
A security group is a virtual firewall to control ingress and egress traffic at the instance level for all instances in your VPC. Each VPC has its own default security group. When you launch an instance without assigning a security group, AWS will assign a default security group of VPC with this instance. Each instance can be assigned up to five security groups.
For a security group, in order to control ingress and egress traffic, we need to define rules for a security group. These rules need to be defined separately for controlling ingress and egress traffic. These rules are only permissive; that is, there can only be allow rules and there can't be deny rules.
When you create a new security group, by default, it does not allow any inbound traffic. You have to create a rule that allows inbound traffic. By default, a security group has a rule that allows all outbound traffic. Security groups are stateless, so if you create a rule for inbound traffic that allows traffic to flow in, this rule will allow outbound traffic as well; there is no need to create a separate rule to allow outbound traffic. These rules are editable and are applied immediately. You can add, modify, or delete a security group, and these changes are effective immediately as well. You can perform these actions from the AWS console or through the command line or an API.
An ENI can be associated with up to five security groups, while a security group can be associated with multiple instances. However, these instances cannot communicate with each other unless you configure rules in your security group to allow this. There is one exception to this behavior: the default security group already has these rules configured.
The following figure shows the security groups set up in my AWS account. This security group is created for the web server, so it has rules configured in order to allow HTTP and HTTPS traffic. It also allows SSH access on port
22 for logging into this instance:
The network access control list (NACL), as it is popularly known, is another virtual firewall provided by AWS VPC to configure inbound and outbound traffic for your subnets inside a VPC. So, all instances within this subnet are going to use the same configuration for inbound and outbound traffic. NACLs are used for creating guardrails in an organization for your network on the cloud as it does not offer granular control. Moreover, NACLs are usually configured by system administrators in an organization.
Every VPC has a default NACL that allows all inbound and outbound traffic by default. When you create a custom NACL, it denies all inbound and outbound traffic by default. Any subnet that is not explicitly associated with an NACL is associated with a default NACL and allows all traffic, so make sure all subnets in your VPCs are explicitly associated with an NACL.
NACL uses rules similar to security groups to configure inbound and outbound traffic for a subnet. Unlike security groups, NACL gives you the option to create allow and deny rules. NACL is stateless and you will need to create separate rules for inbound and outbound traffic.
Each subnet in your VPC can be attached to only one NACL. However, one NACL can be attached to more than one subnet. Rules in NACL are evaluated from the lower to the higher number, and the highest number you can have is 32776. AWS recommends that you create rules in multiples of 100, such as 100, 200, 300, and so on, so you have room to add more rules when required.
The following figure shows network ACL for a public subnet. It allows inbound and outbound HTTP and HTTPS traffic. This NACL can be used for all public subnets that will contain all instances that need to access the internet and those that are publicly accessible:
VPC facilitates the flow of inbound and outbound traffic for all resources in your VPC. It is important to monitor the flow of this IP traffic on a continuous basis in order to ensure that all traffic is going to the desired recipient and is received from expected resources. This feature is also useful for troubleshooting issues related to traffic not reaching its destination or vice versa. The VPC flow log is a very important security tool that helps monitor the security of your network in the AWS cloud.
You can create a flow log for your VPC as well as a subnet and a network interface based on your requirement. For a VPC flow log, all resources in VPC are monitored. For a subnet flow log, all resources in a subnet are monitored. This can take up to 15 minutes to collect data after you have created a flow log.
Each network interface has a unique log stream that is published to a log group in AWS CloudWatch logs. You can create multiple flow logs publishing data to one log. These logs streams consist of flow log records that are essentially log events with fields describing all the traffic for that resource. Log streams contain flow log records, which are log events consisting of fields that describe the traffic, such as the accepted traffic or rejected traffic for that network interface.
You can configure the type of traffic you want to monitor, including accepted, rejected, or all traffic for the flow log you create. You give this log a name in CloudWatch logs, where it will be published, and choose a resource you want to monitor. You will also need the Amazon Resource Name (ARN) of an IAM role that will be used to publish this flow log to CloudWatch logs group. These flow logs are not real-time log streams.
You can also create flow logs for network interfaces created by other AWS services, such as AWS RDS, AWS workspaces, and so on. However, these services cannot create flow logs; instead, you should use AWS EC2 to create flow logs, either from the AWS console or through the EC2 API. VPC flow logs are offered free of charge; you are charged only for logs. You can delete a flow log if you no longer need it. It might take several minutes before this deleted flow log stops collecting data for your network interface.
VPC flow logs have certain limitations. You cannot create VPC flow logs for peered VPCs that are not in your AWS account. VPC flow logs can't be tagged. A flow log cannot be modified after it is created; you need to delete this flow log and create another one with the required configuration. Flow logs do not capture all types of traffic, such as traffic generated by instances when they contact Amazon DNS servers, traffic to and from
169.254.169.254 for getting instance metadata, and so on.
As discussed in IAM, all AWS services require permission to access their resources. It is imperative to define access control for VPC as well. You need to grant appropriate permissions to all users, applications, and AWS services to access all VPC resources. You can define granular, resource-level permissions for VPC, which allows you to control what resources could be accessed or modified in your VPC.
You can give permissions such as managing a VPC, a read-only permission for VPC, or managing a specific resource for VPC, such as a security group or a network ACL.
Let's look at steps to create a custom VPC in an AWS account. This VPC will be created using IPv4 Classless Inter-Domain Routing (CIDR) block. It will have one public subnet and one public facing instance in this subnet. It will also have one private subnet and one instance in private subnet. For instance, for a private subnet to access the internet, we will use a NAT gateway in a public subnet. This VPC will have security groups and network ACL configured to allow egress and ingress internet traffic along with routes configured to support this scenario:
Create a VPC with a
/16IPv4 CIDR block such as
Create an internet gateway and attach it to this VPC.
Create one subnet with
/24IPv4 CIDR block, such as
10.0.0.0/24, and call it a public subnet. Note that this CIDR block is a subset of a VPC CIDR block.
Create another subnet with
/24IPv4 CIDR block, such as
10.0.1.0/24and call it a private subnet. Note that this CIDR block is a subset of a VPC CIDR block and it does not overlap the CIDR block of a public subnet.
Create a custom route table and create a route for all traffic going to the internet to go through the internet gateway. Associate this route table with the public subnet.
Create a NAT gateway and associate it with the public subnet. Allocate one Elastic IP address and associate it with the NAT gateway.
Create a custom route in the main route table for all traffic going to the internet to go through NAT gateway. Associate this route table with the private subnet. This step will facilitate the routing of all internet traffic for instances in the private subnet to go through the NAT gateway. This will ensure IP addresses for private instances are not exposed to the internet.
Create a network ACL for each of these subnets. Configure rules that will define inbound and outbound traffic access for these subnets. Associate these NACLs with their respective subnets.
Create security groups for instances to be placed in public and private subnets. Configure rules for these security groups as per the access required. Assign these security groups with instances.
Create one instance each in the public and private subnet for this VPC. Assign a security group to each of them. An instance in a public subnet should have either a public IP or an EIP address.
Verify that the public instance can access the internet and private instances can access the internet through the NAT gateway.
Once all steps are completed, our newly created custom VPC will have the following architecture. Private instances are referred to as database servers and public instances are referred to as Web servers in the diagram. Note that the NAT gateway should have the Elastic IP address to send traffic to the internet gateway as the source IP address. This VPC has both the public and private subnet in one availability zone; however, in order to have a highly available and fault-tolerant architecture, you can have a similar configuration of resources in additional availability zones:
One of the major features of AWS VPC is the connectivity options it provides for securely connecting various networks with their AWS networks. In this section, you will learn about various connectivity options for AWS VPC, such as connecting remote customer networks with VPC, connecting multiple VPCs into a shared virtual network, and so on. We will look at three connectivity options in detail:
Connecting the user network to AWS VPC
Connecting AWS VPC with another AWS VPC
Connecting the internal user with AWS VPC
You can extend and integrate your resources in your remote networks, such as compute power, security, monitoring, and so on, by leveraging your resources in AWS VPC. By doing this, your users can access all resources in AWS VPC seamlessly like any other resource in internal networks. This type of connectivity requires you to have non-overlapping IP ranges for your networks on the cloud and on-premises, so ensure that you have a unique CIDR block for your AWS VPC. AWS recommends that you use a unique, single, non-overlapping, and contiguous CIDR block for every VPC. You can connect your network with AWS VPC securely in the following ways:
HardwareVPN: You can configure AWS-compatible customer VPN gateways to access AWS VPC over an industry standard, encrypted IPSec hardware VPN connection. You are billed for each VPN connection hour, that is, for every hour your VPC connection is up and running. Along with it, you are charged for data transfer as well.
This option is easier to configure and install and uses an existing internet connection. It is also highly available as AWS provides two VPN tunnels in an active and standby mode by default. AWS provides virtual private gateway with two endpoints for automatic failover. You need to configure, customer gateway side of this VPN connection, this customer gateway could be software or hardware in your remote network.
On the flip side, hardware VPN connections have data transfer speed limitation. Since they use an internet to establish connectivity, the performance of this connection, including network latency and availability, is dependent on the internet condition.
Direct connect: You can connect your AWS VPC to your remote network using a dedicated network connection provided by AWS authorized partners over 1-gigabit or 10-gigabit Ethernet fiber-optic cable. One end of this cable is connected to your router, the other to an AWS Direct Connect router. You get improved, predictable network performance with reduced bandwidth cost. With direct connect, you can bypass the internet and connect directly to your resources in AWS, including AWS VPC.
You can pair direct connect with a hardware VPN connection for a redundant, highly available connectivity between your remote networks and AWS VPC. The following diagram shows the AWS direct connect service interfacing with your remote network:
AWS VPN CloudHub: You might have multiple remote networks that need to connect securely with AWS VPC. For such scenarios, you will create multiple VPN connections, and you will use AWS VPN CloudHub to provide secure communication between these sites. This is a hub and spoke model that can be used either for primary connectivity or as a backup option. It uses existing internet connections and VPN connections.
You create a virtual private gateway for your VPC with multiple customer gateways for your remote networks to use AWS VPN CloudHub. These remote networks should not have overlapping IP networks. The pricing model for this option is similar to that of a hardware VPN connection.
SoftwareVPN: Instead of a hardware VPN connection, you can also use an EC2 instance in your VPC with a software VPN appliance running in order to connect your remote network. AWS does not provide any software VPN appliance; however, you can use software VPN appliances through a range of products provided by AWS partners and various open source communities present on AWS marketplace. It also uses the internet for connectivity; hence, reliability, availability, and network performance are dependent on the internet speed.
This option, however, supports a wide variety of VPN vendors, products, and protocols. It is completely managed by customers. It is helpful for scenarios where you are required to manage both ends of a connection, either for compliance purposes or if you are using connectivity devices that are currently not supported by AWS.
If you have multiple VPCs in multiple regions across the globe, you may want to connect these VPCs to create a larger, secure network. This connectivity option works only if your VPCs do not have overlapping IP ranges and have a unique CIDR block. Let's look at the ways to connect AWS VPC with other AWS VPCs.
You can connect two VPCs in the same region using a VPC peering option in AWS VPC. Resources in these VPCs can communicate with each other using private IP addresses as if they are in the same network. You can have a VPC peering connection with a VPC in your AWS account and VPC in other AWS accounts as long as they are in the same region.
AWS uses its own existing infrastructure for this connection. It is not a gateway or a VPN connection that uses any physical device. It is not a single point of failure or a network performance bottleneck.
VPC peering is the most preferred method of connecting AWS VPCs. It is suited for many scenarios for large and small organizations. Let's look at some of the most common scenarios.
If you need to provide full access to resources across two or more VPCs, you can do that by peering them. For example, you have multiple branch offices in various regions across the globe and each branch office has a different VPC. Your headquarter needs to access all resources for all VPCs for all your branch offices. You can accomplish this by creating a VPC in each region and peering all other VPCs with your VPC.
You might have a centralized VPC that contains information required by other VPCs in your organization, such as policies related to human resources. This is a read-only VPC and you would not want to provide full access to resources in this VPC. You can create VPC peering connection and restrict access for this centralized VPC.
You can also have a centralized VPC that might be shared with your customers. Each customer can peer their VPC with your centralized VPC, but they cannot access resources in other customers' VPC.
Data transfer charges for a VPC peering connection are similar to charges for data transfer across availability zones. As discussed, VPC peering is limited to VPCs in the same region. A VPC peering is a one-to-one connection between two VPCs; transitive peering is not allowed for a peering connection. In the following diagram, VPC A is peered with VPC B and VPC C; however, VPC B is not peered with VPC C implicitly. It has to be peered explicitly:
Apart from VPC peering, there are other options for connecting VPCs, such as software VPN, hardware VPN, and AWS direct connect as well. All of these options have benefits and limitations similar to the one discussed in the previous section.
If you want to allow your internal users to access resources in AWS VPC, you can leverage your existing remote networks to AWS VPC connections using either hardware VPN, direct connect, or software VPN depending on your requirement. Alternatively, you can combine these connectivity options to suit your requirements, such as cost, speed, reliability, availability, and so on.
In this section, we will go through an exhaustive list of best practices to be followed for AWS VPC. Most of these are recommended by AWS as well. Implementing these best practices will ensure that your resources, including your servers, data, and applications, are integrated with other AWS services and secured in AWS VPC. Remember that VPC is not a typical data center and it should not be treated as one.
Always start by planning and designing architecture for your VPC before you create it. A bad VPC design will have serious implications on the flexibility, scalability, availability, and security of your infrastructure. So, spend a good amount of time planning out your VPC before you actually start creating it.
Start with the objective of creating a VPC: is it for one application or for a business unit? Spec out all subnets you will need and figure out your availability and fault- tolerance requirements. Find out what all connectivity options you will need for connecting all internal and external networks. You might need to plan for a number of VPCs if you need to connect with networks in more than one region.
Once you create VPC with a CIDR block, you cannot change it. You will have to create another VPC and migrate your resources to a new VPC if you want to change your CIDR block. So, take a good look at your current resources and your requirements for the next few years in order to plan and design your VPC architecture. A VPC can have a CIDR block ranging from
/28, which means you can have between 65,536 and 16 IP addresses for your VPC. AWS recommends that you choose the highest CIDR block available, so always go for
/16 CIDR block for your VPC. This way, you won't be short of IP addresses if you need to increase your instances exponentially.
All VPC connectivity options require you to have non-overlapping IP ranges. Consider future connectivity to all your internal and external networks. Make sure you take note of all available IP ranges for all your environments, including remote networks, data centers, offices, other AWS VPCs, and so on, before you assign CIDR ranges for your VPC. None of these should conflict and overlap with any network that you want to connect with.
AWS provides a default VPC in every region for your AWS account. It is best to leave this VPC alone and start with a custom VPC for your requirement. The default VPC has all components associated with it; however, the security configuration of all these components, such as subnets, security groups, and network ACLs are quite open to the world. There is no private subnet either. So, it is a good idea to create your own VPC from scratch using either a VPC wizard in the AWS console or creating it manually through the AWS console or AWS CLI. You can configure all resources as per your requirement for your custom VPC.
Moreover, by default, if a subnet is not associated with a route table or an NACL, it is associated with the main route table and default NACL. These two components don't have any restrictions on inbound and outbound traffic, and you risk exposing your resources to the entire world.
You should not modify the main route table either; doing that might give other subnets routes that they shouldn't be given. Always create a custom route table and keep the main route table as it is.
AWS keeps on expanding its regions by adding more availability zones to them. We know that one subnet cannot span more than one availability zone, and distributing our resources across availability zones makes our application highly available and fault-tolerant. It is a good idea to reserve some IP address for future expansion while creating subnets with a subset of VPC CIDR block. By default, AWS reserves five IP address in every subnet for internal usage; make a note of this while allocating IP addresses to a subnet.
Ideally, you should design your subnets according to your architecture tiers, such as the database tier, the application tier, the business tier, and so on, based on their routing needs, such as public subnets needing a route to the internet gateway, and so on. You should also create multiple subnets in as many availability zones as possible to improve your fault-tolerance. Each availability zone should have identically sized subnets, and each of these subnets should use a routing table designed for them depending on their routing need. Distribute your address space evenly across availability zones and keep the reserved space for future expansion.
For every resource you provision or configure in your VPC, follow the least privilege principle. So, if a subnet has resources that do not need to access the internet, it should be a private subnet and should have routing based on this requirement. Similarly, security groups and NACLs should have rules based on this principle. They should allow access only for traffic required. Do not add a route to the internet gateway to the main route table as it is the default route table for all subnets.
In order to keep your VPC and resources in your VPC secure, ensure that most of the resources are inside a private subnet by default. If you have instances that need to communicate with the internet, then you should add an Elastic Load Balancer (ELB) in the public subnet and add all instances behind this ELB in the private subnet.
Use NAT devices (a NAT instance or a NAT gateway) to access public networks from your private subnet. AWS recommends that you use a NAT gateway over a NAT instance as the NAT gateway is a fully managed, highly available, and redundant component.
You should ideally create one VPC each for your development, testing, and production environments. This will secure your resources from keeping them separate from each other, and it will also reduce your blast radius, that is, the impact on your environment if one of your VPCs goes down.
For most use cases such as application isolation, multi-tenant application, and business unit alignment, it is a good idea to create a separate VPC.
Security groups and NACLs are virtual firewalls available for configuring security rules for your instances and subnets respectively. While security groups are easier to configure and manage, NACLs are different. It is recommended that NACLs be used sparingly and not be changed often. NACLs should be the security policy for your organization as it does not work at a granular level. NACL rules are tied to the IP address and for a subnet, with the addition of every single rule, the complexity and management of these rules becomes exponentially difficult.
Security group rules are tied to instances and these rules span the entire VPC; they are stateful and dynamic in nature. They are easier to manage and should be kept simple. Moreover, security groups can pass other security groups as an object reference in order to allow access, so you can allow access to your database server security group only for the application server security group.
Access control for your VPC should be on top of your list while creating a VPC. You can configure IAM roles for your instances and assign them at any point. You can provide granular access for provisioning new resources inside a VPC and reduce the blast radius by restricting access to high-impact components such as various connectivity options, NACL configuration, subnet creation, and so on.
There will usually be more than one person managing all resources for your VPC; you should assign permissions to these people based on their role and by following the principle of least privileges. If someone does not need access to a resource, that access shouldn't be given in the first place.
Periodically, use the access advisor function available in IAM to find out whether all the permissions are being used as expected and take necessary actions based on your findings.
Create an IAM VPC admin group to manage your VPC and its resources.
Use VPC peering whenever possible. When you connect two VPCs using the VPC peering option, instances in these VPCs can communicate with each other using a private IP address. For a VPC peering connection, AWS uses its own network and you do not have to rely on an external network for the performance of your connection, and it is a lot more secure.
Always use Elastic IP (EIP) instead of public IP for all resources that need to connect to the internet. The EIPs are associated with an AWS account instead of an instance. They can be assigned to an instance in any state, whether the instance is running or whether it is stopped. It persists without an instance so you can have high availability for your application depending on an IP address. The EIP can be reassigned and moved to Elastic Network Interface (ENI) as well. Since these IPs don't change, they can be whitelisted by target resources.
All these advantages of EIP over a public IP make it more favorable when compared with a public IP.
Always tag your resources in a VPC. The tagging strategy should be part of your planning phase. A good practice is to tag a resource immediately after it is created. Some common tags include version, owner, team, project code, cost center, and so on. Tags are supported by AWS billing and for resource-level permissions.
Monitoring is imperative to the security of any network, such as AWS VPC. Enable AWS CloudTrail and VPC flow logs to monitor all activities and traffic movement. The AWS CloudTrail will record all activities, such as provisioning, configuring, and modifying all VPC components. The VPC flow log will record all the data flowing in and out of the VPC for all the resources in VPC. Additionally, you can set up config rules for the AWS Config service for your VPC for all resources that should not have changes in their configuration.
Connect these logs and rules with AWS CloudWatch to notify you of anything that is not expected behavior and control changes within your VPC. Identify irregularities within your network, such as resources receiving unexpected traffic in your VPC, adding instances in the VPC with configuration not approved by your organization, among others.
Similarly, if you have unused resources lying in your VPC, such as security groups, EIP, gateways, and so on, remove them by automating the monitoring of these resources.
Lastly, you can use third-party solutions available on AWS marketplace for monitoring your VPC. These solutions integrate with existing AWS monitoring solutions, such as AWS CloudWatch, AWS CloudTrail, and so on, and provide information in a user-friendly way in the form of dashboards.
The VPC is responsible for securing your network, including your infrastructure on the cloud, and that makes this AWS service extremely critical for mastering security in AWS. In this lesson, you learned the basics of VPC, including features, benefits, and most common use cases.
We went through the various components of VPC and you learned how to configure all of them to create a custom VPC. Alongside, we looked at components that make VPC secure, such as routing, security groups, and so on.
We also looked at multiple connectivity options, such as a private, shared, or dedicated connection provided by VPC. These connectivity options enable us to create a hybrid cloud environment, a large connected internal network for your organization, and many such secure, highly available environments to address many more scenarios.
Lastly, you learned about the limits of various VPC components and we looked at an exhaustive list of VPC best practices.
In the next lesson, we will look at ways to secure data in AWS: data security in AWS in a nutshell. You will learn about encrypting data in transit and at rest. We will also look at securing data using various AWS services.
Which among the following is used for separating resources, such as web servers and database servers?
Elastic Network Interfaces
State whether the following statement is True or False: By default, every VPC has a network interface attached to every instance.
One route table can be attached to multiple ______.
Elastic Network Interfaces
How to access private subnets publicly?
______ can be associated with up to five security groups.