Gatus Monitoring on ECS Fargate
A secure monitoring deployment on AWS ECS Fargate, with automated CI/CD, private networking and a 97.6% reduction in container image size.
Technologies
The project
Overview
I deployed Gatus, an open-source endpoint monitoring application, on Amazon ECS Fargate using Terraform-managed infrastructure and automated GitHub Actions pipelines.
The application runs in private subnets across two Availability Zones, behind an Application Load Balancer. Route 53 provides DNS, while AWS Certificate Manager enables HTTPS.
Beyond deploying the monitoring service, I focused on container optimisation, secure networking and automating the complete infrastructure lifecycle.
System design
Architecture
Architecture diagram from the project.
The challenge
The project required a monitoring application that could be deployed consistently without exposing its containers directly to the internet.
The original single-stage Docker image was approximately 2.45 GB because it included build dependencies and tooling that were unnecessary at runtime.
I also needed to automate image delivery and infrastructure changes while keeping AWS credentials out of the CI/CD configuration.
How the architecture works
Monitoring workload
Gatus runs on ECS Fargate and evaluates configured endpoints, providing visibility into uptime, response times and service health.
Private networking
ECS tasks run without public IP addresses in private subnets across two Availability Zones. Security groups restrict application ingress to the ALB security group.
Public access
Route 53 directs traffic to an internet-facing Application Load Balancer. ACM provides HTTPS, with HTTP requests redirected to HTTPS.
Infrastructure automation
Terraform provisions the VPC, ECS services, load balancer, certificates and DNS resources. Remote state is stored in S3 with locking.
Container delivery
GitHub Actions builds and scans the Docker image, pushes it to Amazon ECR and deploys infrastructure changes using OIDC-authenticated AWS access.
Infrastructure lifecycle
Separate build, deployment and destroy workflows support repeatable releases and allow the AWS environment to be removed when it is no longer required.
Behind the build
Implementation
Reducing Docker image size by 97.6%
The original single-stage Docker image was approximately 2.45 GB, including build tooling and dependencies that were not needed by the running application.
I replaced it with a multi-stage build that separates compilation from the final runtime image, reducing the image size to approximately 58 MB.
The final container also runs as a non-root user, with file ownership configured to provide only the permissions needed at runtime.
Designing secure AWS networking
I provisioned a multi-AZ VPC with public and private subnets. The Application Load Balancer handles incoming traffic, while ECS Fargate tasks remain isolated in private subnets.
Security groups use security-group references so application tasks accept inbound traffic from the ALB rather than from unrestricted public CIDR ranges.
A NAT Gateway provides outbound connectivity for private workloads, while Route 53 and ACM provide custom-domain access over HTTPS.
Automating build and deployment
GitHub Actions builds the container image, runs Trivy vulnerability scanning and pushes the resulting image to Amazon ECR.
A separate deployment workflow applies Terraform changes, with infrastructure configuration and image references supplied through pipeline variables.
OIDC allows the workflows to obtain temporary AWS credentials without storing static IAM access keys in GitHub.
Managing infrastructure with Terraform
Terraform modules manage the VPC, ALB, ECS, ACM and Route 53 resources. Infrastructure state is stored remotely in S3 using native locking.
The project includes dedicated workflows for deploying and destroying the environment, making it possible to reproduce the infrastructure and remove resources when they are no longer needed.
Monitoring endpoint health
Gatus provides visibility into endpoint availability, response times and configured health conditions through its monitoring interface.
The monitoring workload demonstrates an important operational distinction: an application can be running while its dependencies or externally visible endpoints are unhealthy.
The project focuses on endpoint monitoring rather than presenting Gatus as a replacement for a full metrics, logging and tracing platform.
Key takeaways
Multi-stage Docker builds can substantially reduce runtime image size by excluding build-only dependencies.
Private subnets and security-group references provide clearer control over application exposure.
OIDC-based CI/CD authentication avoids storing long-lived AWS access keys.
Container vulnerability scanning adds a security check before images enter the deployment process.
Infrastructure teardown should be automated alongside deployment, especially for environments that incur ongoing cloud costs.
Reflection
What this project taught me
The most significant improvement was reducing the container image from approximately 2.45 GB to 58 MB. Combined with private networking, automated delivery and reproducible infrastructure, the project demonstrated how deployment engineering can improve the security and efficiency of a relatively small application.
Explore the source code