What you’ll learn
- how the necessary cloud infrastructure resources are deployed within a custom VPC
During the creation of a new Webiny project, one of the questions that shows up is should your new project be deployed in a Virtual Private Cloud (VPC) or not. The answer to that question depends on your needs, but usually for production environments, having resources deployed in a custom VPC is a reasonable choice.
Note that the VPC setup presented here is a good foundation, but is not an ultimate solution. There is a chance that the setup might need additional cloud infrastructure resources or different configurations on your or your organisation's behalf.
Virtual Private Clouds (VPCs) is a topic that requires some general networking knowledge and knowledge on AWS-specific concepts like regions, availability zones, different network gateways, and so on. Be sure to read about it before going through this section.
The shown diagram gives an overview of which cloud infrastructure resources are deployed when the Custom VPC option was chosen during the creation of a new Webiny project. When compared to the Default VPC option, essentially, resources still work and communicate with each other in the same way, except this time, there are a couple of additional network-level resources, and rules in place. This helps in improving your project's overall security posture.
Public and private subnets
The most prominent change, when compared to the default-VPC option, is the inclusion of a VPC that consists of three subnets - one public
With this network structure, you are given the opportunity to place mission-critical cloud infrastructure resources into the private subnets
With the Amazon ElasticSearch Service
Multiple Availability Zones
As mentioned, the public and private subnets are deployed across multiple availability zones (AZs). This helps in making your application more highly available, fault tolerant and scalable. For example, if in a single region, one of the AZs goes offline, all of the network traffic is essentially routed to other AZs that are online. This means your application still works.
Note that the number of distinct AZs depends on the region you're deploying to as some only have 2 AZs.
Have in mind that hosting your application in multiple availability zones may incur additional cost, since some of the cloud infrastructure resources need to be deployed multiple times. For example, this is true for Amazon ElasticSearch Service
External internet-facing cloud infrastructure resources
The only way resources located in the private subnets
This makes it possible for Lambda functions that are located in private subnets
Note that when private subnet resources are communicating with the ones operating in an internet facing environment
If this presents a problem, you may want to integrate a different solution, like for example VPC endpoints for DynamoDB. Check out the Using Amazon VPC Endpoints to Access DynamoDB article to learn more.
Is it allowed to make changes to the custom-VPC cloud infrastructure code?
Yes. The provided cloud infrastructure code does provide a good foundation, but there might be cases where you'd want to make further adjustments.
Is it possible to switch from the default-VPC to the custom-VPC setup?
Yes, you'd just need to alter the cloud infrastructure code accordingly, and redeploy. This can probably be considered as a bigger change to your cloud infrastructure, so make sure to test the deployment before applying changes in your production environment. The
--preview flag can also come in handy when doing this.
Is it possible to deploy the custom-VPC setup into the production environment only?
This can be done. Since the cloud infrastructure is defined using code, nothing prevents you from using a couple of
if statements to determine which resources need to be deployed.
Is Amazon ElasticSearch Service
Currently it is deployed into a single AZ, just for cost reasons. But yes, production workloads should use two or three AZs. Check out the Amazon ElasticSearch Service's FAQ page for more information.
How is API Gateway
To our knowledge, there is no official evidence on how this actually works. But, since no additional configuration was needed in order to establish the API Gateway