Skip to content

AWS Database Connectivity and VPC Peering Plan

Purpose

This document defines the network path between the new ECS VPC and the existing production database VPC.

The goal is to keep database access narrow:

  • ECS services should reach the database through a controlled internal path
  • the Patroni nodes should not be opened directly to the ECS VPC unless required
  • the HAProxy layer should remain the primary ingress point for application traffic

Recommendation

Use VPC peering between the ECS VPC and the database VPC if both VPCs are in eu-west-2 and their CIDR ranges do not overlap.

For this migration, peering is the simplest default because:

  • both environments are in the same region
  • the dependency is internal-only
  • the routing model is straightforward
  • the access path can be restricted with security groups

If the HAProxy endpoint is published through shared private DNS and resolves in the ECS VPC, the ECS services can target that name directly. For example, if production-haproxy.timescale.glimpse.internal resolves to 10.0.1.12, and peering, routes, and security groups are in place, the ECS tasks can connect to that HAProxy endpoint without needing direct access to every Patroni node.

Connectivity Model

Preferred Path

Use the ECS application services to connect to the HAProxy cluster.

HAProxy then forwards traffic to PgBouncer or directly to the Patroni cluster nodes, depending on the existing production topology.

This means the ECS side should be allowed to reach the HAProxy endpoint only, not the entire database node set.

What ECS Needs

The ECS service security group should be allowed to reach only the HAProxy cluster on the required database port(s).

That means:

  • no direct ECS-to-Patroni-node rules unless they are required
  • no broad database subnet access from the ECS side
  • no public exposure of the database path

If the private DNS name resolves to a specific HAProxy IP, such as 10.0.1.12, the security group rule can target that HAProxy endpoint path rather than the Patroni nodes.

What HAProxy Needs

The HAProxy security group should be allowed to reach the downstream database targets it already proxies to:

  • PgBouncer, if that is the current forwarding layer
  • Patroni nodes, if HAProxy connects directly to them

Keep those backend rules internal to the database VPC. If those HAProxy-to-backend security groups already exist, leave them as-is and only add the ECS-to-HAProxy path required for this migration.

Security Group Layout

ECS VPC

Allow outbound from the ECS service security group to the HAProxy security group on:

  • PostgreSQL traffic port
  • any required read-only or read-write service port split, if the production topology uses one

Database VPC

Allow inbound to the HAProxy security group from the ECS service security group on the same required port(s).

Allow HAProxy to reach only the downstream database targets it actually needs.

Rule of Thumb

If the application talks to HAProxy, it should not need direct security group rules for every Patroni node.

If DNS, peering, and security groups are all configured correctly, the app can use the shared internal HAProxy name and the network path stays limited to that ingress point.

Routing

Requirements

If peering is used:

  • update route tables in both VPCs
  • ensure DNS resolution works for the internal endpoints you use
  • verify there is no CIDR overlap
  • keep the path private

Constraints

VPC peering is non-transitive.

That is fine here because the migration only needs a direct path between the ECS VPC and the database VPC.

DNS

Use a stable internal name for the HAProxy endpoint.

The ECS services should resolve the database entrypoint name, not individual node names.

Validation

Before cutover, confirm:

  • ECS tasks can reach HAProxy
  • HAProxy can reach PgBouncer or the Patroni nodes
  • the application can open and close database connections cleanly
  • failover behavior is still consistent with the existing production model