Deploying a Scalable .NET Application on AWS Using ECS Fargate, RDS, ALB and CloudFormation
In this hands-on AWS project, I deployed a containerized .NET web application using AWS managed services and explored how different AWS components work together to build a scalable, secure, and observable application.
The objective was to understand the complete application deployment lifecycle — from creating the network and security foundation, containerizing the application, storing the Docker image in Amazon ECR, running it using ECS Fargate, exposing it through an Application Load Balancer, connecting it securely to an RDS database, and finally implementing monitoring and Infrastructure as Code using CloudFormation.
Architecture
The application follows this flow:
Browser → Application Load Balancer → ECS Fargate → RDS
Supporting services include:
- Amazon VPC – Provides the isolated network environment.
- Subnets – Separate public and private resources.
- Security Groups – Control communication between ALB, ECS and RDS.
- Amazon ECR – Stores the Docker image of the .NET application.
- Amazon ECS Fargate – Runs the application containers without managing EC2 servers.
- Application Load Balancer – Provides the public entry point and distributes traffic to healthy ECS tasks.
- Amazon RDS – Hosts the relational database inside a private subnet.
- CloudWatch – Provides centralized logging, metrics and monitoring.
- SNS – Sends email notifications when CloudWatch alarms are triggered.
- Container Insights – Provides ECS container and task-level monitoring.
- AWS CloudFormation – Defines the infrastructure as code and allows the environment to be recreated consistently.
What I Implemented
The project was implemented in multiple stages.
First, I created the VPC, subnets, security groups, IAM roles, CloudWatch log group and SNS notification resources.
Next, I containerized the .NET application and pushed the Docker image to Amazon ECR. I then created an ECS Fargate cluster and task definition, configured the container resources and logging, and deployed the application as an ECS service.
An Application Load Balancer and Target Group were configured to route incoming HTTP requests to healthy ECS tasks.
For persistence, I created an Amazon RDS MySQL/PostgreSQL database in a private subnet. Access to the database was restricted so that only the application tier could communicate with it.
I also configured the application to consume the database configuration through AWS-managed configuration and updated the ECS task definition accordingly.
Scaling and Monitoring
To understand ECS scalability, I changed the desired task count and observed ECS automatically starting additional Fargate tasks.
For observability, I configured:
- CloudWatch Logs for centralized container logs
- CloudWatch Dashboard for ECS and RDS metrics
- CloudWatch Alarms
- SNS email notifications
- ECS Container Insights
This provided visibility into both the application's runtime behavior and the underlying AWS resources.
Infrastructure as Code
Finally, I explored AWS CloudFormation to represent the infrastructure as code.
The CloudFormation approach allows resources such as ECS, ECR, RDS and supporting infrastructure to be recreated consistently instead of manually configuring every resource.
I also worked with CloudFormation parameters and change sets to understand how infrastructure changes can be reviewed before deployment.
Key Learning
This project helped me understand how a traditional .NET application can be transformed into a containerized, scalable and monitored cloud application using AWS managed services.
More importantly, it provided hands-on understanding of how networking, security, containers, load balancing, databases, monitoring and Infrastructure as Code fit together in a real-world deployment architecture.
Technologies: C#, .NET, Docker, AWS ECS Fargate, Amazon ECR, Application Load Balancer, Amazon RDS, Amazon VPC, CloudWatch, SNS, Container Insights, CloudFormation.
Step by step guide to configure services in AWS-
1.Create VPC (Virtual Private Cloud)
VPC gives an isolated network in AWS where subnets, routing and network can have controlled access
2.Create Subnet
A subnet is a smaller network segment inside my VPC.
Ex- Public Subnet for ALB
Private/Application Subnet for ECS Fargate
Private DB Subnet for RDS
3.Create Security Groups
ALB-SG - Load balancer security group
Controls traffic coming into my Application Load Balancer
(inbound request port- HTTP 80,Source: Internet / 0.0.0.0/0)
ECS-SG - ECS Security Group
Controls traffic going to my ECS application containers.
TCP 8080, Source: ALB-SG
RDS-SG - RDS Security Group
Controls access to my database
TCP 3306, Source: ECS-SG
So far request flow model
Internet
|
| HTTP 80
v
ALB
|
| TCP 8080
v
ECS
|
| DB port (TCP 3306)
v
RDS
4.Create IAM roles
Create the required ECS task execution role to pull image from ECR and send logs to CloudWatch.
The ECS task needs an IAM execution role so that AWS can pull my container image from ECR and send container logs to CloudWatch.
ECS Task
|
+----> ECR
| Pull Docker image
|
+----> CloudWatch
Send container logs
5.Create CloudWatch Log Group
This is where my ECS container logs will be centralized.
Ex- /aws/ecs/my-application
6.Create SNS topic
SNS is responsible for sending notifications when my CloudWatch alarm is triggered.
Ex - aws-assignment-alerts
CloudWatch Alarm
|
v
SNS
|
v
7.Create ECR Repository (Elastic Container Registry)
ECR is AWS's managed Docker image registry. I use it to store my application's Docker image
Local machine
|
| docker build
v
Docker image
|
| docker push
v
ECR
8. Create ECS Cluster (Elastic Container Service)
ECS can run containers using Fargate or EC2, with Fargate being serverless
9. Create ECS Task Definition
A task definition describes how ECS should run my Docker container
Confiiguration
Task Definition
|
+-- Image: ECR
+-- CPU
+-- Memory
+-- Port: 8080
+-- Logging: CloudWatch
+-- Execution Role
10.Create Application Load Balancer
The ALB provides the public entry point to my application and distributes HTTP requests to healthy ECS tasks
Port 80, attach ALB- ALB-SG
11.Create Target Group
The target group identifies where the ALB should send application traffic and performs health checks on the targets
ALB
|
| HTTP
v
Target Group
|
| Port 8080
v
ECS Tasks
12.Create ECS Service
ECS service as the component responsible for running, stopping, managing and scaling containers
The ECS service maintains my desired number of running tasks. It also integrates the ECS tasks with my load balancer.
Navigate to your ECS cluster and create a service
Cluster
↓
Task Definition
↓
Fargate Service
↓
Desired task count
13.Configure networking for ECS
Choose
VPC
Subnets
ECS-SG
14.Verify ECS Task
Navigate to ECS -> cluster -> service -> Task
verify Task status = RUNNING and Target group Status = HEALTHY
15. Test ALB
Copy the ALB DNS name - http://<ALB-DNS>
16.Create DB Subnet Group
A DB subnet group tells RDS which subnets it is allowed to place the database in
Create RDS -> Subnet Groups -> DB Subnet Group
17.Create RDS
The database is deployed into private networking and its security group only allows connections from the ECS security group
RDS → Create database
Configure below properties
Database
|
+-- Private subnet
+-- RDS-SG
+-- Automated backups
+-- Backup retention
18.Save the RDS Endpoint
Once RDS is created, get RDS endpoint
19.Add DB connection string in .Net App
Add ECS task Environment variable to store DB connection string and then update the ECS version.
20. Validate the complete workflow
App flow
Browser
|
| HTTP :80
v
ALB
|
| :8080
v
ECS Fargate Container
|
| DB connection
v
RDS
Logging Flow
ECS Container
|
| logs
v
CloudWatch Logs
Image
ECR
|
| Docker image
v
ECS Fargate
21. ECS scaling
The ECS service maintains the desired number of tasks. When we increase the desired count from one to two, ECS starts another Fargate task.
Then check ECS => Task, you should be able to see 2 tasks running.
The ALB target group can then distribute requests among healthy tasks.
22. Cloud Watch Monitoring (Create CloudWatch Dashboard)
CloudWatch gives me centralized monitoring of my infrastructure instead of checking every service individually.
Create a dashboard containing metrics for
ECS
├── Service metrics
└── Task/container metrics
RDS
├── CPU
├── Connections
└── other relevant metrics
23.Create CloudWatch Alarm
The alarm should trigger an SNS email notification.
Flow
AWS Metric
|
v
CloudWatch Alarm
|
v
SNS Topic
|
v
24.Enable ECS Container Insights
Container Insights provides additional ECS task and container-level monitoring information.
Go to ECS-> Enable "ECS Container Insights"
25.Verify CloudWatch Logs
Instead of logging only inside the container, we should centralize the container logs in CloudWatch so they remain accessible for troubleshooting.
Go to CloudWatch → Log groups → ECS log group
Above steps will create ECS and RDS manually and we can access URL in browser. Now we can create the same infrastructure using CloudFormation (infrastructure as code).
* CloudFormation template
1.Create CloudFormation template
Cloud formation should create below items via code
CloudFormation
|
+-- VPC
+-- Subnets
+-- Security Groups
+-- IAM roles
+-- ECR
+-- ECS Cluster
+-- ECS Task Definition
+-- ECS Service
+-- ALB
+-- Target Group
+-- RDS
+-- CloudWatch
2.Add Parameters
Instead of hard-coding environment-specific values, we should parameterize the infrastructure so the same template can be reused with different configurations.
Parameters
|
+-- Region
+-- ECS Task CPU
+-- ECS Task Memory
+-- RDS instance size
3.Create Change Set
Creaet the template -> review it -> Deploy
Template code example
----Summary----------
------Components summary----------
1. ECR- "Docker image is stored in ECR."
2. ECS - "ECS Fargate pulls the image and runs it as a task."
3. ALB - "The ALB exposes the application through HTTP and forwards requests to healthy ECS tasks."
4. RDS -"The application connects to RDS, which is deployed in a private subnet and is not publicly accessible."
5. Security -"The ALB accepts internet traffic, ECS accepts traffic only from the ALB, and RDS accepts database traffic only from ECS."
6. Logging - "ECS container logs are sent to CloudWatch."
7. Monitoring - "CloudWatch monitors ECS and RDS, and alarms can send notifications through SNS."
8. Scaling - "We can increase the ECS desired task count and ECS launches additional Fargate tasks."
9. Infrastructure as Code - "Finally, We can reproduce the infrastructure using CloudFormation."
-------- Complete creation order------------
PHASE 1 — FOUNDATION
────────────────────────────────
1. VPC
2. Subnets
3. Security Groups
├── ALB-SG
├── ECS-SG
└── RDS-SG
4. IAM ECS Task Execution Role
5. CloudWatch Log Group
6. SNS Topic + Email Subscription
PHASE 2 — APPLICATION RESOURCES
────────────────────────────────
7. ECR Repository
8. Build Docker Image
9. Push Image → ECR
10. ECS Cluster — Fargate
11. ECS Task Definition
12. ALB
13. Target Group
PHASE 3 — CONNECT APPLICATION
────────────────────────────────
14. ECS Service
15. Connect ECS Service → Target Group
16. Connect ALB → Target Group
17. Configure ECS networking/security groups
18. Start ECS Task
19. Verify Target = HEALTHY
20. Open ALB DNS in browser
PHASE 4 — DATABASE
────────────────────────────────
21. RDS DB Subnet Group
22. RDS MySQL/PostgreSQL
23. Private subnet
24. RDS-SG
25. Automated backups
26. Note RDS endpoint
PHASE 5 — APPLICATION → DATABASE
────────────────────────────────
27. Store/configure DB parameter
28. Update ECS task configuration
29. Create new Task Definition revision
30. Update ECS Service
31. Verify application → RDS
PHASE 6 — SCALING
────────────────────────────────
32. Change desired count
33. ECS launches additional task
34. Verify both tasks
35. Verify ALB distributes traffic
PHASE 7 — MONITORING
────────────────────────────────
36. CloudWatch Dashboard
37. ECS metrics
38. RDS metrics
39. CloudWatch Alarm
40. SNS notification
41. ECS Container Insights
42. CloudWatch centralized logs
PHASE 8 — CLOUDFORMATION
────────────────────────────────
43. Create CloudFormation template
44. VPC/network resources
45. Security groups
46. ECR
47. ECS
48. ALB
49. RDS
50. Parameters
51. Create Change Set
52. Review
53. Deploy
54. Verify stack
Join the conversation! Your thoughts help the community grow.