Hybrid Network Connectivity To AWS

1. Situation

A company has three AWS VPCs and one data center:

• a production VPC;
• a development VPC;
• a shared-services VPC containing directory and management systems; and
• on-premises databases that will remain during a phased migration.

Production must reach selected on-premises services. Developers need shared services but must not reach production databases. On-premises users need private AWS DNS names to resolve. The network must survive a path failure.

Beginners often hear “connect the data center to AWS” as one problem. It is at least five:

physical path -> routing -> segmentation -> DNS -> failure recovery

• Connectivity provides a path for packets.
• Routing tells packets where to go and how to return.
• Segmentation decides which networks may have a route to which destinations.
• DNS translates names across the AWS and on-premises environments.
• Security controls decide whether reachable traffic is actually allowed.

2. Naive Design

Naive option 1: connect everything to everything

flowchart LR
  A["VPC A"] <--> B["VPC B"]
  A <--> C["VPC C"]
  B <--> C
  DC["Data center"] <--> A
  DC <--> B
  DC <--> C

As VPC count grows, point-to-point connections, routes, owners, and failure paths multiply. VPC peering is not transitive, so VPC A cannot automatically act as a routing bridge between B and C.

Naive option 2: “The VPN is up, so networking is done”

The tunnel is established, but the VPC route table lacks the on-premises CIDR, the data-center router lacks the VPC CIDR, or a security group blocks the port. Tunnel health proves only part of the path.

Naive option 3: reuse the same CIDR everywhere

The data center and a VPC both use 10.20.0.0/16. A router cannot choose which identical destination is intended without address translation or redesign.

Naive option 4: allow every attached network to communicate

A central hub simplifies connectivity, but one broad route table turns development, production, and partners into one large trust zone.

3. What Breaks

Follow one request from an EC2 instance to an on-premises database:

1. The instance sends a packet to the database IP.
2. Its subnet route table has no matching on-premises route, so the packet never reaches the hybrid connection.
3. After that route is added, Transit Gateway sends the packet to the wrong attachment because its route table is misassociated.
4. After the forward path is fixed, the data-center router does not know the VPC CIDR, so the response cannot return.
5. After routing works, the application uses db.corp.internal, but AWS DNS has no forwarding rule for that domain.
6. After DNS works, the database firewall still denies the VPC source range.

This explains an essential networking principle:

A working path requires forward routing, return routing, name resolution when names are used, and permission at every control point.

4. AWS Architecture

Build the network from the smallest requirement.

Step 1: plan non-overlapping addresses

Before connections exist, allocate CIDRs centrally:

on premises       10.0.0.0/12
production VPC    10.32.0.0/16
development VPC   10.33.0.0/16
shared VPC        10.34.0.0/16

The exact ranges are examples. The rule is that networks that must route directly should not overlap.

When overlap already exists, options such as renumbering, NAT, proxies, or service-specific private access can help, but they add operational complexity. Address planning is cheaper than repairing collision later.

Step 2: connect one VPC quickly with Site-to-Site VPN

For a first hybrid path, use an AWS Site-to-Site VPN:

flowchart LR
  DC["Customer gateway device<br/>in data center"] ==>|"Two IPsec tunnels<br/>over internet"| VGW["Virtual private gateway"]
  VGW --> VPC["One VPC"]

The customer gateway device is the physical or software router on the company side. The AWS customer gateway resource describes it. The AWS-side target can be a virtual private gateway for one VPC or a Transit Gateway for a hub design.

Each Site-to-Site VPN connection includes two tunnels with different AWS endpoints. Configure both; a second tunnel that the customer router ignores is not useful redundancy.

VPN is the usual signal when the requirement emphasizes:

• encrypted IPsec connectivity;
• internet transport;
• relatively fast setup; or
• a temporary or backup hybrid path.

Step 3: choose Direct Connect for a sustained private path

If the company needs more predictable network behavior, high sustained throughput, or private dedicated connectivity, add AWS Direct Connect:

