Infrastructure Overview

Introduction

The WorkArea Hosting Platform runs on Amazon Web Services (AWS).

Each client has their own AWS account, these accounts share only a billing relationship to WebLinc through AWS' Consolidated Billing.

Each account has at least two VPC's: Staging and Production.

We'll touch more on exactly what a VPC is later on in these guides.

When infrastructure features and changes are architected, they are done so using a number of Infrastructure as Code (IaC) tools: Chef, Terraform, CloudFormation.

Using these tools to write IaC means our infrastructure is reproducable across multiple VPCs/Environments, can be stored in version control, code-reviewed, and tested programatically.

All of the major services required for the application to operate (mongodb, redis, elasticsearch) are ran in a cluster of atleast 3 nodes distributed across 3 availability zones, most commonly in Amazon's us-east-1 region.

Application, search, and log servers sit behind an Elastic Load Balancer to ensure that traffic is split evenly across nodes and availability zones.

VPCs and their components

A Virtual Private Cloud (VPC) is a software defined network that provides logical isolation and network security features for services that run inside of an AWS account.

As previously mentioned, each Workarea project typically contains two AWS VPCs.

Typically the Staging VPC will hold a Staging and QA environment. This is best thought of as a non-production sandbox, where infrastructure and application changes can be tested and battle hardened prior to reaching production.

The Production VPC typically only has one environment, which is the Production environment.

Staging and Production VPCs cannot communicate with each other.

Environments

Aside from the base resources we cover below, a VPC contains many Environments.

An Environment contains application servers and other resources which should be isolated from other Environments living inside a VPC.

Check out the App Environment Guide for more information.

Network Address Translation (NAT)

Each VPC requires a Network Address Translation (NAT) service for communicating with the internet.

Prior to reaching the NAT, most outbound traffic also passes through a Proxy server, which we'll cover in detail a bit later.

If an integration requires an IP/Firewall whitelist, the Elastic IP address attached to the NAT gateway is the IP Address that should be used.

Check out the NAT Gateway Guide for more details.

Subnets in a VPC

A VPC has many subnets, these subnets are used to separate functions, such as application servers, database servers, elasticsearch servers, etc.

For each function, there are several subnets. For example, we provision 3 subnets to host MongoDB.

Each VPC subnet exists in a single AWS availability zone. This ensures that each server exists in a different physical location, for redundancy purposes in the case of a datacenter or network outage.

There is only one set of subnets that is accessible via the Internet. We have chosen to call this group Public, which feels right. This subnet group contains the load balancers that serve the web site to the public.

Without access to the public Internet, connecting directly to the servers requires a connection to a VPN instance that lives in a Public subnet. The connection to this VPN instance can be opened using a VPN client or an SSH Bastian.

Check out the VPN Connection Guide for more details on connecting to instances in your VPC.

AWS Security groups are used to govern the traffic permitted between subnets. For example, application servers can connect to the database servers, but search servers cannot.

Base Resources in a VPC

A VPC contains the following base resources, which are shared across all environments inside a VPC:

VPC Topology

AWS Resource Map