Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Technology / AI SaaS |
| Cloud Environment | AWS (4 accounts), multiple VPCs per account |
| Database Types | MariaDB (primary), PostgreSQL (planned migration) |
| Network Constraint | VPC CIDR conflicts; VPC Peering ruled out |
| Deployment Model | ECS-based JIT DB components in customer’s VPC |
| RDS Authentication | IAM Authentication enabled during onboarding |
| Team Access | All developers have access to Development account |
| Primary Challenge | Deploy DB JIT without cross-VPC networking |
| Cloudanix Scope | Database JIT across 4 accounts, multiple VPCs |
The Situation: The Network Won’t Bend
When this AI SaaS company decided to adopt Database JIT, the technical conversation hit an immediate constraint: the company’s VPC architecture made conventional database proxy solutions non-viable.
The problem was simple in concept and difficult in practice: VPC CIDR conflicts. The company’s AWS environment had grown organically across 4 accounts with multiple VPCs in each. Subnet ranges overlapped between accounts and VPCs — a common legacy of rapid scaling where network address planning wasn’t centralized from day one.
VPC Peering — the standard AWS mechanism for connecting VPCs — requires non-overlapping CIDR ranges. With overlapping ranges across their environment, peering was architecturally impossible without a major re-IP effort that would disrupt running workloads.
The team had also had a negative experience with VPC Peering in the past. The combination of technical impossibility (CIDR conflicts) and organizational reluctance (bad prior experience) meant peering was categorically off the table. Any solution that required cross-VPC network connectivity through peering, Transit Gateway with conflicting routes, or external VPC dependencies would fail at the network layer before it reached the application layer.
The question for Cloudanix was: can you deliver Database JIT entirely within the customer’s existing VPCs, without requiring any cross-VPC networking?
The Core Challenge
Database JIT requires a component that can reach RDS instances in private subnets and broker temporary credentials to developers. Most approaches require this component to live in a central network location with connectivity to all database VPCs. In an environment where VPC Peering is impossible (CIDR conflicts) and cross-VPC networking is organizationally vetoed, the JIT infrastructure must deploy inside each VPC that contains databases — not connect to them from outside.
Where the Gaps Were
VPC CIDR Conflicts: The Silent Infrastructure Debt
CIDR conflicts accumulate quietly. A team spins up VPC-A with 10.0.0.0/16. Another team (or the same team, six months later) creates VPC-B with 10.0.0.0/16 in a different account. Both work fine independently. The conflict only surfaces when someone tries to connect them.
For this company:
- 4 AWS accounts, each with multiple VPCs.
- Organic growth meant no centralized IP address management.
- Multiple VPCs used the same or overlapping CIDR ranges.
- Result: No VPC Peering possible between these environments.
This isn’t unusual. It’s one of the most common networking legacies in AWS environments that scaled without a network architecture team. But it constrains every solution that assumes cross-VPC connectivity.
The “Central Proxy” Model Doesn’t Work Here
Many database access solutions deploy a central proxy or bastion in a dedicated “security VPC” and peer it to all other VPCs. This model assumes:
- You can peer the proxy VPC to every database VPC (requires non-overlapping CIDRs).
- Routes from the proxy VPC to each database VPC don’t conflict.
- Security groups on RDS instances can allow traffic from the proxy VPC’s CIDR.
All three assumptions fail in this environment. A central proxy with spokes to each database VPC was architecturally impossible.
PrivateLink Is an Alternative — But Not For RDS
AWS PrivateLink can expose services across VPC boundaries without peering. But RDS isn’t a PrivateLink-native service. You can’t expose an RDS instance as a PrivateLink endpoint without building custom NLB + target-group infrastructure for each database — multiplied by the number of databases across accounts and VPCs. This becomes its own maintenance burden and still requires infrastructure provisioning per database.
The Team’s Previous Bad Experience
Beyond the technical impossibility, the team had a prior negative experience with VPC Peering. The specifics weren’t elaborated, but the organizational position was clear: peering is not an option, period. When evaluating Cloudanix for Database JIT, this was stated upfront as a hard constraint, not a preference.
The Cloudanix Solution: Per-VPC ECS Deployment
Cloudanix Database JIT addresses VPC-constrained environments by deploying the database proxy component inside each VPC that contains databases — eliminating any need for cross-VPC networking.
Architecture: One ECS Service Per VPC
For each VPC containing RDS instances that require JIT access:
- An ECS service is deployed in the same VPC, in a private subnet that has network access to the target RDS instances.
- Security groups are configured to allow traffic from the ECS service to the RDS instances (same-VPC traffic, no cross-VPC routing needed).
- The ECS service communicates with Cloudanix’s control plane via outbound HTTPS (through the VPC’s existing NAT Gateway) — no inbound network changes required.
This means:
- No VPC Peering. Each deployment is self-contained within its VPC.
- No CIDR concerns. There’s no routing between VPCs. Each ECS service talks to databases in its own VPC only.
- No Transit Gateway. No shared networking infrastructure is required.
- Standard outbound internet. The only external connectivity is HTTPS outbound to Cloudanix’s API — using the NAT Gateway that’s already configured for each private subnet.
Deployment Process
For this customer’s environment (4 accounts, multiple VPCs), the deployment followed a per-VPC pattern:
- Identify VPCs with databases requiring JIT access.
- Run the infrastructure setup script (provided by Cloudanix) from AWS CloudShell in the target account.
- Provide subnet IDs (private subnets for the ECS service, public subnets for the NAT-accessible load balancer if needed).
- Script creates: ECS service, IAM policy, CloudWatch log group, Secrets Manager configuration, security group rules.
- Verify: IAM database authentication is enabled on target RDS instances. Create required RDS users if needed.
- Test: Raise a JIT request, retrieve credentials, connect to database.
Total deployment time per VPC: 1–2 hours including verification.
What Lives in the Customer’s Account
All JIT DB infrastructure runs in the customer’s AWS account:
| Component | Location | Owned By |
|---|---|---|
| ECS Service (DB proxy) | Customer’s VPC, private subnet | Customer |
| IAM Policy | Customer’s account | Customer |
| CloudWatch Logs | Customer’s account | Customer |
| Secrets Manager secrets | Customer’s account | Customer |
| Security Groups | Customer’s VPC | Customer |
| RDS Instances | Customer’s VPC, private subnet | Customer |
| Cloudanix control plane | Cloudanix infrastructure | Cloudanix |
The customer owns and controls all infrastructure that touches their databases. Cloudanix’s control plane orchestrates the JIT lifecycle (request → approve → credential generation → revocation) but doesn’t have direct network access to the databases. The ECS service in the customer’s VPC is the execution layer.
Scaling to New VPCs
When the company added a new (5th) VPC in a production account for a new customer-facing workload, the same pattern applied:
- Run the setup script in the new VPC.
- Provide the new VPC’s subnet IDs and RDS details.
- Update IAM policy names and CloudWatch log groups to avoid conflicts with existing deployments.
- Verify IAM authentication on the new RDS instances.
- Test end-to-end.
The new VPC was operational for JIT DB within 2 hours. No changes to existing VPC deployments. No cross-VPC routing changes. Each deployment is independent.
Handling Environment-Specific Configurations
Across 4 accounts and multiple VPCs, each environment had slightly different configurations:
- Different IAM policy names per account (to avoid cross-account naming conflicts).
- Different CloudWatch log group names per VPC deployment.
- Different Secrets Manager paths per environment.
- Different security group configurations based on each VPC’s network layout.
The setup script is parameterized for these differences. Hardcoded values from initial deployments are updated for each new VPC, ensuring clean separation between deployments.
What IAM RDS Authentication Means for the Customer
One prerequisite for Cloudanix Database JIT is that IAM Authentication is enabled on the RDS instances. For this customer, IAM Authentication was not previously enabled — the team had not used it before.
Enabling IAM Authentication on RDS:
- Is a non-disruptive change (doesn’t affect existing database connections or credentials).
- Allows database access to be granted via IAM policies rather than static database passwords.
- Is the mechanism Cloudanix uses to generate time-bound credentials that are identity-stamped.
The team enabled IAM Authentication on one database during the initial onboarding session, verified it didn’t impact existing connections, and subsequently enabled it across databases slated for JIT access.
The security team noted that IAM RDS Authentication would require internal Security approval before broader rollout. This is a reasonable governance step — any authentication model change on production databases should go through security review. Cloudanix supported a phased approach: start with development databases (already approved), expand to production after security sign-off.
Platform Impact
| Metric | Value |
|---|---|
| VPCs onboarded | 5 (across 4 accounts) |
| Deployment time per VPC | 1–2 hours |
| Cross-VPC networking required | None |
| VPC Peering required | None |
| CIDR conflict impact | Zero (each deployment is VPC-local) |
| New VPC addition time | ~2 hours (independent of existing deployments) |
| Infrastructure ownership | 100% in customer’s AWS account |
| Cleanup effort (if VPC is decommissioned) | ~1 hour (delete ECS service, IAM policy, log groups) |
Why This Pattern Matters for Enterprise AWS Environments
VPC CIDR conflicts are one of the most common networking constraints in enterprise AWS environments. They’re the result of:
- Multi-team, multi-account growth without centralized network planning.
- Acquisitions that bring accounts with conflicting address spaces.
- Development accounts that used “convenient” CIDR ranges matching production.
Any database access solution that requires cross-VPC connectivity (peering, Transit Gateway, PrivateLink plumbing) will hit this wall in a meaningful percentage of enterprise environments. The per-VPC deployment pattern avoids this entirely — each deployment is self-contained, communicates only within its VPC for database access, and uses standard outbound HTTPS for control plane communication.
For teams evaluating database JIT solutions: if your network architecture has CIDR conflicts, overlapping subnets, or organizational policies against VPC Peering — ask your vendor how their solution deploys. If the answer requires cross-VPC networking, it won’t work in your environment without a network re-architecture project.
Dealing with VPC CIDR Conflicts in Your AWS Environment?
If your AWS environment has VPC CIDR conflicts that make VPC Peering impossible, and you need database JIT access across multiple VPCs and accounts — Cloudanix’s per-VPC deployment model works within your existing network topology without requiring cross-VPC connectivity, Transit Gateway, or network re-architecture.
Book a Free Assessment to discuss deployment in your VPC-constrained environment.
