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:

Figure 6: AWS VPC for a multi-tier web application

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:

Figure 7: AWS VPC for connecting branch offices

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.

Figure 8: AWS VPC extend corporate data center

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.

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:

Figure 9: AWS VPC security groups

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:

Figure 10: AWS VPC NACL

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.

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 AWS VPC with Other AWS VPC

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:

Figure 13: AWS VPC Transitive Peering

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.

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 /16 to /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.