Skip to content

PATTERN Cited by 1 source

Shared PrivateLink endpoints at tier level

Pattern

Establish AWS PrivateLink interface endpoints once per tier, inside the tier's infra-group VPCs, for each downstream service the tier consumes. All tenants in the tier inherit the pre-configured endpoints; no per-tenant endpoint provisioning. The endpoints' cost is amortised across tenants.

Canonicalised on the wiki by the 2026-05-12 AWS Architecture Blog post (Source: sources/2026-05-12-aws-building-hybrid-multi-tenant-architecture-for-stateful-services). Verbatim:

"This step happens at tier creation, not at tenant onboarding — and that distinction is the architectural heart of the design. For each downstream service your application integrates with, create a VPC interface endpoint in the infra group VPC. The ECS tasks in the tier route traffic to downstream services through these endpoints. Tenants onboarded to that tier can access downstream connectivity through the pre-configured endpoints."

The post attributes the 80% reduction in infrastructure setup steps primarily to this single architectural decision:

"This single architectural decision is the primary reason for the 80 percent reduction in infrastructure setup steps."

Shape

  • One VPC interface endpoint per downstream service per infra group. (Not per tenant.)
  • Established at tier / infra-group creation, before any tenant is onboarded.
  • Subnets: spans the infra-group VPC's subnets used by ECS tasks.
  • Security group: allows outbound traffic from ECS tasks on the required downstream-service port.
  • IAM: downstream-service access uses tier-level IAM roles attached to ECS task definitions (see systems/aws-iam).

Canonical CLI example

From the post:

aws ec2 create-vpc-endpoint \
  --vpc-id YOUR_VPC_ID \
  --service-name com.amazonaws.vpce.us-east-1.vpce-svc-YOUR_SERVICE_ID \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-*** subnet-*** \
  --security-group-ids sg-YOUR_SG_ID

The endpoint is declared in the infra-group VPC, not in a per-tenant VPC.

What this buys

Onboarding-time impact

Verbatim from the post:

"Tenants onboarded to that tier can access downstream connectivity through the pre-configured endpoints."

Without pre-wiring: every tenant onboarding includes 3+ weeks of VPC / PrivateLink setup, 1 week of IAM setup, 2 weeks of integration testing. With pre-wiring: these steps vanish; tenant onboarding is only 7 days (most of which is testing and validation of the tenant's product configuration, not dependency setup).

Cost amortisation

  • PrivateLink endpoint cost: ~$7.30/month per endpoint + $0.01/GB data transfer (from the post).
  • Per-tenant cost at 50 tenants sharing one endpoint: $7.30 / 50 ≈ $0.15/month per tenant.
  • Compared to per-tenant endpoints (account-per-tenant): 50 × $7.30 = $365/month for the same downstream connectivity.

The cost difference is an order of magnitude; the engineering- time savings are multiple orders.

Connection-setup amortisation

PrivateLink endpoint creation requires:

  • VPC endpoint service approval from the downstream-service owner (sometimes manual, with a turnaround).
  • Network-engineering review of security-group rules.
  • End-to-end integration testing.

Doing this once per tier means the downstream-service owner approves connectivity once, not 50+ times.

When to use

  • Multi-tenant architectures with several downstream dependencies shared across tenants.
  • Downstream services owned by other teams / AWS accounts where PrivateLink is preferable to VPC peering or Transit Gateway.
  • High tenant counts where per-tenant endpoint cost or setup time is material.

When not to use

  • Downstream services in the same VPC as the tier. Direct VPC-internal addressing is cheaper and simpler.
  • Small numbers of large tenants where per-tenant endpoints are preferred for isolation / billing audit.
  • Downstream services requiring per-tenant network-layer segregation (e.g., regulatory per-tenant-VPN). PrivateLink endpoints are shared at the network layer; per-tenant segregation must happen at the IAM / application layer.
  • Cross-region / cross-partition downstream access. The post covers same-region PrivateLink; cross-partition needs different mechanisms (see concepts/cross-partition-authentication).

The tier-level IAM role dependency

The pattern only works if downstream-service access is granted via tier-level IAM roles, not per-tenant IAM roles. The post explicitly:

"Define tier-level IAM roles with the permissions needed to access downstream services and assign these roles to ECS task definitions at the tier level. New tenants can receive the tier-level permissions through the shared IAM roles without per-tenant role creation."

Per-tenant IAM roles would re-introduce per-tenant onboarding tax even with shared endpoints; the payoff depends on both sharing the endpoint and sharing the IAM role.

Alternatives at other granularities

  • Per-tenant PrivateLink endpoints — full isolation; N× cost; N× provisioning. Used when per-tenant-auditability is required.
  • VPC peering — no per-endpoint cost; requires non- overlapping CIDRs; no VPC endpoint service abstraction.
  • Transit Gateway — hub-and-spoke; shared across accounts; higher infrastructure cost but simpler topology at scale.
  • VPC endpoint service (provider side) — the other end of PrivateLink; downstream-service owner publishes it once; multiple consumer accounts / tiers can connect.

Anti-patterns

  • Creating a new endpoint per tenant. Defeats the amortisation.
  • Using per-tenant security groups on shared endpoints. Security-group rules aren't tenant-aware; needed segregation must happen at the IAM layer.
  • Tying endpoint lifecycle to tenant lifecycle. Endpoints should outlive tenants; tenants come and go but the tier's downstream connectivity persists.
  • Provisioning endpoints at first-tenant onboarding rather than tier creation. The first tenant pays the setup cost; subsequent tenants inherit. But tier-level provisioning is cleaner as an operational boundary.

Caveats

  • The endpoint is shared at the network layer. All tenants of the tier can reach the downstream service; per-tenant authorisation must happen at the application / IAM level.
  • Endpoint-level outage affects all tenants of the tier. Blast radius = tier-size; not reduced by cell / infra- group subdivision unless the endpoint is re-established in each cell.
  • Cross-tenant eavesdropping at the endpoint level is not prevented. Rely on TLS on the application protocol if tenants shouldn't see each other's requests.
  • Endpoint capacity limits. PrivateLink endpoints have connection and bandwidth limits; tier-level aggregated load must be sized against them.
  • Downstream-service provider must agree to a single shared endpoint consumer for the tier. If the provider enforces per-consumer quotas via consumer AWS account ID, the shared endpoint looks like one big consumer.
  • Endpoint re-provisioning across tier expansion. Adding a new cell (new AWS account) requires re-establishing the same endpoint in the new cell's infra-group VPC; not transparently inherited.

Seen in

Last updated · 542 distilled / 1,571 read