AWS Infrastructure

Every resource the AWS template creates, and what each one is for.

This is the actual shape of the AWS CloudFormation template — a VPC, an ECS Fargate cluster running three services, a Postgres database and a Redis cache, all reachable through exactly one public entry point. Everything below is real: read against your own review checklist, not summarized for it.

Cloud-Vex AWS infrastructure. A CloudFront distribution outside the VPC is the only public HTTPS endpoint, terminating TLS at the edge and reaching an internal Application Load Balancer through a CloudFront VPC origin - the load balancer has no public route of its own. Inside the VPC, across two availability zones, an ECS Fargate cluster runs three services: a backend service behind the load balancer serving the API and web UI and handling login and collector setup links, a scheduler service running exactly one task outside the load balancer that fires scheduled scans and licence and update checks, and a worker service that consumes the scan queue over Redis so a started scan actually runs. The backend and scheduler write to an RDS for PostgreSQL 15 database, encrypted at rest with a customer-managed KMS key, private-subnet only, with 30-day backups. The backend and worker share an ElastiCache for Redis cluster as the scan job queue, also private-subnet only. Outside the VPC, Secrets Manager holds the database password, initial admin credentials, session-signing key and licence key, never as a stack parameter. An S3 bucket hosts the collector setup templates the backend links to. CloudWatch Logs holds every service's logs. Two IAM roles separate what pulls the container image and writes logs from what the running application itself is allowed to do.

Network

  • VPC, across two availability zones — the boundary everything else lives inside.
  • Public subnets, NAT Gateway & Internet Gateway — the only route to the internet, and it's outbound-only: it's what lets the scheduler reach the licence and update-check endpoints without anything being reachable from outside.
  • Private subnets — where the load balancer, ECS tasks, database and cache actually run. No route to the internet at all.
  • Security groups — each tier only accepts traffic from the one immediately in front of it: load balancer ← CloudFront, ECS tasks ← load balancer, database and cache ← ECS tasks.

Edge

  • CloudFront distribution — the only public HTTPS endpoint. Terminates TLS at the edge, on a custom domain if you set one.
  • Application Load Balancer (internal) — reached only through a CloudFront VPC origin. It has no public route of its own, whatever its security group says.
  • Route 53 alias record (optional) — created only when a custom domain's hosted zone is Route 53 in this same account. Points that domain at the CloudFront distribution automatically, instead of a manual DNS step. See the reference guide for the full flow.

Compute — ECS Fargate

  • Backend service — serves the API and web UI, same origin, behind the load balancer. Handles login, the SSO callback, and generates collector setup links. Scales with the stack's task-count parameter.
  • Scheduler service — exactly one task, not behind the load balancer. The same image as the backend with the scheduler switched on; fires scheduled scans and the daily licence and update checks.
  • Worker service — consumes the scan queue over Redis. Without it, a started scan enqueues and stays "running" forever.

Data

  • RDS for PostgreSQL 15 — the findings store: scan results, accounts, users, settings. Encrypted at rest, private subnets only, 30-day backups.
  • ElastiCache for Redis — the scan job queue between the backend and the worker. Private subnets only, no public endpoint.

Secrets & encryption

  • Secrets Manager — four secrets: the database password, the initial administrator's credentials, the session-signing key, and the licence key. None of these are ever a stack parameter or a template default.
  • KMS — the customer-managed key encrypting the database and its secrets.
  • IAM task execution role & task role — the execution role only pulls the container image and writes logs; the task role is what the running application itself is allowed to do.

Storage

  • S3 (collector template bucket) — hosts the CloudFormation, ARM and Deployment Manager templates the backend generates setup links to, for adding a collector in another cloud account.

Monitoring

  • CloudWatch Logs — every task's stdout and stderr, one log group shared across the backend, scheduler and worker services.

This is the hub's own account. Adding another AWS account, or Azure or Google Cloud, deploys a much smaller collector into it instead — covered by the permission model and the scan cycle pages.

Need this against your own security review checklist? Email support@cloud-vex.com.

Join the waitlist