AWS platform infrastructure

Backbone is deployed into AWS accounts owned by the operator. Infrastructure is defined as code (AWS CDK in TypeScript), provisioned deterministically per environment, and designed for container-native workloads on ECS Fargate.

Backbone is not a hosted SaaS control plane. The operator owns the account, networking, data, and runtime configuration.

This guide is for architecture review, procurement, and technical due diligence. Day-to-day CDK commands live in Operations and Runbook documentation.

Design goals

The infrastructure model prioritizes:

• Predictable deployments — repeatable stacks per environment (DEV, INT, STAGE, PROD)
• Horizontal scale — stateless ECS services behind load balancers
• Private-by-default — datastores and tasks in private subnets; controlled public edge
• Least privilege — scoped IAM, security groups, and secret access
• Progressive hardening — baseline suitable for mature deployments; room to add enterprise controls

Backbone intentionally avoids mandating a specific AWS Organizations layout. Operators can integrate the platform into existing landing zones.

Single region today: Each environment deploys to one AWS region with multi-AZ patterns inside that region. Multi-region failover is a roadmap consideration, not the current baseline.

High-level architecture

Browser traffic hits CloudFront at the environment apex hostname. Static UI is served from S3. API paths forward to a regional internet-facing ALB (CloudFront origin only) with origin verification. Application tasks run in private subnets and reach datastores over internal networking.

Environment composition

Each Backbone environment (e.g. INT, PROD) is a set of coordinated CDK stacks:

Stateful resources run inside private networking boundaries. Stateless application services scale horizontally by adding ECS tasks.

Container and release model

• One shared container registry per account/region holds versioned/tagged images for all services and environments.
• Immutable build tags trace each deployment to source; mutable service tags reference what ECS runs.
• Native or JVM runtime — operators can switch ECS task runtime mode (GraalVM native vs JVM) via deployment configuration without infrastructure redesign. See Runbook.

Images are built and published through GitHub Actions; deployment workflows update ECS task definitions.

Shared platform services

See Application caching and distributed scale and Rate limiting for how Redis is used.

Networking and security

• Public edge: CloudFront with WAF (hostname allowlist, rate limits, geo controls).
• Origin protection: CloudFront-to-ALB verification header; ALB security groups restrict source to CloudFront edge ranges.
• Internal traffic: Service-to-service calls use an internal load balancer; JWT validation at the application layer (not network trust alone).
• Optional internal TLS: Enterprise-tier opt-in via platform configuration.

Full edge and IAM posture: Platform security posture.

Baseline cost expectations (non-production)

Representative idle monthly cost in us-west-2 for a single-replica, minimal-endpoint footprint is on the order of ~USD 150/month, dominated by Fargate tasks, interface VPC endpoints, and load balancers. Actual costs vary with traffic, NAT usage, RDS storage, and endpoint AZ mode.

Validate production assumptions with the AWS Pricing Calculator. Gateway endpoints (S3, DynamoDB) do not incur hourly charges; interface endpoint AZ spread is often the largest hidden cost lever in smaller environments.

Availability posture

Backbone supports progressive hardening without redesigning application services.

Operator expectations

Further reading

• ADR-0022: Public ALB edge and origin protection
• ADR-0024: Internal ALB TLS (east-west, optional)
• Runbook §9: Enable internal ALB HTTPS
• Amazon ECS best practices guide — AWS Documentation