Networking & Entry Points
This page describes how external traffic reaches the services managed by this repository, from DNS and CDN layers through to the Application Load Balancer (ALB) and ECS services.
The focus is on networking and entry points rather than application logic. Where relevant, we note which sibling repositories define the applications that run behind these entry points.
High-level HTTPS and auth flow
The diagram below shows the HTTPS and authentication flow for the Prefect surface.
At a high level:
- A user accesses
pipelines.rocketclub.online. - DNS for
rocketclub.onlineis served via Cloudflare in DNS-only mode (records are not proxied), resolving thepipelines.hostname to its AWS CloudFront distribution. - CloudFront distributions front the Application Load Balancer for the
pipelines.hostname. - The ALB terminates TLS and performs OIDC authentication with Kinde before routing traffic to the Prefect ECS service.
Domains and routing
This repository defines the AWS-side infrastructure for the main entry points into the platform.
| Hostname | DNS / CDN front door | AWS entry point | Target service | Defined where |
|---|---|---|---|---|
pipelines.rocketclub.online | Cloudflare → CloudFront | Application Load Balancer | Prefect ECS service/API | infra/platform/infra/modules/core/cloudfront-apps, infra/platform/infra/modules/core/alb |
Notes:
- Cloudflare provides DNS only here (records are not proxied); CloudFront is the CDN that fronts the ALB. The Cloudflare DNS records are managed in this repository via the Cloudflare Terraform provider (
cloudflare_dns_recordininfra/platform/infra/modules/core/cloudfront-appsandacm-alb-origin). Any other Cloudflare configuration (WAF, page rules, etc.) is managed outside this repository. - CloudFront distributions and the ALB are defined via Terraform modules under
infra/platform/infra/modules/core/cloudfront-appsandinfra/platform/infra/modules/core/alb.
Load balancer, listeners and target groups
The Application Load Balancer is responsible for:
- Terminating HTTPS/TLS for the
pipelines.hostname - Performing OIDC authentication with Kinde
- Routing traffic to the appropriate ECS target group based on the request path
From an infra perspective:
- ALB resources, listeners, listener rules and target groups are defined under
infra/platform/infra/modules/core/alb. - Certificates for the ALB origin are managed via the
acm-alb-originmodule. - The Prefect ECS service registers targets in ALB target groups so that health checks and routing work correctly.
The HTTPS and Auth diagram abstracts this into a single "ALB / TLS + OIDC" node, but the underlying Terraform modules in this repository are responsible for the concrete listeners, rules and security groups.
Kinde OIDC (high level)
The ALB uses Kinde as its OIDC provider for the Prefect entry point. For detailed configuration, secrets wiring and rotation runbook, see Security, IAM & Secrets.
Network topology
At a coarse level, the network topology is:
- A VPC with public and private subnets, defined in
infra/platform/infra/modules/core/network. - Internet-facing resources (CloudFront origins, ALB) in public subnets.
- ECS services and databases in private subnets behind the ALB.
- VPC endpoints and security groups used to control access from ECS tasks and Lambda functions to AWS services such as S3 and Secrets Manager.
This page does not attempt to document every security group rule; the source of truth is the Terraform under infra/platform/infra/modules/core/network and infra/platform/infra/modules/core/alb.
Relationship to applications
The networking and entry points described here are shared infrastructure used by applications defined in other repositories:
- The Prefect access surface at
pipelines.rocketclub.onlineis used to interact with Prefect, while the underlying flows and deployments are defined in the data platform (data/platform). - The web app (
apps/web) is deployed on Vercel and does not sit behind this ALB; it instead consumes Neo4j Aura, Cloudinary and S3 resources provisioned by this infrastructure.
For detailed application behavior, refer to the relevant sections of this documentation (the data platform lives in data/platform, the web app in apps/web, and these docs in apps/docs).