Hybrid & Edge Architecture

TL;DR

• Hybrid architectures are frequently framed as temporary migration bridges but often remain structurally permanent — due to legacy systems, regulatory data-residency requirements, or physical-world constraints — and should be designed as first-class, not provisional.
• Hybrid DNS must resolve in both directions: on-prem querying VPC private hosted zones (inbound Resolver endpoint) and VPC querying on-prem domains (outbound Resolver endpoint). Missing either direction produces intermittent failures that look like network problems but are DNS problems.
• Active Directory dependency is usually the real blocker on legacy migrations, not application code; the correct sequencing is to extend AD reachability first, then separately evaluate identity modernization.
• Outposts, VMware Cloud on AWS, and Local Zones solve three genuinely different problems (on-prem native AWS services, VMware estate migration, metro-level low latency) and are not interchangeable.
• Local Zones only help if the workload is physically near one — most facilities (factories, hospitals, branch offices) are not.
• Edge compute (Lambda@Edge, CloudFront Functions) is for lightweight logic at PoPs, not a substitute for real compute — it eliminates round trips to origin for decisions simple enough to make at the edge.

Core Concepts

Hybrid DNS via Route 53 Resolver

Resolution must work bidirectionally. An inbound Resolver endpoint lets on-premises systems query names inside a VPC’s private hosted zones. An outbound Resolver endpoint forwards VPC-originated queries for on-prem domain names to on-prem DNS servers, over Direct Connect or VPN. Missing either direction produces intermittent, hard-to-diagnose connectivity failures that present as network problems but are actually unresolved DNS lookups.

Active Directory integration

AD dependency is typically the real blocker in legacy application migrations, more so than the application code itself. The pragmatic sequencing: extend AD reachability into the VPC first — AD Connector for simpler proxy-based cases, a replica domain controller for heavier authentication load — get the legacy application running against that extended AD, and only then separately plan whether/how to modernize the identity model. Migrating the application and re-architecting authentication in the same step compounds risk without a corresponding benefit.

AWS Outposts

Answers the requirement “native AWS services with low local latency, physically inside a customer datacenter.” Typically driven by data-residency mandates or on-prem processing that must survive a WAN link outage for the data plane — though some control-plane operations still depend on connectivity back to the parent Region.

VMware Cloud on AWS

Answers a different question entirely: “an existing VMware estate (vSphere, NSX, vSAN) needs to move to AWS infrastructure without re-platforming every VM.” It is the faster migration path for VMware-native environments, where Outposts would require rebuilding workloads as native AWS services from the ground up. It functions best as a migration bridge — moving off aging on-prem hardware quickly, then selectively re-platforming individual workloads to native AWS services over time — rather than as a permanent end state.

Local Zones

Relevant when latency-sensitive users cluster in a specific metro that isn’t home to a full Region — media production, ad-tech bidding infrastructure, gaming backends. The binding constraint: Local Zones only help if the workload is physically near one, and most physical facilities (a factory floor, a hospital, a branch office) are not.

Edge computing (Lambda@Edge, CloudFront Functions)

For lightweight logic — header manipulation, auth checks, A/B routing — running at true edge points of presence, of which there are hundreds worldwide. Not a substitute for real compute; a substitute for a round trip to origin for decisions simple enough to make at the edge.

Outposts vs VMware Cloud on AWS vs Local Zones

Inbound vs Outbound Route 53 Resolver Endpoints

Command / Configuration Reference

# Create an inbound Resolver endpoint (on-prem -> VPC resolution)
aws route53resolver create-resolver-endpoint \
  --direction INBOUND \
  --security-group-ids sg-0123456789 \
  --ip-addresses SubnetId=subnet-0123456789

# Create an outbound Resolver endpoint (VPC -> on-prem resolution)
aws route53resolver create-resolver-endpoint \
  --direction OUTBOUND \
  --security-group-ids sg-0123456789 \
  --ip-addresses SubnetId=subnet-0123456789

# Create a forwarding rule for the on-prem domain, associated with the outbound endpoint
aws route53resolver create-resolver-rule \
  --domain-name corp.internal \
  --rule-type FORWARD \
  --resolver-endpoint-id rslvr-out-0123456789 \
  --target-ips Ip=10.0.100.10,Port=53

Common Pitfalls

• Pitfall: Treating hybrid connectivity as a temporary state. Why: Legacy systems, regulatory constraints, or physical-world limitations often make hybrid structurally permanent, but under-investment continues as if it were short-lived. Fix: Design DNS, identity, and connectivity as first-class, permanent architecture components from the start.
• Pitfall: Choosing Outposts when the actual requirement was a faster VMware migration path, or the reverse. Why: The two solve fundamentally different problems — native AWS services on-prem versus VMware estate migration — and the wrong choice means redoing the work later.
• Pitfall: Assuming Local Zones are available near a given facility. Why: Local Zones exist only in specific metros, and most physical facilities (factories, hospitals, branch offices) are not near one. Fix: Confirm Local Zone metro proximity before committing to the design; use Outposts if the facility is not near a Local Zone but needs low local latency.
• Pitfall: Configuring inbound/outbound Resolver endpoints once and never validating them against an actual link failure. Why: DNS resolution failures are intermittent and easy to miss until the hybrid link degrades. Fix: Test both resolution directions explicitly, including under simulated link failure, before declaring hybrid DNS complete.
• Pitfall: Migrating the application and re-architecting authentication in the same step for AD-dependent legacy systems. Why: Coupling two migrations multiplies risk without a corresponding benefit. Fix: Extend AD reachability into the VPC first, get the legacy app running against it, then separately plan identity modernization.

Interview Questions

• “An on-prem application needs to resolve DNS names for VPC resources, and EC2 instances need to resolve the on-prem domain. Design the architecture.” — tests whether bidirectional Resolver endpoint design is understood, not just one direction.
• “A legacy ERP system depends on on-prem AD and can’t be touched for 18 months. Design the hybrid connectivity that lets it keep running while new services build on native AWS.” — tests sequencing judgment, not just knowledge of the services involved.
• “Explain when VMware Cloud on AWS is preferable to a native re-platform to EC2/ECS, and what the exit strategy looks like.” — tests whether it’s understood as a migration bridge rather than a permanent destination.
• “A factory floor needs sub-10ms local processing but also needs to sync results back to a Region. What’s the right placement?” — tests whether Outposts is correctly distinguished from Local Zones based on physical proximity constraints.
• “Walk through what breaks on an Outposts rack if the link to the parent Region goes down for six hours, and what doesn’t.” — tests genuine operational understanding of the control-plane/data-plane split versus surface-level familiarity.