Cross-VPC Database Access for a Partner
A company hosts its order service in VPC-A (10.0.0.0/16) and its analytics database in VPC-B (10.1.0.0/16), both in the same region and account. A partner needs read access to a curated analytics view from their own VPC-C (10.2.0.0/16) in a different account. The company's security policy forbids exposing the database on the public internet and forbids overlapping CIDRs. The partner's CIDR is fixed and cannot change. The internal order service must keep talking to the database over private addresses. The team proposes three options: peer VPC-A with VPC-C, peer VPC-B with VPC-C, or attach all three to a transit gateway. They want a recommendation and a security review.
1. Evaluate the three proposed connectivity options against the constraints.
Read the worked answer
- Peer VPC-A with VPC-C: Wrong target. VPC-A holds the order service, not the database. Peering A–C would expose the order-service subnet to the partner and still not reach the database. Reject.
- Peer VPC-B with VPC-C: Works technically if the CIDRs do not overlap (10.1/16 vs 10.2/16 is fine) and peering is supported cross-account. It is the minimal blast radius: only the database VPC is connected to the partner. This is the strongest simple option.
- Transit gateway with all three: Also works and centralizes routing, but it attaches VPC-A to the same hub as the partner, which widens the partner's potential reach unless route tables and segmentation are carefully scoped. More operational overhead than needed for one partner.
Given a single partner and a single database VPC, peer VPC-B with VPC-C is the best fit. Use a transit gateway only if more partners or VPCs are expected soon.
2. Describe the security controls needed so the partner can read only the curated view and nothing else.
Read the worked answer
Connectivity is not authorization. Layer controls:
- Network: In VPC-B, allow inbound only from the partner's specific CIDR on the database port; deny everything else. Do not route the partner to any other subnet.
- Database: Create a dedicated read-only account scoped to the curated view/schema. Grant no access to base tables or other schemas. Enforce read-only at the engine level.
- Identity: If the database supports it, use short-lived credentials or a secrets manager rather than a static shared password. Rotate regularly.
- Audit: Enable database audit logging and VPC flow logs so partner queries and connection attempts are traceable.
- Review: Confirm the partner CIDR does not overlap any company CIDR before peering; overlapping CIDRs would silently break routing.
3. The partner later reports intermittent timeouts. What would you check first, and why?
Read the worked answer
Check in this order:
- Route tables on both sides. Peering requires routes in both VPCs pointing at the peering connection. A one-sided route causes asymmetric or missing return paths.
- Security groups and network ACLs. A stateless ACL that allows outbound but not the return ephemeral ports will drop responses intermittently.
- CIDR overlap or a more specific route. A conflicting route can send some traffic elsewhere, producing intermittent rather than total failure.
- Database connection limits and idle timeouts. Intermittent timeouts under load often reflect connection pool exhaustion rather than networking.
The pattern (intermittent, not total) points to routing asymmetry or ACL return-port issues before it points to the database itself.