Managing AWS Fargate
CloudFormation Nested Stacks: A Beginner-Friendly Guide
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