flowchart LR
  DC["Company router"] --> Provider["Carrier / colocation path"]
  Provider --> DX["AWS Direct Connect location"]
  DX --> AWS["AWS network and gateway path"]

Direct Connect establishes private connectivity from the customer environment to AWS through a Direct Connect location. It takes planning and often provider coordination, so it is not usually the fastest emergency setup.

Private does not mean encrypted by default. Direct Connect traffic is not encrypted in transit by the service automatically. Use TLS at the application layer, an IPsec VPN over Direct Connect, or supported MACsec options when encryption requirements call for them.

VPN and Direct Connect are not mutually exclusive. A common pattern uses Direct Connect as the primary path and VPN as backup, subject to tested routing preference and capacity.

Step 4: add Transit Gateway when the connection count grows

Three VPCs and the data center need a hub:

flowchart LR
  Prod["Production VPC"] --> TGW["AWS Transit Gateway<br/>Regional routing hub"]
  Dev["Development VPC"] --> TGW
  Shared["Shared-services VPC"] --> TGW
  DC["Data center<br/>VPN or DX path"] --> TGW

Each connected network uses an attachment. Transit Gateway supports attachment types such as VPC and VPN, and can connect to Direct Connect through the appropriate Direct Connect gateway and transit virtual-interface design.

Transit Gateway is a managed Regional transit hub. It replaces a large peering mesh, but it does not automatically authorize all traffic and it does not remove VPC route tables.

For only two VPCs that need direct private connectivity, VPC peering may be simpler and cheaper. Transit Gateway becomes valuable when centralized, transitive routing and segmentation justify the hub.

Step 5: understand the two routing decisions

An EC2 packet crosses two main routing layers:

flowchart LR
  EC2["EC2 instance"] --> VPCRT["VPC subnet route table<br/>on-prem CIDR -> TGW"]
  VPCRT --> TGWRT["TGW route table<br/>on-prem CIDR -> hybrid attachment"]
  TGWRT --> Hybrid["VPN or Direct Connect path"]
  Hybrid --> Corp["On-premises router<br/>VPC CIDR -> AWS"]

1. The VPC subnet route table selects the Transit Gateway attachment.
2. The Transit Gateway route table selects the next attachment.

The return path needs corresponding routes in the data center and AWS.

Routes can be configured statically or learned dynamically. BGP (Border Gateway Protocol) exchanges route information between network devices. BGP can adapt to path changes, but it does not replace security policy or prove the application endpoint is healthy.

Step 6: segment with Transit Gateway route tables

An attachment is associated with one Transit Gateway route table for routing traffic arriving from that attachment. Routes from attachments can be propagated into selected route tables, or routes can be configured deliberately.

Use that control to create different routing domains:

flowchart LR
  Prod["Production attachment"] --> ProdRT["Production TGW route table"]
  Dev["Development attachment"] --> DevRT["Development TGW route table"]
  Shared["Shared attachment"] --> SharedRT["Shared-services TGW route table"]
  ProdRT --> Shared
  ProdRT --> OnPrem["Approved on-prem routes"]
  DevRT --> Shared
  DevRT -.->|"No production route"| Prod

• Association answers: “Which TGW route table evaluates traffic arriving from this attachment?”
• Propagation answers: “Which route tables learn routes for destinations behind this attachment?”

Routing segmentation removes paths that should not exist. Security groups, NACLs, host firewalls, and application authentication still enforce access along paths that do exist.

Step 7: connect the two DNS worlds

Private connectivity by IP does not automatically make private names resolvable.

flowchart LR
  CorpDNS["On-premises DNS"] -->|"AWS private domain queries"| Inbound["Route 53 Resolver<br/>inbound endpoint"]
  Inbound --> AWSNames["Private hosted zones<br/>and VPC DNS"]
  AWSWorkload["AWS workload"] --> Outbound["Route 53 Resolver<br/>outbound endpoint + rule"]
  Outbound -->|"corp.internal queries"| CorpDNS

• An inbound Resolver endpoint receives DNS queries coming from on premises into the VPC Resolver.
• An outbound Resolver endpoint sends selected VPC DNS queries to on-premises DNS servers according to forwarding rules.

