PRODUCTION-GRADE DELIVERY MODEL

Production Delivery Architecture

End-to-end delivery model for a containerized Node.js workload on AWS ECS Fargate, covering CI/CD, infrastructure as code, remote state governance, IAM segmentation, HTTPS ingress, and operational observability.

IaC Provisioned

3 Environment Path

Gated Promotion

HTTPS Secure Ingress

CI/CD Pipeline with GitHub Actions

Governed delivery path that builds, packages, publishes, and deploys the service with environment-scoped configuration, remote state, and controlled promotion boundaries.

🔄

Automated Dev Delivery

Merges to main trigger dev deployments, keeping integration feedback fast while preserving higher-environment gates.

🎯

Controlled Promotion

Staging and production releases remain explicit through workflow_dispatch, keeping promotion intentional and reviewable.

🔐

Runtime Secret Boundaries

AWS credentials are injected at workflow runtime through GitHub Secrets and never committed with the source.

⚙️

Environment Contract

Region, service naming, VPC CIDR, TLS, and Terraform backend values are externalized through repository variables.

✓ SUCCESS Delivery Pipeline Execution

Build image → publish to ECR → deploy infrastructure and service through CDKTF

Confirms successful build-image and deploy-dev jobs using immutable commit-SHA image tagging.

DOCKER Container Build & ECR Publish

Repeatable Docker build with ECR repository bootstrap handled by the pipeline

Each image is tagged with the source commit SHA to support traceability and reproducible promotion.

MANUAL Controlled Staging / Production Promotion

Manual workflow_dispatch input separates integration delivery from release promotion

GitHub Actions Manual Staging and Prod Deploy

The environment selector keeps dev, staging, and prod deployments explicit and reviewable.

💡 ECR Lifecycle Boundary

The ECR repository is deliberately owned by the CI lifecycle rather than the Terraform stack. This keeps container artifacts independent from environment rebuilds and avoids deleting repositories that still contain deployable images.

CI creates the repository on demand when the first image is published.
Terraform state remains focused on runtime infrastructure instead of artifact retention.
Container images remain available during infrastructure updates, teardown tests, and rebuilds.

CDKTF CDKTF Infrastructure Apply

Infrastructure deployment with remote state and CloudWatch log integration

Captures cdktf deploy execution, resource creation, and deploy-time outputs used by the delivery flow.

🧱 Terraform State Governance (S3 + DynamoDB)

Terraform state is stored remotely to make infrastructure changes auditable, repeatable, and safe for team-based delivery:

S3 bucket: stores environment-scoped terraform.tfstate files.
DynamoDB table: serializes state mutations and prevents concurrent cdktf deploy runs.
Backend config: supplied through repository variables such as TF_STATE_BUCKET and TF_LOCK_TABLE.

S3 BACKEND Remote Terraform State in S3

Centralized backend with environment-scoped state paths

S3 provides encrypted backend storage with prefixes separating dev, staging, and production state files.

LOCKING DynamoDB State Lock Table

State locking to serialize infrastructure mutations

DynamoDB prevents competing cdktf/terraform applies from modifying the same state concurrently.

🔒 SECRETS GitHub Secrets

Runtime credentials isolated from source control

AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are injected only during workflow execution and are not printed to build logs.

CONFIG Delivery Configuration Contract

Environment-specific infrastructure inputs managed outside the application code

Includes AWS_REGION, SERVICE_NAME, VPC_CIDR, Terraform backend values, TLS settings, and environment-specific runtime inputs.

Deployment-time variable injection showing the complete environment contract consumed by CDKTF.

IAM Boundary & Security Model

Segregated CI/CD identity, group-managed permissions, and ECS task roles keep deployment authority, runtime execution, and future application AWS access clearly separated.

👤

Dedicated CI Identity

A non-human deployment principal keeps automation access auditable and separate from operator accounts.

👥

Group-Managed Permissions

CI permissions are centralized through IAM groups to simplify review and policy updates.

🎭

Runtime Role Separation

ECS execution and application roles separate platform actions from workload-level AWS access.

🔒

Least-Privilege Expansion

The application role starts empty and is extended only when the workload requires specific AWS APIs.

IAM USER CI/CD Identity

Dedicated AWS IAM principal for GitHub Actions delivery

turbovets-github-actions-user is scoped to automation credentials rather than human console access.

DETAILS Credential & Membership Summary

Access-key lifecycle and group assignment for the CI identity

The access key is reserved for GitHub Actions and can be rotated independently of application code.

GROUP Group Membership

User assigned to turbovets-github-actions-group

Group assignment keeps CI permissions centralized and easier to review as the platform evolves.

PERMISSIONS Deployment Permission Set

Grouped AWS permissions required for infrastructure and service delivery

Covers the ECR, ECS, VPC, IAM, CloudWatch, ALB, Route53, and ACM actions required by the delivery pipeline.

TurboVetsDevOpsCiACMRoute53Policy policy

Permission breakdown showing inherited group policies and the dedicated Route53/ACM policy used for DNS and certificate operations.

🔐 IAM Design Decisions

Dedicated automation identity: CI/CD activity remains auditable and separate from human access.
Group-based permissions: Policies are easier to review, version, and adjust as the delivery surface grows.
No inline user policies: Permissions are managed through group-attached policies instead of user-specific exceptions.
Credential rotation: CI credentials can be rotated without source-code or application changes.
ECS execution role: Handles platform-level operations such as ECR image pulls and CloudWatch log publishing.
ECS application role: Kept empty by default and extended only for explicit workload-level AWS API needs.

AWS Runtime Infrastructure

CDKTF-provisioned AWS runtime foundation with multi-AZ networking, ECS Fargate service placement, HTTPS ingress, target group health checks, and security group segmentation.

Multi-AZ VPC

Public subnets across two Availability Zones provide baseline availability and blast-radius separation.

Application Load Balancer

TLS termination with ACM plus HTTP-to-HTTPS redirect for a single controlled ingress path.

ECS Fargate

Managed container runtime that removes server maintenance while keeping service scaling options available.

Security Groups

Network rules restrict traffic paths between the ALB and ECS tasks.

ACTIVE ECS Runtime Cluster

turbovets-app-dev-cluster hosting the dev service instance

Cluster is created through CDKTF with environment-specific naming and repeatable provisioning.

SERVICE ECS Service Summary

Fargate service placement, desired count, and load balancer association

Validates one desired task, one running task, and active ALB target registration for the dev environment.

✓ HEALTHY Target Health Verification

ALB target group health checks are passing

The /health endpoint returns 200 OK, giving the load balancer an explicit service-readiness signal.

NETWORKING Task Networking & Security Groups

Subnet placement and traffic boundaries for ECS tasks

Tasks are placed across public subnets, fronted by an internet-facing ALB, and constrained by security groups that define the allowed traffic path.

📌 Runtime Architecture Highlights

Core runtime resources such as VPC, ALB, ECS, and security groups are provisioned through CDK for Terraform.
Traffic follows a clear ingress path: Route 53 → ALB over HTTPS → ECS Fargate tasks.
CloudWatch Logs provide environment-scoped visibility for each ECS task family.
Networking, IAM, and deployment boundaries are intentionally separated to keep the platform understandable, supportable, and ready to evolve.