Default VPC
What you’ll learn
- how the necessary cloud infrastructure resources are deployed within the default VPC
Diagram

Description
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 development environments, having resources deployed in the default VPC is a reasonable choice.
info
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.
You can also check this Understanding the Default Virtual Private Cloud article. It clearly lays out a lot of useful information about AWS's default VPC setup.
In the diagram above, we can see that the default VPC setup (a setup controlled by AWS) consists of three subnets
We can also see that Lambda functions are located in all three subnets. This is because, by default, AWS runs Lambda functions in multiple AZs to ensure it is highly available in case of an AZ failure. The same cannot be said for the Amazon ElasticSearch Service
As mentioned, the default VPC setup can be a reasonable choice when it comes to development environments. But for production, since some of the cloud infrastructure resources may require that they are not exposed to the public internet, the Custom VPC may be a better solution.
FAQ
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.
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.