​
Introduction

Networks house your databases, caches, jumpboxes, and occasionally applications within AWS. In general, although they are displayed in the Vapor UI for you to review, you are not required to interact with networks directly when using Vapor. When you create a project in a region that does not contain any previous Vapor projects, Vapor automatically begins provisioning a network for you.

​
Attaching A Network To An Environment

Typically, you do not need to manually add a network directive to your vapor.yml file; however, sometimes you may want to manually specify that a Vapor environment should be placed within a given network. This may be the case when you are accessing private AWS resources, such as ElasticSearch, that are not created through Vapor. To place an environment within a network, add the network directive to your vapor.yml configuration file:
vapor.yml
id: 3
name: vapor-app
environments:
    production:
        network: my-network
        build:
            - 'composer install --no-dev'

​
Custom IP Range

By default, Vapor provisions new networks with an IP address range which is more than sufficient for most projects. However, if you need more control over how your network is configured - such as when you plan to configure your Vapor environment to communicate with pre-existing resources on AWS - you may set your own custom IP range. When creating the network within the Vapor UI, select “Configure Custom IP Range” to show the Custom IP Range interface. You must enter an IP range in valid CIDR notation for the overall VPC, along with the public and private subnets. The total number of ranges required for private subnets varies between two and four depending on the number of availability zones for the selected region. IP ranges provided for public and private subnets must fall in the range provided for the overall VPC without overlapping each other.

​
Jumpboxes

Some Vapor resources, such as private databases or cache clusters, may not be accessed from the public Internet. Instead, they can only be accessed by a machine within their network. This can make it cumbersome to inspect and manipulate these resources during development. To mitigate this inconvenience, Vapor allows you to create jumpboxes. Jumpboxes are very small, SSH accessible servers that are placed within your private network. You may create a jumpbox via the Vapor UI’s network detail screen or using the jump CLI command: 
vapor jump my-jumpbox
Once the jumpbox has been created, Vapor will provide you with the private SSH key needed to access the jumpbox. You should connect to the jumpbox via SSH as the ec2-user user and the private SSH key.
For practical examples of using jumpboxes to make your serverless life easier, check out the database and cache documentation.

​
NAT Gateways

​
What Are They?

If your application interacts with a private database or a cache cluster, your network will require a NAT Gateway. It sounds complicated, but don’t worry, Vapor takes care of the heavy lifting. In summary, when a serverless application needs to interact with one of these resources, AWS requires us to place that application within that region’s network. By default, this network has no access to the outside Internet, meaning any outgoing API calls from your application will fail. Not good.

​
Managing NAT Gateways

Anytime you deploy an application that lists a private database or cache cluster as an attached resource within its vapor.yml file, Vapor will automatically ensure that the network associated with that database / cache contains a NAT Gateway. If it doesn’t, Vapor will automatically begin provisioning one. Unfortunately, AWS bills for NAT Gateways by the hour, resulting in a monthly fee of about $32 / month. To totally avoid using NAT Gateways, you can use publicly accessible RDS databases (Vapor automatically assigns a long, random password) and a DynamoDB cache table, which Vapor automatically creates for each of your projects. You may also manually add or remove NAT Gateways from your networks using the Vapor UI or using the network:nat and network:delete-nat CLI commands.

​
Load Balancers

By default, Vapor routes HTTP traffic to your serverless applications using AWS API Gateway. When using this service, AWS only bills you based on the amount of requests your application receives. However, at very high scale, API Gateway can become more expensive than your Lambda functions themselves. As an alternative to API Gateway, you may route traffic to your application using an Application Load Balancer, which provides large cost savings at scale. For example, if an application receives about 1 billion requests per month, using an Application Load Balancer will save about $3,000 on the application’s monthly Amazon bill when compared to an API Gateway REST API and about $1,000 when compared to an API Gateway HTTP API.

​
Creating Load Balancers

You may create load balancers using the Vapor UI or using the balancer CLI command. When using the CLI command: 
vapor balancer my-balancer

​
Using Load Balancers

To attach a load balancer to an environment, add a balancer key to the environment’s configuration in your vapor.yml file and deploy your application. The value of this key should be the name of the load balancer.
vapor.yml
id: 3
name: vapor-app
environments:
    production:
        balancer: my-balancer
        build:
            - 'composer install --no-dev'
By default, Vapor creates all SSL certificates in the us-east-1 region, regardless of the region of your project. When your application is using API Gateway, AWS will automatically replicate your certificate to all regions behind the scenes.However, when using an Application Load Balancer to route traffic to your application, you will need to create a certificate in the region that the project is actually deployed to.

​
Deleting Load Balancers

Load balancers may be deleted via the Vapor UI or using the balancer:delete CLI command: 
vapor balancer:delete my-balancer