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 Backstage portal and Prefect surface.

At a high level:

1. A user accesses portal.rocketclub.online or pipelines.rocketclub.online.
2. DNS for rocketclub.online is served via Cloudflare, which proxies traffic towards AWS.
3. CloudFront distributions front the Application Load Balancer for the portal. and pipelines. hostnames.
4. The ALB terminates TLS and performs OIDC authentication with Kinde before routing traffic to ECS services for Backstage and Prefect.

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
portal.rocketclub.online	Cloudflare → CloudFront	Application Load Balancer	Backstage ECS service	infra/modules/core/cloudfront-apps, infra/modules/core/alb
pipelines.rocketclub.online	Cloudflare → CloudFront	Application Load Balancer	Prefect ECS service/API	infra/modules/core/cloudfront-apps, infra/modules/core/alb

Notes:

• Cloudflare is modeled as an external CDN/proxy in the diagrams; exact Cloudflare configuration (page rules, WAF, etc.) is managed outside this repository.
• CloudFront distributions and the ALB are defined via Terraform modules under infra/modules/core/cloudfront-apps and infra/modules/core/alb.

Load balancer, listeners and target groups

The Application Load Balancer is responsible for:

• Terminating HTTPS/TLS for portal. and pipelines. hostnames
• 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/modules/core/alb.
• Certificates for the ALB origin are managed via the acm-alb-origin module.
• ECS services for Backstage and Prefect register 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 both Backstage and Prefect entry points. 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/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/modules/core/network and 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 Backstage application and config in blog_portal run on the Backstage ECS service behind the portal.rocketclub.online entry point.
• The Prefect access surface at pipelines.rocketclub.online is used to interact with Prefect, while the underlying flows and deployments are defined in blog_data.
• The public blog frontend in blog_code is deployed on Vercel and does not sit behind this ALB; it instead consumes Neo4j Aura, Cloudinary and S3 resources provisioned by this repository.

For detailed application behavior and user-facing documentation, refer to the appropriate application repositories (for example blog_portal, blog_data, blog_code and blog_docs).