Project Name
4 AWS Accounts Unified Under One VPN With SSO in Under 3 Weeks
The client is a mid-market AdTech and eCommerce analytics SaaS platform headquartered in North America, serving major consumer brands and retailers across the region.
Their platform processes high-volume shopper engagement data, enabling brands to measure and optimise media-to-commerce performance in real time. The engineering team operates a multi-account AWS environment spanning production, staging, QA, and development workloads.
Rapid growth in data volume and engineering headcount had outpaced the original VPN architecture, creating an urgent need to modernise secure remote access without disrupting active development cycles or ongoing sprint commitments.
The engineering team wasn't struggling with one networking problem; they were managing six, simultaneously, across four isolated AWS accounts.
- Non-Standard OpenVPN Configuration: The existing OpenVPN setup used a non-standard configuration that lacked native AWS integration, making it incompatible with AWS-managed networking features and increasingly difficult to maintain, extend, or audit as the environment grew.
- No Cross-Account Private Access: Developers could only VPN into one AWS account at a time. Reaching private resources in staging, QA, or dev required a full disconnect, profile swap, and reconnect, adding an estimated 10 to 15 minutes to every cross-environment task.
- Manual VPC Peering and Routing: Inter-account connectivity relied on point-to-point VPC peering with manually maintained route tables. Every new account or VPC addition required hands-on network reconfiguration with no automated path.
- No Single Sign-On Integration: VPN authentication was decoupled from the corporate identity provider. Engineers managed separate, locally maintained credentials for VPN access, creating credential sprawl and leaving audit gaps across all four accounts.
- Security and Compliance Gaps: No centralised access logging or identity-based policies meant the security team had no unified view of who accessed which account, when, and from where, a compliance exposure that was growing with every new engineer onboarded.
- Operational Overhead on the Infrastructure Team: Every onboarding, offboarding, or access change required manual VPN credential provisioning and route updates, consuming infrastructure team bandwidth that should have been spent elsewhere.
Ksolves, an AI-first DevOps consulting company, designed and executed a full migration from the legacy OpenVPN setup to AWS Client VPN with SAML 2.0-based SSO, unified through AWS Transit Gateway for hub-and-spoke routing across all four AWS accounts. The governing principle was simple: one client, one identity, every environment.
- AWS Client VPN Endpoint: Provisioned and configured an AWS Client VPN endpoint with mutual certificate authentication and SAML 2.0 federation, replacing the legacy OpenVPN appliance entirely and enabling native AWS integration from day one.
- AWS Transit Gateway Hub-and-Spoke Architecture: Deployed Transit Gateway as the central routing hub, attaching all four account VPCs, including production, staging, QA, and development, to a single transit network. Point-to-point VPC peering and manual route table management were eliminated entirely.
- SSO Integration via IAM Identity Centre: Integrated AWS Client VPN with the client's identity provider through IAM Identity Centre and SAML 2.0, enabling engineers to authenticate once with their corporate credentials and reach every environment from a single persistent VPN session.
- Authorisation Rules and Network Segmentation: Configured per-account authorisation rules on the Client VPN endpoint, enforcing least-privilege access per user group. Engineers access only the environments their role permits, with all sessions centrally logged in CloudWatch.
- Zero-Downtime Cutover: Executed a parallel-run migration where AWS Client VPN operated alongside the legacy OpenVPN for a validation window before cutting over all users. There’s no service interruption, no lost connectivity, no impact to active sprints.
Technology Stack
| Category | Technology |
|---|---|
| Networking | AWS Client VPN |
| Networking | AWS Transit Gateway |
| Security | IAM Identity Centre + SAML 2.0 |
| Infrastructure | Multi-Account VPC Architecture |
| Observability | Amazon CloudWatch |
Four VPN profiles, four credential sets, and four isolated access models collapsed into one connection, one login, and one audit trail.
- VPN Profiles Reduced From 4 to 1: A single AWS Client VPN profile now provides access to all four accounts through Transit Gateway, eliminating per-account VPN management and the daily profile-switching overhead that came with it.
- Developer Context-Switch Time Cut by ~80%: All environments are reachable within one persistent VPN session, reducing cross-account access time from an estimated 10 to 15 minutes per switch to under 2 minutes, giving engineering teams back hours every week.
- Credential Sprawl Eliminated With SSO: SAML 2.0 SSO via IAM Identity Centre provides single-credential authentication with centralised session logging across 100% of environments, closing the audit gaps that existed across all four accounts.
- Manual Route Management Reduced to Zero: Transit Gateway hub-and-spoke routing handles all inter-account connectivity automatically. New VPCs are onboarded in minutes with no manual peering configuration or route table updates required.
- Zero-Downtime Migration Completed in Under 3 Weeks: A parallel-run cutover strategy ensured zero minutes of developer downtime during the full migration. Active sprints across four engineering teams were never interrupted.
Four AWS accounts, four VPN profiles, four credential sets, and no centralised audit trail, replaced in under three weeks. Every context switch that once cost 15 minutes now happens inside a single persistent session. Every login is now a corporate credential, every connection is logged, and every access decision is governed by least-privilege rules. Ksolves, an AI-first DevOps consulting company, didn’t just fix the VPN; it gave the engineering team an access model that scales cleanly with headcount, satisfies compliance requirements, and absorbs new environments without reconfiguration.
Struggling with Fragmented VPN Access Across Multiple AWS Accounts?
