Overview

The StartupKit-templates 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 (jump)
• A bastion host to securely access instances inside the VPC (jump)
• A deployment environment using AWS Elastic Beanstalk (jump)
• A container-based environment using AWS Fargate (jump)
• A relational database using Amazon RDS (jump)
• An Amazon Aurora DB cluster (jump)
• An ElastiCache Cluster (jump)
• Billing alerts for your account (jump)

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.

StartupKit is designed to be modular. Some stacks depend on others, some can be deployed individually or in combination with others. You can use the stacks for each module individually and combine them on your own, or use wrapper stacks we have created from the tables below that provide one-click launch for common combinations. The wrapper stacks in the one-click launch table are broken down by regions in order to simplify deployments. See the Region Table for more information on availability of services by region.

Prerequisites

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.

Creating stacks

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.

The templates

Each section contains details about template parameters and the resources created by the stack.

• vpc.cfn.yml
• bastion.cfn.yml
• elastic-beanstalk.cfn.yml
• fargate.cfn.yml
• db.cfn.yml
• aurora.cfn.yml
• elasticache.cfn.yml
• billing.cfn.yml

VPC

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.

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.

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.

Diagram

Bastion Host

It is preferable not to ssh into EC2 instances at all, instead monitoring 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 instances, it's best (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 to private resources, allowing it to function as a secure go-between. You configure your EC2 instances to only accept ssh traffic from the bastion host, then you can ssh into the bastion host, and from there connect to your private resources.

EC2 key pairs are required to ssh into any EC2 instance, including bastion hosts. If an attacker gains access to your key pair, they can use it to get into your bastion host, and thus your other resources. In order to prevent this kind of breach the bastion host template supports enabling Multi-Factor Authentication (MFA), which is highly recommended

With MFA enabled you use an app like Google Authenticator or Authy to obtain a one-time password, and use this when logging in, in addition to your username and key pair.

You can also set how long CloudWatch logs are retained, and optionally enable Multi-Factor Authentication, among other options.

Creating a Bastion Host stack requires you to have first created a VPC stack, and to enter the name of the VPC stack as the NetworkStackName parameter.

After 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. Once on the bastion host you should be able to reach all AWS resources running in the same VPC.

For security and cost optimization it is a best practice to stop (not terminate!) the bastion host when not in use.

See Enabling Multi-factor authentication on the Bastion Host for additional MFA information.

Resources Created

• A t2.micro EC2 instance
• An Elastic IP Address
• An Elastic Network Interface
• 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
• Five login attempts with either an invalid key or invalid username occur within five minutes

Diagram

AWS Elastic Beanstalk

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.

Creating a AWS Elastic Beanstalk stack requires you to have first created a VPC stack, and to enter the name of the VPC stack as the NetworkStackName parameter.

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.
• The name of the stack you previously created to define your VPC, as the NetworkStackName parameter.

Resources Created

• A service role
• An Elastic Beanstalk application
• An Elastic Beanstalk environment
• An Auto Scaling Group
• A Load Balancer
• Related IAM Roles and Policies.

Diagram

AWS Fargate

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.

Creating a Fargate stack requires you to have first created a VPC stack, and to enter the name of the VPC stack as the NetworkStackName parameter.

Resources Created

• An S3 bucket providing an example of how IAM roles work with containers
• 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

Diagrams

With RDS/Aurora:

Without RDS/Aurora:

Amazon RDS

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.

Creating an RDS stack requires you to have first created a VPC stack, and to enter the name of the VPC stack as the NetworkStackName parameter.

Resources Created

• A DB instance
• A DB subnet group

Amazon Aurora

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.

Creating an Aurora stack requires you to have first created a VPC stack, and to enter the name of the VPC stack as the NetworkStackName parameter.

Resources Created

• An Aurora DB Cluster
• An Aurora DB instance
• A DB subnet group

Amazon ElastiCache Cluster

Amazon ElastiCache is a managed high-performance in-memory data store, backed with either the Redis or Memcached engines. Running this template lets you select the engine type, number of nodes in the cluser, and the instance type of the nodes.

