This repo contains a collection of AWS CloudFormation templates intended to help you set up common pieces of AWS infrastructure. Each template defines a stack, which is a collection of related resources that can be created, updated, or deleted as a single unit. Templates are available for creating:
- A secure network inside a VPC
- A bastion host to securely access instances inside the VPC
- A deployment environment using AWS Elastic Beanstalk
- A container-based environment using Amazon Fargate
- A relational database using Amazon RDS
- An Amazon Aurora DB cluster
The VPC template is a requirement for the others. You can either run the templates/vpc.cfn.yml template by itself prior to using the others, or run any one of the vpc-*.cfn.yml wrapper templates at the top level of this repo to create sets of resources. For example, vpc-bastion-fargate-rds.cfn.yml will create a single stack containing a vpc, bastion host, fargate cluster, and database.
If you haven't already done so you first need to:
- Create an AWS account.
- Make sure you're signed into AWS as an IAM user with admin access. Don't use the root account!
- Create an EC2 key pair. This is necessary to use the bastion host.
- Clone this repo so that you have a local copy of the templates.
Use the AWS CloudFormation Console to run the templates. Click the "Create Stack" button in the upper left corner of the console, then under "Choose a template", select "Upload a template to Amazon S3" and click "Browse" to find your local fork of this repository and choose the template you want to run.
To launch stacks directly directly from this README see the table below.
Each section contains details about template parameters and the resources created by the stack.
The vpc.cfn.yml template is a prerequisite for most of the others--you need to either run it first, or run one of the wrapper templates at the top level of the repo, which include it. It creates a private networking environment in which you can securely run AWS resources, along with related networking resources.
Resources created:
- 1 Amazon Virtual Private Cloud
- 2 Public subnets
- 2 Private subnets
- 1 Internet gateway
- 1 NAT gateway
- 3 route tables
- A bunch of security groups.
Subnets are isolated network areas--resources in public subnets are visible to the Internet, resources in private subnets can only be reached from inside the VPC. If a resource in a private subnet needs to communicate externally it has to do so via a NAT Gateway, which acts as a proxy.
The VPC template creates two public and two private subnets, in different Availability Zones (AZ) for redundancy. A subnet is public if it’s associated with an Internet gateway, which allow it to communicate with the Internet
Each subnet has to be associated with a route table, or set of network rules, that define allowed traffic. Route tables operate at the subnet level. The VPC template creates two of them: one for the public subnets, and one for the private.
Security groups act as firewalls at the instance level, to control inbound and outbound traffic. The template creates security groups for an application, load balancer, database, and bastion host. Depending on what other templates you run, not all of them may be used.
It's preferable not to ssh into instances at all, instead monintoring instances by configuring them to send logs to CloudWatch or other services, and managing instantiation, configuration, and termination of instances using devops tools.
If you do need to connect directly to EC2 instances, it's best practice (and for instances in a private subnets, a requirement) to use a bastion host, otherwise known as a jump box. A bastion host is an EC2 instance that is publicly accessible, and also has access resources in private subnets, allowing it to function as a secure go-between. You can ssh into the bastion host, and from there connect to your private resources.
The bastion.cfn.yml template creates:
- A t2.micro EC2 instance
- An Elastic IP Address (EIP)
- An Elastic Network Interface (ENI)
- A log stream , and an IAM profile, role, and group for use in logging
- Cloudwatch alarms for:
- Three login attempts with invalid username occur within one minute
- Fifteen login attempts with either an invalid key or invalid username occur within five minutes
You can also set how long CloudWatch logs are retained, and optionally enable Multi-Factor Authentication (MFA), among other options.
The bastion template is dependent on having previously run the VPC template--when you run the bastion template you're required to enter the name of the VPC created by the VPC template. Once the bastion stack has been created, you can log into the EC2 section of the console, find the EC2 instance containing the stack name, copy its public DNS address, and ssh into it. One on the bastion host you should be able to reach all AWS resources running in the same VPC.
For security and cost optimization it's best practice to stop (not terminate!) the bastion host when not in use.
AWS Elastic Beanstalk is a service that lets you define an environment for common application types, and deploy code into it. The Beanstalk template is dependent on the VPC, and optionally can be used with the bastion, RDS, or Aurora templates.
The elastic-beanstalk.cfn.yml template asks for a series of inputs defining your environment. Those with constrained values are:
- A stack type, with allowed values of node, rails, python, python3 or spring.
- An environment name with allowed values of dev or prod.
It creates:
- A service role
- An Elastic Beanstalk application
- An Elastic Beanstalk environment
- An Auto Scaling Group
- A Load Balancer
- Related IAM Roles and Policies.
AWS Fargate is part of Amazon Elastic Container Service (ECS). It's a managed service for running container-based applications, without having to worry about the underlying servers--sort of like Lambda for containers.
The fargate.cfn.yml template creates:
- An S3 bucket for the container
- An S3 bucket for CodePipeline artifacts
- A CodeBuild project
- A CodeBuild service role
- An Elastic Container Registry (ECR) repository
- An Application Load Balancer (ALB)
- An ALB Route 53 record
- ELB target groups stuff
- A Fargate task definition
- A Fargate service with associated scaling resources
Amazon Relational Database Service (RDS) is a service for running relational databases without having to manage the server software, backups, or other maintenance tasks. The RDS service as a whole supports Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server; this template currently works with PostgreSQL, MySQL, and MariaDB, and supports t2, m4, and r4 instance types.
The db.cfn.yml template creates:
- A DB instance
- A DB subnet group
Amazon Aurora is a high-performance cloud-optimized relational database, which is compatible with MySQL and PostgreSQL. It’s treated separately than RDS because Aurora has a few unique characteristics.
The aurora.cfn.yml template creates:
- An Aurora DB Cluster
- An Aurora DB instance
- A DB subnet group
Click a row's "Launch stack" button to launch a single stack in the specified region containing all the resources in the checked templates.
New services are not immediately available in all AWS Regions, please consult the Region Table for more information.
| CloudFormation | Region Name | Region | VPC | Bastion | DB | Fargate | Elastic Beanstalk |
|---|---|---|---|---|---|---|---|
 |