The endpoint names describe query direction relative to AWS. Use endpoints across multiple Availability Zones and ensure routes, security groups, and on-premises firewalls allow the DNS traffic.

Step 8: add centralized inspection only when required

If policy requires inter-VPC or hybrid traffic inspection, route selected traffic through an inspection VPC with AWS Network Firewall or supported appliances.

flowchart LR
  Source["Source attachment"] --> TGW["Transit Gateway"]
  TGW --> Inspect["Inspection VPC<br/>firewall endpoints"]
  Inspect --> Destination["Destination attachment"]

Stateful firewalls expect a consistent path. Design symmetric routing so both directions of a flow traverse the correct inspection endpoint. Central inspection adds hops, cost, route complexity, and another failure domain; it is a policy decision, not a decoration.

Step 9: remove single-path dependencies

For production hybrid connectivity:

• configure both tunnels of each VPN connection;
• use redundant customer gateway devices where required;
• consider multiple VPN connections for device/site resilience;
• design Direct Connect redundancy across connections and locations according to the availability requirement;
• provide a tested backup path with enough capacity; and
• verify routing preference and convergence during failure.

Redundant diagrams are not enough. Failure exercises must show that traffic actually moves and returns.

Completed architecture

flowchart LR
  OnPrem["On-premises network"] ==>|"Direct Connect primary<br/>VPN backup"| TGW["Transit Gateway"]
  TGW --> ProdRT["Production routes"]
  TGW --> DevRT["Development routes"]
  TGW --> SharedRT["Shared-services routes"]
  ProdRT --> Prod["Production VPC"]
  DevRT --> Dev["Development VPC"]
  SharedRT --> Shared["Shared-services VPC"]
  DevRT -.->|"No route to production"| Prod
  Resolver["Route 53 Resolver<br/>inbound + outbound"] <--> OnPremDNS["Corporate DNS"]
  Resolver <--> Shared
  Inspect["Optional inspection VPC"] -.-> TGW

5. Request Or Data Flow

Learn three flows.

Flow 1: production EC2 reaches an on-premises database

1. The application resolves the database name through an outbound Resolver rule if it uses corporate DNS.
2. The EC2 instance sends the packet to the resolved on-premises address.
3. The subnet route table targets Transit Gateway for that CIDR.
4. The production-associated TGW route table selects the hybrid attachment.
5. BGP-learned or static routing sends the packet across Direct Connect or VPN.
6. On-premises routing delivers it to the database.
7. Firewalls and the database authorize the connection.
8. The response follows a valid return route to the production VPC.

Flow 2: on-premises user resolves an AWS private name

1. The user's query reaches corporate DNS.
2. A conditional forwarder recognizes the AWS private domain.
3. It sends the query over hybrid connectivity to the Resolver inbound endpoint.
4. The VPC Resolver evaluates the private hosted zone and returns the answer.
5. The client then needs a valid network route and permission to reach that address.

DNS resolution proves a name maps to an address; it does not create network reachability.

Flow 3: Direct Connect becomes unavailable

1. Monitoring detects the path or BGP session failure.
2. The router withdraws or stops preferring the Direct Connect routes according to design.
3. Routes converge toward the VPN backup.
4. Both VPN tunnels and the customer device must be configured and healthy.
5. Monitoring checks packet loss, latency, application errors, and backup-path saturation.

If the VPN cannot carry essential production traffic, it is a diagram backup rather than a recovery path.

6. Security Controls

Minimize routes before filtering packets

Do not propagate every route everywhere. Remove unnecessary reachability through TGW route-table segmentation, then use security groups, NACLs, Network Firewall, host controls, and application authentication for the permitted paths.

Protect routing and DNS administration

Routes, BGP configuration, Resolver rules, and shared attachments can change a large blast radius. Use least privilege, change review, CloudTrail, AWS Config where suitable, and clear ownership.

Match encryption to the path

