Fargate Web Demo Using CDK

Mark Ilott
4 min readJun 20, 2021

Create a public web server behind an ALB using CDK

Fargate Web App

This is a short article to explain a demo you can download the Javascript code on GitHub here.

The demo creates Fargate services with a Docker containers for a web apps. The containers can be created from a local definition or an image on Docker Hub or ECR.

As a bonus there is a basic scheduler included using EventBridge.

I use this pattern a to test web apps created by other teams (front-end applications are definitely not my thing).

In this case the ALB is created publicly because it’s simpler that way, but it can be created internally with some minor modifications.

There are a few CDK tricks on show here.

Application Load Balancers with Restricted Inbound Access

By default in CDK when you add a Listener it will be configured to allow all inbound. I’m not a fan of that at all and thought it was a bug when I first realised, but turns out I just hadn’t read the docs carefully enough.

Make sure you add ‘open: false’ to the Listener props if you don’t want it open to the public.

Listener with restricted inbound

In the demo you can easily configure allowed CIDR ranges to restrict access to your web apps.

Fargate Clusters and Application Load Balancer in Different Stacks

Creating an Application Load Balancer and Fargate app in separate stacks is not straightforward. It is very useful to be able to do however if you have multiple apps to sit behind the ALB. In the demo here we are creating 3 (or more) web apps sitting behind a single ALB. Maybe not something you want to do in production unless the budget is tight, but very handy in development environments.

There are two different methods for splitting the ALB and Fargate Services into different stacks — split at Listener and split at Target Group.

Split at Listener:

  • Create the ALB without Listeners in the ALB stack
  • Add Listeners in the application stack

Split at Target Group:

  • Create the Listeners in the ALB stack
  • Create an empty Target Group in the ALB stack
  • Register the Fargate Service to the Target Group in the application stack

In this case we’re using the split at Target Group method as it’s the only way to have multiple apps on the same HTTPS Listener.

The key for this configuration is that you have to specify that the Target Group Type is IP in the ALB stack:

Target Group for Fargate Services in a different stack

Create Fargate Containers from Local Dockerfile

The (currently experimental) ECR Assets module in CDK allows us to create containers from a local Dockerfile. The container image is built locally using Docker Desktop, then pushed to an ECR repository where it can be pulled by Fargate as required.

Create Fargate Containers from Docker Hub (or ECR Public)

The demo includes a Wordpress server from Docker Hub, but you can easily specify any image you want to test.

Basic Scheduling in EventBridge

The demo includes a Lambda function for starting and stopping Fargate Tasks, which can be triggered by EventBridge Rules. Tasks are started and stopped by setting the desired count to one or zero.

Start/stop Fargate Tasks using a Lambda Function

EventBridge rule scheduling is set using CRON expressions. I find it useful to turn tasks on and off on workdays to keep costs down in development environments (and use the same technique for EC2 servers).

CDK — Lambda scheduler function and Event Rules

Security Groups and Roles

Ingress/egress rules are set to the minimum required to make the demo work. As we are pulling images from Docker Hub or ECR we need to allow all outbound from the ECS Task. This isn’t allowed in production in many environments, including where I work. The alternative is to pull only from ECR and allow outbound to VPC Endpoints, which is how we do it in production (along with Roles that allow access only to the required images).

Similarly with the Roles. I’ve taken a shortcut with the Role for the Lambda scheduler, and it can start/stop any ECS task in the Account. Alternatives include adding to the schedule Lambda Policy from the Application stack, or to using tags or prefixes for Tasks that can be scheduled. Otherwise everything is least privilege.

Requirements

This isn’t possible to do without a custom domain and certificate, so you will need a Route53 zone in your test account.

Hopefully some of you find this useful. Feel free to check out this and my other CDK demos on my Github profile.

About the Author

Mark is a 20+yr IT industry veteran, with technical expertise and entrepreneurial experience in a range of fields. For many years now his passion has been building on AWS, and he holds certifications including Solution Architect Professional and the Advanced Networking Specialty. He wants you to know that he is an infrastructure and architecture expert who writes code, not a professional software developer — just in case you spot something odd.

Mark has spent the last few years in the banking industry, were he is currently building and leading a team focused on using AWS serverless technologies to reduce costs and speed up the time to market for new services and products.

You can also find Mark on:

GitHub — https://github.com/markilott

LinkedIn — https://www.linkedin.com/in/markilott/

Twitter — https://twitter.com/mark_ilott

--

--

Mark Ilott

Solution Architect specialising in AWS, sharing IaC tips and tricks