AWS CloudFormation basics – part1

Collection of notes, templates and tips for building AWS CloudFormation templates.

The basic structure of CloudFormation files (in JSON):

{
  "Resources" : {
    "ExampleResourceName" : {
      "Type" : "AWS::?::?",
      "Properties" : {
        "Example" : "propertyvalue"
      }
    }
  }
}
  • Resources: the AWS services to be provisioned. There can be multiple repeating Resource elements in this section, to provision/configure multiple services in a stack
  • ExampleResourceName: a name for each resource being provisioned
  • Type: the AWS type for the resource, e.g. AWS::S3::Bucket
  • Properties: properties for the service being provisioned/configured

AWS CLI commands:

aws cloudformation create-stack --stack-name STACK-NAME
  --template-body file://template-file.json
  --parameters ParameterKey=example1,ParameterValue=value1    
    ParameterKey=example2,ParameterValue=value2
aws cloudformation list-stacks
aws cloudformation delete-stack --stack-name STACK-NAME

If your stack creates IAM resources, you’ll also need to pass:

--capabilities CAPABILITY_NAMED_IAM

Otherwise you’ll see this error:

An error occurred (InsufficientCapabilitiesException) when calling the CreateStack operation: Requires capabilities : [CAPABILITY_NAMED_IAM]

Summary: What you need to deploy a Docker container to AWS ECS Fargate

In my previous post I walked through a couple of tutorials to deploy a test Docker container to AWS ECS Fargate. As a summary, here’s the various parts that you need to have in place to deploy a Docker container using Fargate:

  • A Docker image, deployed to a Docker repository, e.g. either Docker Hub, or AWS ECR
  • A VPC with either a public or private subnet (or both)
  • A Security Group to define what traffic is allowed in and out to your running Container
  • A ELB Load Balancer, assuming you’re running more than 1 instance of a container and are not accessing a single instance directly with a public IP
  • An ECS Cluster
  • An ECS Task Definition
  • An ECS Fargate Service Definition to create the running instance of your task

Using Route 53 to create subdomain names for your projects

If you create and deploy your own software projects to the cloud, at some point you probably end up with a number of things deployed to various places and unless you spend time maintaining your bookmarks to all these projects, it becomes hard to keep track after a while.

One of the interesting things about Route 53 is that you can create A records that resolve to IP addresses either within AWS or hosted elsewhere. If you have you own domain setup in Route 53, you can easily create subdomains with A records pointing to where ever these projects are hosted. e.g.

example1.youdomain.com -> x.x.x.x

example2.yourdomain.com -> y.y.y.y

A while back I deployed my Sudoku Solver React app to an S3 bucket hosting the website, and I can never remember the S3 endpoint name. But using a Route 53 Alias to the S3 endpoint, you can create whatever subdomain you need to point to the target resource. Here’s what it looks like setting up an alias:

Notes:

  • when you click in the Alias Target box you should see your S3 bucket already listed (if not, check you’ve enabled Static Website Hosting)
  • the recordset name must be identical to the first part of your bucket name (e.g. ‘example’)
  • the S3 bucket name must be the subdomain name plus full domain, e.g. example.yourdomain.com

AWS Lambda access to AWS RDS databases

For a Lambda to access an AWS RDS database instance, it needs to be in the same VPC as the RDS instance. However, if you haven’t created and assigned a role with persmissions for the Lambda to access the VPC, you’ll see this error when creating your Lambda:

To fix this per steps in the tutorial here, create a role with permission ‘AWSLambdaVPCAccessExecutionRole’.