It’s always fun to see what we’ve learned in action. Based on what we have explored so far, let’s get our hands dirty by deploying a test application on Amazon ECS. This time, we’ll create a newapplication that you can also use and customize beyond the scope of this chapter, as per your personal preferences – a To-Do List Manager.

We will sprinkle some data persistence elements into the application architecture to make it as close as possible to real-life usage patterns, where you would like to add new tasks and delete a few others daily. Let’s outline the main components of the application, as highlighted in Figure 7.2.

Understanding the test application architecture

To-Do List Manager is an application that allows you to manage all the tasks that you accomplish in your day-to- day routine. In this exercise, we will develop and host two features: creating new tasks and deleting the ones that are complete. You can also further extend the scope of the application and personalize it to your taste. Several application- and infrastructure-level components communicate with each other to expose task management capabilities to the end user. They can be broadly categorized into two segments – infrastructure components and application components.

Infrastructure components

These are the services that support the underlying infrastructure foundations on top of which the application runs. As always, you need a VPC, subnet, and corresponding route tables for traffic flow management. Once the user requests hit an Application Load Balancer hosted on the edge, it forwards the packets to an ECS cluster, which then returns a HTTP response, based on the type of request that was sent. As we’ve already discussed in this chapter, ECS is further composed of services, tasks, and task definitions. We will make use of all of them to host our Python-based web application in an AWS account.

As we saw in the previous chapter, A Programmatic Approach to IaC with AWS CDK, it’s very efficient to leverage existing CDK constructs to build and deploy AWS infrastructures at scale. Thisenables us to avoid investing a lot of time in writing CloudFormation templates from scratch. Therefore, we will define the entire infrastructure required in this chapter using AWS CDK.

The following are the three layers under the infrastructure segment:

• Network infrastructure (VPCs, subnets, and route tables): We will create a standard 10.0.0.0/16 VPC CIDR block for this exercise and carve out two public and two private subnets, each with a /24 mask. We will offload all the tasks around route table creation, route entries, NAT gateways, and internet gateways to CDK using the aws-cdk-lib/aws-ec2 library.
• Container platform (ECS): Within the scope of ECS, we will create task definitions that allocate compute and memory resources, and further define two containers for the application and the database. To have an always running application instance, we will wrap it into an ECS service that integrates with the Application Load Balancer. As we don’t want to manage any EC2 instances, we will use the Fargate launch type, thereby offloading this responsibility to the ECS service.

• Traffic controller (Application Load Balancer): To receive requests from the end user, we will create a public-facing Application Load Balancer and drop its interfaces into the public subnets of the VPC. ECS automatically registers the running containers with the respective target group, thereby abstracting the container port, 5000 (used by Flask), behind the regular HTTP 80.

Take a look at Figure 7.2 for a visual understanding of what the overall communication flow looks like:

Figure 7.2 – Infrastructure components of the To-Do List Manager application hosted on ECS

The infrastructure elements by themselves don’t support any real-life usage patterns. So, let’s dive into the application components that will breathe life into these foundational elements.