Architecture > API Architecture
Custom VPC
Learn how the necessary cloud infrastructure resources are deployed within the custom VPC.
- how the necessary cloud infrastructure resources are deployed within a custom VPC
Diagram
Description
As mentioned in the introduction section, the API project application’s cloud infrastructure comes with two setups - development and production. The difference between the two is a bit different setup when it comes to networking and Amazon ElasticSearch Service. In the production setup, these are configured a bit differently, mainly for improving your project’s security posture and availability.
Unlike in the development setup, where your project is deployed into the default VPC, in the production setup, your project is deployed into a custom Virtual Private Cloud (VPC), which we cover in this section.
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 organization’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.
Key Differences
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 publicMultiple 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.
External Internet-Facing Cloud Infrastructure Resources
The only way resources located in the private subnetsIf 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.
FAQ
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 Amazon ElasticSearch Service<diagram-letter>H</diagram-letter>Deployed Into Multiple AZs?
For the production setup, that is true. For development setup, it is deployed into a single AZ, just for cost reasons.
Check out the Amazon ElasticSearch Service’s FAQ page for more information.