Individual cloud infrastructure project · 2026

AWS Fargate infrastructure with Vault workload identity

A production-minded Terraform design for running private Fargate workloads without embedding cloud credentials or Vault tokens in the task definition.

Role: Architecture, Terraform implementation, security model, tests, and documentation
Stack: AWS, Terraform, ECS Fargate, VPC, ALB, IAM, Vault, CloudWatch
Scope: Locally validated architecture; no live AWS environment claimed

Problem

Give a private workload an identity, not a static secret

The design needed to expose a small service safely while keeping its containers private. Runtime content had to come from Vault without placing a long-lived Vault token or AWS access key in the task definition.

2 availability zonesPublic load-balancer subnets and private Fargate subnets.
0 static tokensThe ECS task role authenticates directly through Vault AWS auth.
3 tested variantsAWS-only, Vault-enabled, and ACM-backed HTTPS plans.

Architecture

Public routing, private execution

IngressApplication Load BalancerPublic HTTP or ACM TLS across two availability zones

NetworkPublic subnetsInternet gateway, ALB, and one cost-conscious NAT gateway

BoundarySecurity groupsPort 8080 reaches tasks only from the ALB

↓ private routing, no public task IPs ↓

ComputeECS Fargate serviceApplication and Vault Agent containers with read-only roots

IdentityIAM task roleRotating workload credentials used for signed Vault authentication

Runtime dataEphemeral volumeVault Agent renders the permitted KV path for the application

↓ operations and external secret service ↓

SecretsVault AWS authExact role binding, short token lifetime, and narrow read policy

ObservabilityCloudWatchContainer logs, 30-day retention, and Container Insights

ReliabilityHealth and scalingALB checks, container checks, rollback, and CPU autoscaling

Runtime flow

Authenticate and render before accepting traffic

ECS supplies rotating task-role credentials to the Vault Agent sidecar.
The agent signs an AWS IAM request and authenticates to a Vault role bound to that exact task-role ARN.
A least-privilege policy permits reads only from the required KV v2 path.
The agent renders the returned content into a task-scoped ephemeral volume.
The application becomes healthy after the file exists; the ALB then begins routing requests.

The application container never needs a Vault token, AWS access key, or direct permission to retrieve broader secrets.

Delivery

A quality gate that cannot deploy by accident

GitHub Actions runs Terraform formatting, initialization without a backend, configuration validation, and credential-free plan tests with mocked AWS and Vault providers. The workflow deliberately has read-only repository permissions and no cloud credentials.

The Makefile creates a saved Terraform plan but never applies during planning.
Applying requires both an existing reviewed plan and an explicit ALLOW_APPLY=yes gate.
The service uses a deployment circuit breaker with automatic rollback.
Optional ACM configuration redirects HTTP to HTTPS using a modern TLS policy.

Engineering

Reliability, security, and cost are design inputs

Network isolationOnly the load balancer is public; tasks run privately without public IP addresses.
Workload identityECS-managed credentials replace long-lived keys and static Vault tokens.
ObservabilityBoth containers emit structured runtime output through awslogs and Container Insights.
AvailabilityThe service spans two availability zones and combines health checks, rolling replacement, rollback, and autoscaling.
Cost awarenessFargate Spot receives most scheduling weight, scaling is bounded, and the NAT topology is an explicit demo tradeoff.
Precise scopeThe configuration and three mocked plan variants are locally verified. No live AWS deployment is presented as production experience.

View repository and diagrams ↗