US East (N. Virginia) | us-east-1 | ✅ | ||||
| |
US East (N. Virginia) | us-east-1 | ✅ | ✅ | |||
| |
US East (N. Virginia) | us-east-1 | ✅ | ✅ | ✅ | ||
| |
US East (N. Virginia) | us-east-1 | ✅ | ✅ | ✅ | ✅ | |
| |
US East (N. Virginia) | us-east-1 | ✅ | ✅ | ✅ | ✅ | |
| |
US East (Ohio) | us-east-2 | ✅ | ||||
| |
US East (Ohio) | us-east-2 | ✅ | ✅ | |||
| |
US East (Ohio) | us-east-2 | ✅ | ✅ | ✅ | ✅ | |
| |
US West (N. California) | us-west-1 | ✅ | ||||
| |
US West (N. California) | us-west-1 | ✅ | ✅ | |||
| |
US West (N. California) | us-west-1 | ✅ | ✅ | ✅ | ✅ | |
| |
US West (Oregon) | us-west-2 | ✅ | ||||
| |
US West (Oregon) | us-west-2 | ✅ | ✅ | |||
| |
US West (Oregon) | us-west-2 | ✅ | ✅ | ✅ | ✅ | |
| |
Canada (Central) | ca-central-1 | ✅ | ||||
| |
Canada (Central) | ca-central-1 | ✅ | ✅ | |||
| |
Canada (Central) | ca-central-1 | ✅ | ✅ | ✅ | ✅ | |
| |
S. America (São Paulo) | sa-east-1 | ✅ | ||||
| |
S. America (São Paulo) | sa-east-1 | ✅ | ✅ | |||
| |
S. America (São Paulo) | sa-east-1 | ✅ | ✅ | ✅ | ✅ | |
| |
EU (Ireland) | eu-west-1 | ✅ | ||||
| |
EU (Ireland) | eu-west-1 | ✅ | ✅ | |||
| |
EU (Ireland) | eu-west-1 | ✅ | ✅ | ✅ | ✅ | |
| |
EU (London) | eu-west-2 | ✅ | ||||
| |
EU (London) | eu-west-2 | ✅ | ✅ | |||
| |
EU (London) | eu-west-2 | ✅ | ✅ | ✅ | ✅ | |
| |
EU (Paris) | eu-west-3 | ✅ | ||||
| |
EU (Paris) | eu-west-3 | ✅ | ✅ | |||
| |
EU (Paris) | eu-west-3 | ✅ | ✅ | ✅ | ✅ | |
| |
EU (Frankfurt) | eu-central-1 | ✅ | ||||
| |
EU (Frankfurt) | eu-central-1 | ✅ | ✅ | |||
| |
EU (Frankfurt) | eu-central-1 | ✅ | ✅ | ✅ | ✅ | |
| |
Asia Pacific (Tokyo) | ap-northeast-1 | ✅ | ||||
| |
Asia Pacific (Tokyo) | ap-northeast-1 | ✅ | ✅ | |||
| |
Asia Pacific (Tokyo) | ap-northeast-1 | ✅ | ✅ | ✅ | ✅ | |
| |
Asia Pacific (Seoul) | ap-northeast-2 | ✅ | ||||
| |
Asia Pacific (Seoul) | ap-northeast-2 | ✅ | ✅ | |||
| |
Asia Pacific (Seoul) | ap-northeast-2 | ✅ | ✅ | ✅ | ✅ | |
| |
Asia Pacific (Mumbai) | ap-south-1 | ✅ | ||||
| |
Asia Pacific (Mumbai) | ap-south-1 | ✅ | ✅ | |||
| |
Asia Pacific (Mumbai) | ap-south-1 | ✅ | ✅ | ✅ | ✅ | |
| |
Asia Pacific (Singapore) | ap-southeast-1 | ✅ | ||||
| |
Asia Pacific (Singapore) | ap-southeast-1 | ✅ | ✅ | |||
| |
Asia Pacific (Singapore) | ap-southeast-1 | ✅ | ✅ | ✅ | ✅ | |
| |
Asia Pacific (Sydney) | ap-southeast-2 | ✅ | ||||
| |
Asia Pacific (Sydney) | ap-southeast-2 | ✅ | ✅ | |||
| |
Asia Pacific (Sydney) | ap-southeast-2 | ✅ | ✅ | ✅ | ✅ |