CloudPulse

Overview

CloudPulse is an intentionally constrained, production-style cloud deployment designed to demonstrate container orchestration, Infrastructure as Code, and cost-conscious AWS architecture. The application consists of a React + TypeScript frontend, a Spring Boot REST API, and a PostgreSQL database deployed as containers on Amazon ECS using the EC2 launch type.

The system runs on a single EC2 instance with no load balancer, no NAT Gateway, and no managed database services. All infrastructure is provisioned with Terraform, and container images are built and deployed via GitHub Actions using OIDC-based role assumption.

This project emphasizes engineering tradeoffs, operational simplicity, and cost control while reflecting real-world deployment fundamentals.

---

Architecture Summary

Frontend

• React + TypeScript (Vite)
• Built into static assets
• Served via nginx container
• SPA routing via try_files
• API calls made via relative /api paths

Reverse Proxy

• nginx listening on port 80
• /api proxied to http://127.0.0.1:8080
• No TLS termination
• No load balancer

Backend

• Spring Boot (Java 17)
• REST endpoints:
  • GET /api/health
  • GET /api/services
  • POST /api/services
• JPA entity: service_instances
• Hibernate ddl-auto=update
• CORS configured
• No authentication layer

Database

• PostgreSQL 16 (containerized)
• Database: cloudpulse
• Host-mounted volume at /opt/cloudpulse/pgdata
• No RDS
• No migration tooling

Containerization

• Single ECS task definition
• Three containers:
  • postgres
  • backend
  • frontend
• networkMode = host
• Backend depends on Postgres HEALTHY
• Frontend depends on Backend START
• Environment variables injected at task level
• Logs shipped to CloudWatch via awslogs driver

---

Infrastructure

Provisioned entirely using Terraform.

State Management

• Remote state stored in S3
• State locking via DynamoDB
• Separate bootstrap and application stacks

Compute

• Amazon ECS (EC2 launch type)
• Auto Scaling Group:
  • min = 1
  • max = 1
  • desired = 1
• Instance type: t3.micro
• Capacity provider attached

Networking

• VPC with 2 public subnets
• Internet Gateway attached
• No private subnets
• No NAT Gateway

Security

• Security Group:
  • Inbound TCP 80 from 0.0.0.0/0
  • Ports 8080 and 5432 not publicly exposed
• Security boundary enforced at the instance level

---

CI/CD Pipeline

GitHub Actions handles build and deployment.

On push to the main branch:

• Backend Docker image is built
• Frontend Docker image is built
• Images are pushed to Amazon ECR
• GitHub OIDC assumes an IAM role (no static AWS credentials)
• ECS service is updated to use the new images

This provides automated, repeatable deployments without storing long-lived credentials.

---

Request Flow

Browser
  → nginx (port 80)
      → Spring Boot (localhost:8080)
          → PostgreSQL (localhost:5432)

All traffic enters through port 80 on a single EC2 instance.
Container-to-container communication occurs via localhost due to host networking.

---

Key Engineering Decisions

ECS (EC2 Launch Type) Instead of Fargate

ECS on EC2 was selected to:

• Reduce monthly costs for a continuously running service
• Maintain direct control over instance sizing
• Demonstrate understanding of capacity providers and ASGs
• Avoid per-task Fargate pricing overhead

Tradeoff

• Increased operational responsibility (instance lifecycle, AMI management)
• Less abstraction than Fargate

This choice prioritizes cost transparency and infrastructure control.

---

No Application Load Balancer

An ALB was intentionally omitted to:

• Eliminate additional fixed monthly cost
• Reduce architectural complexity
• Keep traffic flow simple for a single-instance deployment

Tradeoff

• No managed health check routing
• No horizontal scaling capability

For a single-instance architecture, nginx provides sufficient reverse proxy functionality.

---

No NAT Gateway / No Private Subnets

The deployment uses public subnets only.

Rationale

• NAT Gateways introduce significant monthly cost
• The workload does not require outbound-only private networking
• Ports 8080 and 5432 are not exposed publicly

Tradeoff

• Database is not isolated in a private subnet
• Security relies primarily on Security Groups

This reflects a deliberate cost-performance tradeoff suitable for a controlled portfolio deployment.

---

Containerized PostgreSQL Instead of RDS

PostgreSQL runs as a container within the ECS task.

Rationale

• Avoid RDS baseline cost
• Keep the entire system self-contained
• Demonstrate multi-container task orchestration

Tradeoff

• No automated backups
• No managed failover
• Persistence handled via host-mounted volume

This approach emphasizes infrastructure mechanics over managed service convenience.

---

Single EC2 Instance (t3.micro)

The system runs on one t3.micro instance.

Rationale

• Minimize infrastructure cost
• Demonstrate minimal viable production architecture
• Align resources to workload size

Tradeoff

• No redundancy
• Single point of failure

This is an intentionally constrained deployment to highlight engineering fundamentals rather than enterprise resiliency.

---

Infrastructure-as-Code with Terraform

All infrastructure components are defined in Terraform.

Benefits

• Repeatable provisioning
• Version-controlled infrastructure
• Clear separation of bootstrap and application layers
• Remote state with locking to prevent drift and race conditions

This ensures the environment can be recreated from code without manual configuration.

---

OIDC-Based GitHub Deployments

GitHub Actions assumes an IAM role using OIDC.

Rationale

• No static AWS credentials stored in GitHub
• Short-lived credential model
• Modern CI/CD security practice

Tradeoff

• Slightly more complex IAM configuration
• Requires trust relationship setup

This reflects secure automation patterns expected in production environments.

---

Operational Characteristics

• Logs available in CloudWatch
• ECS service maintains desired count of 1
• Postgres data persisted on host volume
• Service health endpoint: /api/health
• Manual scaling required (ASG max = 1)

This system is not designed for high availability or scale.
It is designed to demonstrate controlled, intentional cloud architecture decisions.

---

Intentional Limitations

• No TLS
• No authentication
• No horizontal scaling
• No automated database backups
• No blue/green deployments
• No load balancing

These constraints are deliberate to:

• Control cost
• Reduce architectural complexity
• Focus on infrastructure fundamentals

---

What This Project Demonstrates

• Multi-container ECS task orchestration
• Reverse proxy configuration with nginx
• Spring Boot container deployment
• Stateful container persistence
• Terraform-managed AWS infrastructure
• Remote state + locking
• OIDC-based CI/CD
• Cost-aware architectural tradeoffs

CloudPulse is a minimal but production-structured cloud deployment designed to demonstrate core AWS infrastructure engineering capabilities under real operational constraints.