Creating an ElastiCache stack requires you to have first created a VPC stack, and to enter the name of the VPC stack as the NetworkStackName parameter.

Resources Created

• An ElastiCache Cluster
• An ElastiCache subnet group
• An ElastiCache security group

Billing Alerts

If you leave AWS resources running longer than intended, have unexpected traffic levels, or misconfigure or over provision resources, your bill can climb higher or faster than expected. To avoid surprises we recommend turning on billing alerts, so that you're notified when charges go above preconfigured thresholds. The billing alert template makes this easier.

Before running you need to use the AWS console to enable billing alerts:

• Log into the billing section of the console. Click your username on the top right and select 'My Billing Dashboard.'
• Select 'Preferences' from the list of options on the left.
• Check 'Receive Billing Alerts.' Once saved this cannot be disabled.

Now you can run the billing_alert.cfn.yml template, which will create a CloudWatch alarm and an SNS topic. You'll be asked for the threshold (in US dollars) for receiving an alert and the email address the alert should be sent to. If you want to get alerts at more than one threshold, you can run the template multiple times.

You can read about more ways to avoid unexpected charges.

Launching Modular Stacks

Select the Category of stack you want to launch below. Then find the row with the combination of modules you are looking for from the checkbox columns (i.e. vpc+bastion host) and select the region you want to launch the stack in. Click 'Launch Stack' button and the CloudFormation console will open automatically with the stack's details.

New services are not immediately available in all AWS Regions, please consult the Region Table for more information.

Basic Infrastructure Templates (VPC etc)

CloudFormation	Region Name	Region	VPC	Bastion
	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 West (N. California)	us-west-1	✅
	US West (N. California)	us-west-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	✅	✅
	EU (Ireland)	eu-west-1	✅
	EU (Ireland)	eu-west-1	✅	✅
	EU (London)	eu-west-2	✅
	EU (London)	eu-west-2	✅	✅
	EU (Paris)	eu-west-3	✅
	EU (Paris)	eu-west-3	✅	✅
	EU (Frankfurt)	eu-central-1	✅
	EU (Frankfurt)	eu-central-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 (Mumbai)	ap-south-1	✅
	Asia Pacific (Mumbai)	ap-south-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	✅	✅

AWS Elastic Beanstalk

CloudFormation	Region Name	Region	VPC	Bastion	DB	Elastic Beanstalk
	US East (N. Virginia)	us-east-1	✅	✅	✅	✅
	US East (Ohio)	us-east-2	✅	✅	✅	✅
	US West (N. California)	us-west-1	✅	✅	✅	✅
	US West (Oregon)	us-west-2	✅	✅	✅	✅
	Canada (Central)	ca-central-1	✅	✅	✅	✅
	S. America (São Paulo)	sa-east-1	✅	✅	✅	✅
	EU (Ireland)	eu-west-1	✅	✅	✅	✅
	EU (London)	eu-west-2	✅	✅	✅	✅
	EU (Paris)	eu-west-3	✅	✅	✅	✅
	EU (Frankfurt)	eu-central-1	✅	✅	✅	✅
	Asia Pacific (Tokyo)	ap-northeast-1	✅	✅	✅	✅
	Asia Pacific (Seoul)	ap-northeast-2	✅	✅	✅	✅
	Asia Pacific (Mumbai)	ap-south-1	✅	✅	✅	✅
	Asia Pacific (Singapore)	ap-southeast-1	✅	✅	✅	✅
	Asia Pacific (Sydney)	ap-southeast-2	✅	✅	✅	✅

AWS Fargate

CloudFormation	Region Name	Region	VPC	Bastion	DB	Fargate
	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 West (Oregon)	us-west-2	✅	✅		✅
	US West (Oregon)	us-west-2	✅	✅	✅	✅
	EU (Ireland)	eu-west-1	✅	✅		✅
	EU (Ireland)	eu-west-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 (Singapore)	ap-southeast-1	✅	✅		✅
	Asia Pacific (Singapore)	ap-southeast-1	✅	✅	✅	✅
	Asia Pacific (Sydney)	ap-southeast-2	✅	✅		✅
	Asia Pacific (Sydney)	ap-southeast-2	✅	✅	✅	✅