Direct Connect in China — private hybrid, not public web

AWS Direct Connect–style private interconnect is for hybrid networks — not for “making the website work in China.” The same category includes Azure ExpressRoute, Google Cloud Interconnect, and China-cloud dedicated attachments: use them when Mainland China systems and overseas systems must exchange private traffic with steadier latency than the public internet. Keep customer-facing HTTP on an explicit public China path. Without a traffic matrix, real China cloud accounts, and circuit ownership, the private link never becomes operable.

Preconditions

Missing any of these stops DIY long before the first LOA.

Precondition	Why DIY stalls
Written traffic matrix (app, src/dst CIDR, ports, direction, peak BW, fail mode)	Without it, you buy bandwidth for undefined flows
China cloud / DC endpoints locked (actual Mainland China account + region)	Global region toggles do not create China attachments
Cross-border / partner circuit path quoted with LOA ownership	Cloud interconnect ports and carrier segments are different tickets
Public vs private split agreed with stakeholders	Marketing “acceleration” expectations poison the design
Security + ownership model (allowlists, incident commander)	Circuits die in ticket ping-pong without a named owner

Chinese-language cloud consoles, joint-venture China cloud accounts (AWS China, Azure China, and peers), and carrier lead times measured in weeks are part of this floor. Your team usually cannot stand up a production hybrid path from overseas click-paths alone — calendar time and LOA ownership are prerequisites, not afterthoughts.

Core path

Step	Decision	Done when
1. Purpose	Replication, admin, partner API, data pipeline — not public web	Written traffic matrix
2. Endpoints	Which China VPC/DC and which overseas VPC/DC	Account + region locked
3. Provider path	AWS Direct Connect / ExpressRoute / Cloud Interconnect (or China-cloud peer) + cross-border / partner circuit if needed	Quote and LOA path clear
4. Routing	Advertise only private CIDRs; no default-route surprises	Route tables reviewed
5. Security	Firewall zones, reverse path; identity still required	Allowlist + deny-by-default
6. Failover	Second circuit or documented degraded mode	Tested failure drill
7. Ops	Latency/loss monitors on the path	Paging thresholds set

Legitimate uses: data sync between a Mainland China processing environment and an overseas analytics plane; secure admin or deployment channels; partner datacenter adjacency into a China cloud VPC; hybrid ERP-style private flows.

Explicit non-goals: bypassing URL filtering for general browsing; replacing ICP-aligned public hosting for customers; “tunnel the whole SaaS” through one private pipe without a public architecture.

Classify each matrix row as (1) must be private, (2) can be public HTTPS with strong auth, or (3) should not cross the border. Direct Connect helps class (1) only. Lead times are weeks, not hours — do not put interconnect on the critical path of a marketing launch without a parallel public plan.

Compressed build sequence once preconditions exist: freeze the matrix → choose the cloud-native interconnect that matches each side (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, or the China-cloud equivalent) and add carrier/partner cross-border when regions require it → bring up links in a staging VRF/VPC → turn on monitoring before production cutover → document who owns circuit tickets at 2 a.m. Ship handoff artifacts with the link: route diagrams, prefix lists, circuit IDs, cloud attachment IDs, and dashboards. Advertise only private CIDRs (no surprise default route); VIFs / private attachments must match the traffic matrix, not “whatever the wizard created.”

Linked reasoning

No traffic matrix → wrong SKU and endless change orders. If a flow cannot be described (ports, sensitivity, fail mode), it should not ride the private link yet.

Public and private conflated → category error. Private interconnect does not replace Mainland China CDN, hosting, or ICP for browser users. Stakeholders need two bold boxes: Public China ingress and Private hybrid interconnect.

China cloud account wrong → attachment never lands. Interconnect planning must use the actual Mainland China cloud account operated under local joint-venture models — not a global region toggle.

Default route or broad advertisement → accidental hairpin. A mistaken 0.0.0.0/0 sucks public traffic into the private path and becomes a nightmare to debug.

Single circuit, no drill → sharper outage. Cross-border segments fail. Without a second path or graceful degrade, you bought downtime with better latency on good days.

Network diagram without data counsel → compliance surprise. Private connectivity does not erase data-localization or security assessment duties when data crosses borders.

Difficulty and blockers

• Sales “Direct Connect = China acceleration” — engineers inherit impossible website KPIs; separate SKUs and success metrics.
• MTU / MSS and mysterious timeouts — test with real payloads before cutover.
• Bandwidth upgrades are not instant — over-provision the launch path or stage traffic.
• Overusing interconnect for developer convenience — if the need is Hub/npm for engineers in China, fix registries and mirrors; do not aim production Direct Connect at that problem.
• No out-of-band path — a routing mistake without a jump host locks you out of your own hybrid link.
• Private ≠ trusted — keep SSO/mTLS/service identity; segment so a compromised China jump host cannot scan the global VPC.
• Cloud port green, carrier red (or reverse) — both tickets must clear; celebrating one side creates false launch readiness.
• Illustrative matrix rows that belong: DB replica China VPC → overseas analytics; overseas CI → China K8s API (allowlisted); partner file drop → China landing VPC. Reject “all employee internet egress” — that is a proxy/VPN problem.

Pre-production tests: throughput and latency with production-like payloads; failover by disabling the primary circuit; application timeouts under loss; DNS/service discovery if you use private hosted zones; runbook execution by a secondary on-call who did not build the link.

What “done” means: artifacts above plus a recorded failover drill. Without them, the link becomes lore. Interconnect is expensive relative to a marketing CDN and cheap relative to a week of hybrid outage — fund it from reliability outcomes, not “make the website faster.”

China landing partner

Most product teams need a China landing partner to clear China cloud onboarding, carrier LOAs, Chinese-language consoles, and the public-vs-private architecture split Your team still owns the traffic matrix and security model; the partner path makes circuit and account rails executable when those rails are not already in-house.

What we can offer?

Direct Connect–style paths help private hybrid traffic between overseas systems and Mainland China — they do not fix public websites. Chinaready helps you scope the private matrix correctly and keep internet ingress as a separate design:

1. China Readiness Assessment — Separate public China ingress from private CIDR / interconnect needs, and decide whether a Direct Connect–class path belongs on the roadmap at all.
2. China Access Acceleration — Design customer-facing Mainland China paths (edge, origin, deps) so private interconnect is never asked to fake a website or SaaS access fix.
3. China Product Hosting — Place the China-side workloads that actually terminate in Mainland China so hybrid endpoints are real for admin, sync, or backend traffic.
4. Mobile App Distribution — Keep public app/API hostnames distinct from private admin or sync paths so store-facing journeys stay on the public China design.

Contact us when hybrid latency is real and you need the private path designed without pretending it replaces China edge architecture.