How to Force a New Fargate Deployment via Multi-Account CDK

In this blog post, I’ll explain how I tackled a limitation with AWS CDK and CloudFormation, specifically when handling ECR images hosted in different accounts. Recently, I needed to trigger a new deployment whenever a new image was pushed to an ECR repository in another account. This was crucial for an ECS and Fargate workload running in other accounts. Unfortunately, AWS CDK and CloudFormation did not provide the necessary properties to handle this scenario directly.

To overcome this limitation, I devised a way to automate the deployment process effectively, ensuring that our ECS services were seamlessly updated with the latest images from the cross-account ECR repository. I leveraged Events and CDK at an architectural level to force deployment triggers whenever new tags were pushed to the ECR.

In this blog post, I will explain the issue I faced and the automation steps I implemented to overcome this limitation using Events Bridge lambda and CDK.

Here is the Diagram showing the flow:

The process begins when developers push their code to a version control repository. This commit and push action then triggers the subsequent CI/CD workflow steps.

The code repository is integrated with an AWS pipeline CI/CD system to enable the automated reception of pushed code. This integration also automates the build of the docker image and deployment processes of the Fargate service and other services depending on your design and application requirements.

The code is built into a container image, pushed to the ECR central repository in the Deployment account, and used by workloads accounts. Once the build is successful, the image is tagged and stored in the registry and ready for the workload accounts to use the image. We are using the central ECR repository to centralize the Dockers images in one central account that is also used for deployments for workload accounts.

An event is triggered in Amazon EventBridge when a new image with the appropriate environment tag is pushed to ECR. EventBridge listens for this event and triggers actions accordingly, executing a cross-account Lambda function authorized to deploy on the workload account.

We need a Lambda function to manage the deployment of the container image across multiple AWS accounts. To do this, we have to create a cross-account role in each workload account. This role will allow the central Lambda function in the policy account to take specified IAM policy actions such as ecs:DescribeServices, ecs:DescribeTaskDefinition, and ecs:UpdateService.

The deployment is executed on AWS Fargate within the workload account, ensuring the new container image is operational in the specified environment. This flag allows to force new deployment to reinitiate the container deployment.

Cross-account deployment involves deploying resources from the deployment account to the workload account. This requires setting up cross-account roles and permissions for secure deployment and allowing this solution to work.

This process outlines an automated deployment pipeline for a multi-account configuration using the Fargate. It enables developers to push code changes in the central repository, which are automatically built into container images and deployed across various AWS accounts using AWS services like ECR, EventBridge, Lambda, and Fargate. This setup ensures a seamless, efficient deployment process, minimizing manual intervention and maintaining consistency across environments.

Looking forward to your feedback. If you have any questions, please let me know.