Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Technology / AI SaaS |
| Cloud Environment | AWS (4 accounts, multiple VPCs per account) |
| New VPC Details | Created 1 week prior, us-west-2, AI Production account |
| Existing JIT DB | 4 VPCs already onboarded across accounts |
| Database Type | RDS (IAM Authentication already enabled) |
| Setup Method | Infrastructure script from AWS CloudShell |
| Time to Operational | ~2 hours including verification |
| Impact on Existing VPCs | Zero (independent deployments) |
| Cloudanix Scope | Database JIT — new VPC addition to existing deployment |
The Situation: A New Workload, A New VPC, Same Day Database JIT
When this AI SaaS company launched a new customer-facing AI workload, infrastructure spun up quickly: new VPC in us-west-2, new RDS instances, new EKS cluster. The production account already had Cloudanix Database JIT running across 4 VPCs. The question was simple: how quickly can the 5th VPC get the same database JIT access as the others?
The answer: 2 hours, with zero impact on existing deployments.
This wasn’t a greenfield installation — it was an addition to an existing JIT DB deployment. The team needed to confirm that:
- The new VPC’s JIT DB infrastructure was independent of existing VPCs (no cross-contamination).
- Existing VPC deployments continued functioning normally during and after setup.
- Developers could request access to databases in the new VPC using the same workflow they already knew.
- The end-to-end flow worked: request → approve → credentials → connect → query → revoke.
The Core Challenge
Adding Database JIT to a new VPC in an environment where 4 VPCs are already running JIT DB. The new deployment must be independent (no impact on existing VPCs), fast (the workload is live and developers need access today), and consistent (same developer experience as the other 4 VPCs).
The Onboarding Process: Step by Step
Prerequisites Verified
Before running the setup, the team confirmed:
- VPC ID identified for the new us-west-2 VPC.
- RDS instances in the VPC with IAM database authentication already enabled (the team had adopted this as standard practice after initial onboarding months earlier).
- Required RDS users already existed on the database instances.
- Subnet IDs for private subnets (where the ECS service would deploy) and public subnets (for NAT-accessible networking).
- Security groups / CIDR correctly configured to allow traffic from the ECS service to RDS instances.
Infrastructure Setup
The team ran the existing setup script from AWS CloudShell in the production account:
-
Provided parameters: VPC ID, private subnet IDs, public subnet IDs, RDS endpoint details.
-
Script created:
- ECS service (the DB proxy component) in a private subnet.
- IAM policy with permissions scoped to the new VPC’s RDS instances.
- CloudWatch log group for operational monitoring.
- Secrets Manager configuration for Cloudanix control plane communication.
- Security group rules allowing ECS → RDS traffic within the VPC.
-
Environment-specific adjustments:
- Different IAM policy names (to avoid conflicts with policies in other VPCs).
- Different CloudWatch log group names (per-VPC naming convention).
- Updated Secret Manager paths for the new deployment.
- Fixed hardcoded values in the script that referenced the original VPC deployment.
-
Cleanup and retry: Initial run hit a CloudWatch log group naming conflict (leftover from a previous test). Cleaned up the log group, reran the script successfully.
Validation
After infrastructure setup, the team validated end-to-end:
- Downloaded latest CLI configuration (user-specific, now includes the new VPC’s databases).
- Raised a JIT request through the Cloudanix Console for a database in the new VPC.
- Approved the request.
- Retrieved temporary database credentials via the CLI.
- Connected to the database using the generated credentials.
- Confirmed access worked — queries executed successfully.
- Verified revocation — credentials invalidated after session expiry.
Total time from start to validated, working JIT DB access: approximately 2 hours.
What Makes This Repeatable
Each VPC Deployment Is Independent
The architecture principle that enables same-day VPC additions: each JIT DB deployment is self-contained within its VPC.
VPC 1 (Dev) VPC 2 (Prod-1) VPC 3 (Prod-2) VPC 4 (Prod-3) VPC 5 (AI Prod) ← NEW
├─ ECS Service ├─ ECS Service ├─ ECS Service ├─ ECS Service ├─ ECS Service
├─ IAM Policy ├─ IAM Policy ├─ IAM Policy ├─ IAM Policy ├─ IAM Policy
├─ CW Log Group ├─ CW Log Group ├─ CW Log Group ├─ CW Log Group ├─ CW Log Group
├─ Secrets ├─ Secrets ├─ Secrets ├─ Secrets ├─ Secrets
└─ SG Rules └─ SG Rules └─ SG Rules └─ SG Rules └─ SG RulesNo shared state between VPCs. No cross-VPC dependencies. Adding VPC 5 doesn’t touch VPCs 1–4. Removing VPC 5 (if the workload is decommissioned) doesn’t affect anything else.
Per-User CLI Configuration
One operational detail: when a new VPC is added, users need to download their updated CLI configuration. The configuration is user-specific (contains their identity context) and now includes the new VPC’s databases as requestable targets.
This is a one-time action per user after each VPC addition — download the new config file, and the new databases appear as options in their JIT request flow.
Consistent Developer Experience
For the 80+ developers who already use JIT DB daily across 4 VPCs, the 5th VPC is invisible in terms of workflow:
- Same CLI command (
cdx db connect). - Same request flow (select database, request access, get approved).
- Same IDE connection (localhost + credentials from CLI).
- Same audit trail (identity-stamped, time-bound, auto-revoked).
They don’t need to learn anything new. They just have additional databases available to request access to.
The Broader Pattern: Infrastructure That Scales by Addition
As this company grows — acquiring new customers that need dedicated infrastructure, launching new product lines on separate VPCs, expanding into new AWS regions — the JIT DB architecture scales by addition:
| Event | JIT DB Action | Time | Impact on Existing |
|---|---|---|---|
| New customer VPC created | Run setup script in new VPC | ~2 hours | Zero |
| New region expansion | Deploy ECS in new region’s VPC | ~2 hours | Zero |
| Customer VPC decommissioned | Remove ECS + IAM + logs | ~1 hour | Zero |
| New database added to existing VPC | Add RDS endpoint to configuration | Minutes | Zero |
| New account onboarded | Setup per-VPC in new account | ~2 hours per VPC | Zero |
Each addition is atomic. Each removal is clean. The total deployment complexity grows linearly with VPCs, not exponentially.
What About the EKS Cluster in the New VPC?
The team also needed EKS JIT for a new staging cluster in the same VPC. During the onboarding session, the cluster wasn’t yet visible in the Cloudanix Console because:
- An Identity Center / account refresh was initiated during the call.
- The sync process takes 2–3 hours for new resources to appear.
- EKS JIT follows a different onboarding path than Database JIT (role-based access through IAM Identity Center rather than credential-based access through the DB proxy).
The team was advised that once the sync completed, the new EKS cluster would appear as a requestable target in the Kubernetes JIT workflow. No additional infrastructure setup was needed for EKS JIT — it operates through the existing IAM Identity Center integration.
Platform Impact
| Metric | Value |
|---|---|
| Time to add new VPC (JIT DB) | ~2 hours |
| Impact on existing 4 VPC deployments | Zero |
| Developer workflow change | None (download updated CLI config) |
| Infrastructure per VPC | ECS service + IAM policy + logs + secrets |
| Cross-VPC dependencies | None |
| Total VPCs with JIT DB | 5 (across 4 accounts) |
| Cleanup time per VPC (if decommissioned) | ~1 hour |
Growing Your JIT DB Footprint Across VPCs?
If your infrastructure is expanding — new customer workloads, new regions, new product lines each getting their own VPC — and you need database JIT access to scale with that growth without architectural overhead, Cloudanix Database JIT deploys per-VPC in ~2 hours with zero impact on existing deployments. Each addition is independent, each removal is clean, and the developer experience stays consistent regardless of how many VPCs exist.
Book a Free Assessment to discuss JIT DB deployment across your multi-VPC environment.
Related Resources
- JIT DB Onboarding in VPC-Constrained Environments: Avoiding CIDR Conflicts
- From EKS Tunneling and socat to Cloudanix Database JIT
- The End of Permanent Access: Just-In-Time Granular Database Security
- JIT Database Access: Replacing HashiCorp Vault Temporary Tokens
- What is Database Activity Monitoring (DAM)?
