# AWS

We use AWS for hosting our services and these are the specific AWS services we use.

# ECR

Our private repository for storing our docker images, similar like dockerhub.

# CodePipeline

We use CodePipeline to trigger builds from commits on our master and test branch.

# CodeBuild

Building our docker images happens on a build server spin up by CodeBuild. The OS on the build server is Ubuntu and we use the latest 18.x Docker version

# CodeDeploy

This AWS service takes care of our blue/green and rolling update deployments. For essential services like VaasWeb, VaasAPI, McGames and VMS our deployment strategy is blue/green deployment with at least 3 containers running in different availability zones. For less essential services like VaasEmbedApi and VaasDFP we use rolling update with two containers running in different availability zones.

# Route 53

This is where we handle our DNS/domains. We registered mychannels.cloud and currently use this to create subdomains and host based routes in our single (Application) Load Balancer. To see all our routes and services check our overview dashboard

# VPC

Currently we use a single Virtual private cloud in the eu-west-1 region

# Subnets

We use three subnets which are all active in different availability zones in the eu-west-1 region.

# Load Balancer

We use a single Application load balancer with listeners on port 80 (redirect to 443),port 443(https access to our services) and 8443 (used for blue/green deployments)

# Target Group

Target group consists of network interfaces we use to direct our traffic to and include a health check to be sure that the service is running.

# Network Interface

Network interface is needed for a service to talk to private/public services

# Elastic IP

IP address provided by AWS, we can easily ask for a new IP address when a service experiences a denial of service attack.

# Security Group

Rules for inbound and outbound traffic. We try to restrict as much as possible for the inbound traffic

# ECS

We use the Fargate option to spin up our containers, which basically means AWS is managing our container servers (so no need to patch them). At the moment we have two clusters (production and test) where our production and test services run.

# Parameter Store

We use the parameter Store to store environment variables which we use in our containers. From normal string to encrypted strings.

# Secret Store

We use secrets for our database credentials instead of parameter store.