Site-to-Site VPN supplies IPsec encryption. Direct Connect supplies private connectivity but not default in-transit encryption. Apply TLS, VPN over Direct Connect, or supported MACsec from the actual data classification and compliance requirement.

Log useful evidence

Use VPC Flow Logs, Network Firewall or appliance logs, VPN and Direct Connect metrics, DNS query logging where appropriate, and configuration-change auditing. Flow Logs show accepted or rejected network-flow metadata; they do not replace application logs or packet payload inspection.

7. Resilience Controls

Monitor:

• VPN tunnel state and bytes;
• Direct Connect connection and virtual-interface state;
• BGP session state and route changes;
• Transit Gateway attachment health and route-table changes;
• packet loss, latency, and throughput on each path;
• Resolver endpoint health and DNS query failures;
• firewall endpoint health and dropped flows; and
• application success across the hybrid dependency.

Build redundancy at both ends. Two AWS VPN tunnels can still share one failed customer router. Two Direct Connect links can still share one building or provider path.

Test maintenance and unplanned failure scenarios. Record convergence time and confirm that existing sessions, DNS, stateful firewalls, and application retries behave acceptably.

8. Performance Controls

VPN performance depends on tunnel configuration, customer device capacity, encryption, packet size, internet conditions, and AWS service limits. Direct Connect provides more predictable private connectivity, but the complete path still includes customer and provider infrastructure.

Avoid unnecessary hairpinning. Sending a packet through Transit Gateway, a centralized firewall, an on-premises appliance, and back to AWS can add latency and multiple data-processing charges.

Stateful inspection needs symmetric routing. Asymmetric return paths can make a healthy network look like an intermittent application failure.

DNS latency is application latency when every connection waits for hybrid forwarding. Make Resolver endpoints resilient and monitor the on-premises DNS servers they depend on.

Use service-specific VPC endpoints when AWS service traffic can remain inside AWS instead of traversing NAT or on-premises paths unnecessarily.

9. Cost Controls

VPC peering may be simpler for a small number of VPCs. Transit Gateway reduces operational mesh complexity but adds its own charges.

Use detailed cost and usage data to find Transit Gateway processing, NAT, firewall, Direct Connect, and regional data-transfer surprises. Architecture diagrams should show cost-bearing hops, not only logical trust zones.

10. Exam Variants

11. Common Traps

• Do not treat connectivity, routing, DNS, and authorization as the same control.
• Do not use VPC peering as a transitive enterprise hub.
• Do not attach every network to one TGW route table without considering segmentation.
• Do not forget the return route.
• Do not design direct routing between overlapping CIDRs and expect longest-prefix rules to identify intent.
• Do not configure only one VPN tunnel.
• Do not mistake two AWS tunnels for two customer devices or sites.
• Do not say Direct Connect encrypts traffic by default.
• Do not reverse Resolver endpoint direction: inbound means queries enter AWS; outbound means queries leave toward another DNS system.
• Do not route stateful inspection asymmetrically.
• Do not assume a backup path has enough capacity without testing it.

Final Mental Model: One-Minute Review

flowchart LR
  DC["Data center"] ==>|"VPN or Direct Connect"| TGW["Transit Gateway"]
  TGW -->|"Segmented routes"| Prod["Production VPC"]
  TGW -->|"Segmented routes"| Dev["Development VPC"]
  TGW -->|"Segmented routes"| Shared["Shared-services VPC"]
  DNS["Route 53 Resolver<br/>inbound + outbound"] <--> DC
  DNS <--> Shared

If you remember only one sentence, remember this:

The connection provides a path; route tables choose the destination; DNS finds the address; security decides whether the conversation is allowed.

12. Related Topics

Deepen the individual mechanics with AWS Transit Gateway, AWS Direct Connect, AWS Site-to-Site VPN, VPC Networking Model, Route 53 Resolver Private DNS Patterns, and AWS Network Firewall.

Official AWS references:

• What is AWS Transit Gateway?
• What is AWS Site-to-Site VPN?
• Encryption in AWS Direct Connect
• Route 53 Resolver inbound and outbound endpoint considerations