Skip to main content

Command Palette

Search for a command to run...

Managing AWS Fargate

CloudFormation Nested Stacks: A Beginner-Friendly Guide

Published
3 min read
P

As a associate system administrator I worked on Redhat Linux servers, including user management, permissions, services, and performance monitoring Automated routine administrative tasks using Bash scripting and cron jobs, reducing manual effort by ~30% I am aws certified sysops administrator and Google Certified Cloud Engineer. Determined to transition my career into cloud architect /Cloud Support role

Modern DevOps teams want to deploy containerized applications without worrying about servers, scaling, or infrastructure complexity. AWS Fargate, combined with CloudFormation nested stacks, provides a powerful yet manageable way to run production-ready microservices using Infrastructure as Code (IaC).

This article explains AWS Fargate, CloudFormation, and nested stacks in simple terms, then walks through a real-world architecture using practical examples and CLI commands.

What Is AWS Fargate?

AWS Fargate is a serverless compute engine for containers. It runs on top of Amazon ECS (Elastic Container Service) but removes the need to manage EC2 instances.

With Fargate:

You deploy Docker containers

AWS manages servers, scaling, and patching

You pay only for CPU and memory used

Think of Fargate as:

“Run containers in AWS without managing servers.”

This makes it ideal for microservices, APIs, and event-driven workloads.

What Is AWS CloudFormation?

CloudFormation allows you to define AWS infrastructure using YAML or JSON templates. This approach is known as Infrastructure as Code (IaC).

Benefits of CloudFormation:

Repeatable deployments

Version-controlled infrastructure

Easy rollback and cleanup

Reduced human error

A simple CloudFormation template that creates an ECS cluster looks like this:

Resources: FargateCluster: 
Type: AWS::ECS::Cluster
 Properties: ClusterName: my-fargate-cluster

While useful, real systems require many resources, which leads to large and hard-to-maintain templates.

Why Use CloudFormation Nested Stacks?

As applications grow, a single CloudFormation file becomes:

Difficult to read

Hard to reuse

Risky to update

Nested stacks solve this by breaking infrastructure into smaller templates, such as:

Networking

ECS cluster

Individual services

CI/CD pipelines

Each nested stack is defined as a resource:

Resources: BaseFargate: 
Type: AWS::CloudFormation::Stack
 Properties: TemplateURL: https://s3.amazonaws.com/mybucket/fargate-cluster.yaml 
Parameters: ClusterName: my-cluster

This approach improves:

Reusability

Readability

Team collaboration

High-Level Architecture Overview

In this setup, we deploy:

Three Fargate services (defense-api, offense-api, arbiter-api)

One ECS cluster

One VPC with public and private subnets

Application Load Balancers per service

ECR repositories for container images

Each service runs independently but follows the same reusable pattern.

Building and Pushing Containers to ECR

Before deploying Fargate services, container images must exist in Amazon ECR.

aws ecr create-repository --repository-name 
service-slayer-defense-api ACCOUNT_ID=$(aws sts get-caller-identity | jq -r '.Account')
docker build -t defense-api .
 docker tag defense-api:latest $ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/service-slayer-defense-api:latest docker push $ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/service-slayer-defense-api:latest

This image is later referenced in the CloudFormation service template.

Sharing Data Between Nested Stacks

Nested stacks often depend on outputs from other stacks, such as VPC IDs or subnet IDs.

VPCId: !GetAtt [ baseNetworking, Outputs.VPC ]

This allows stacks to remain independent while still working together.

Always define dependencies explicitly:

DependsOn: [ baseNetworking, baseFargate ]

This ensures predictable deployment order.

Deploying the Full Stack with AWS CLI

Parameters should also be defined as code:

[ { "ParameterKey": "ProjectName", "ParameterValue": "ServiceSlayer" }, { "ParameterKey": "BucketName", "ParameterValue": "devopstar" } ]

Deploy the stack using:

aws cloudformation create-stack 
--stack-name service-slayer 
--template-body file://deployment.yaml 
--parameters file://deployment-params.json 
--capabilities CAPABILITY_IAM

CloudFormation will create all nested stacks automatically.

Updating and Deleting Stacks

To update infrastructure:

aws cloudformation update-stack 
--stack-name service-slayer 
--template-body file://deployment.yaml 
--parameters file://deployment-params.json 
--capabilities CAPABILITY_IAM

To clean up and avoid costs:

aws cloudformation delete-stack --stack-name service-slayer

Everything created is safely removed.

Final Thoughts

Using AWS Fargate with CloudFormation nested stacks is a clean, scalable way to deploy microservices.

Fargate removes server management, while nested stacks keep infrastructure organized, reusable, and safe.

Together, they form a powerful DevOps foundation that scales from small demos to production systems—without chaos