Shared VPN Tunnel and Shared AD in AWS

Shared VPN Tunnel

Use Cases

This approach eliminates the need to create VPN connections for additional VPCs because all required on-premises resources will be accessed either directly or indirectly through the shared services VPC.

The required on-premises resources are easy to replicate or proxy (e.g., Active Directory)

Strong security or compliance programs require additional application-level controls and proxy servers between their AWS and on-premises resources (e.g., application-layer firewalls)

Shared Services VPC (AD, HA Proxy, NGinx, DNS, ELBs, Database Replicas) – Anything that can be Replicated

This design pattern connects multiple spoke VPCs to a shared services VPC in the same region using VPC peering, and provides access to remote resources in these VPCs through replicated services and application proxy services.

The shared services VPC, in turn, connects to on-premises resources using a standard, dynamically routed AWS VPN connection established with a VGW.

Commonly replicated services include infrastructure services such as Active Directory, DNS, and load-balancing services, but they can also include application services such as database replicas or developer source-control, build, and deployment tools. Common application proxies include standard web-reverse proxies such as HAProxy, Nginx, or Apache mod_proxy, but they can also include load balancer virtual IP addresses and SOCKS proxies.

Transit VPC Only with Auto Recovery for EC2-based VPN Instances (no shared services)

• IMPORTANT: This design uses VPN connections, rather than VPC peering, to connect to the transit VPC because VPC peering does not support transitive routing.
• The best practice for making this transit network highly available and scalable is to use dynamically routed VPN connections.
• Additionally, AWS highly recommends the use of Auto Recovery for EC2 or Auto Scaling for automatic recovery of failed EC2-based VPN instances.

 

 

 

Shared Services and Transit VPC together