Warning

You're browsing the documentation for an old version of Webiny. Consider upgrading your project to Webiny 5.35.x.

Production

Learn how the necessary cloud infrastructure resources are deployed within the custom VPC.

What you’ll learn

how the necessary cloud infrastructure resources are deployed within a custom VPC

Diagram

Webiny Cloud Infrastructure - Modes - Production Mode

(click to enlarge)

Description

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 external link before going through this section.

Key Differences

When compared to the development mode, 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 availability and overall security posture.

Public and Private Subnets

The most prominent change, when compared to the development mode, is the inclusion of a VPC that consists of three subnets - one public C and two private D e, deployed across multiple availability zones (AZs).

With this network structure, you are given the opportunity to place mission-critical cloud infrastructure resources into the private subnets D E, which makes these resources more secure, because they are not directly exposed to the public internet. This is especially important when talking about hosting databases, for example the Amazon ElasticSearch Service H.

With the Amazon ElasticSearch Service H placed inside of a private subnet, note that you can’t connect to it directly from your machine. Deploying a jump-box (bastion host) external link

in a public subnet can resolve this problem.

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 h.

External Internet-Facing Cloud Infrastructure Resources

The only way resources located in the private subnets D e can talk to the public internet is via the public subnet C, which includes a NAT gateway F. The NAT (network address translation) gateway is the middleman that forwards all internet-routable network traffic, received from private subnets, to the Internet Gateway g.This makes it possible for AWS Lambda functions that are located in private subnets D E to talk to AWS resources that operate in an internet facing environment, like Amazon DynamoDB i, Amazon S3 j, and Amazon Cognito k.

Note that when private subnet resources are communicating with the ones operating in an internet facing environment i

k, sending and receiving data is still performed across the public internet l.

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 external link article to learn more.

FAQ

Is Amazon ElasticSearch Service H 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 external link for more information.

How Is API Gateway Communicating With AWS Lambda Functions if It's Outside of the VPC?

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 B - Lambda Functions connection, it means that this is automatically handled for you by AWS’s internal structure and mechanisms. This Stack Overflow external link

question briefly discusses this, but again, no concrete evidence and answers are provided.