VPC Use Cases
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.
Hosting a Public Facing Website
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 Multi-Tier Web Application
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.
Creating Branch Office and Business Unit Networks
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:
Hosting Web Applications in the AWS Cloud That Are Connected with Your Data Center
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.
Extending Corporate Network in AWS Cloud
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.
Disaster Recovery
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.