Steering APAC Traffic for Acquired AWS Applications
Your company has 3,800 employees and 600 contractors, and it has just absorbed a 400-person subsidiary. The subsidiary's 40 business applications run in AWS in ap-southeast-1, eu-west-1 and us-east-1. Prisma Access is already deployed with GlobalProtect for managed laptops, and all internal applications are reached through two service connections that terminate in Dallas and Frankfurt. Two problems surfaced in the first quarter. First, APAC users of the Singapore-hosted order-management application report 180-260 ms round trips and intermittent session resets, because their traffic crosses the backbone to Dallas and back. Second, 12 legacy applications still authenticate against LDAP with no SAML support, and security refuses to publish them to contractors on unmanaged devices. Those contractors currently use an end-of-life Citrix farm that loses vendor support in six months. Leadership wants a single access architecture, not three parallel ones, and has frozen new VDI spend pending your recommendation.
1. Recommend how to reach the AWS-hosted applications, and justify the choice between additional service connections and ZTNA App Connectors.
Read the worked answer
Diagnose before choosing. 180-260 ms is consistent with APAC to Dallas to ap-southeast-1 - roughly double the one-way distance the application actually needs. The session resets point at idle-timeout or MSS/MTU behaviour on a long-haul stateful path, not at bandwidth. Neither symptom is fixed by buying more throughput.
Recommendation: deploy ZTNA App Connectors into each of the three VPCs rather than extending the service connection model.
Why:
- App Connectors are outbound-only and lightweight; they need no route peering, no address-space negotiation, and no exposure of the VPC CIDR to Prisma Access routing.
- They are scoped to a defined application set, which matches the requirement (40 known apps) rather than a network-to-network relationship.
- Placement inside each region keeps the user-to-app flow short and lets you steer APAC users to the ap-southeast-1 connector instead of transiting the trans-Pacific backbone.
Tradeoffs to state explicitly: connectors introduce a per-connector throughput ceiling and a new failure domain, so deploy them in pairs across availability zones, monitor connector health, and keep the existing service connections for the data centers where you genuinely need broad address space. Before any cutover, check that the acquired subsidiary's RFC1918 ranges do not overlap yours - that is the most common cause of silent black-holing in an acquisition.
2. How would you handle the 12 LDAP-only applications so contractors can use them without weakening authentication?
Read the worked answer
Do not solve this at the network layer. A contractor on an unmanaged device must never be authenticated by where the packet came from.
Split the 12 by what you can change:
- Applications with a web front end that can consume a header or assertion: put an identity-aware reverse proxy in front of them. The proxy terminates SAML against the IdP, enforces MFA there, and passes a signed identity header to the legacy app. This is usually a configuration change on the app, not a rewrite, and it removes LDAP from the contractor path entirely.
- Applications with no web tier or no header support: do not publish them to contractors at all. Rank by data sensitivity and give the affected teams a documented alternative rather than a bypass.
Where the browser becomes the boundary: for the subset contractors truly need, deliver it through a browser-based agentless session with copy/paste and download restrictions. The enforcement point is the browser, because the endpoint is untrusted by definition - that is the architectural point the 300 emergency bypasses already proved.
What I would avoid: publishing LDAP to the internet behind a simple VPN pool, or letting contractors onto the same trust zone as employees to save a project. Both convert an access problem into a credential-stuffing problem, and the Citrix deadline is not a reason to accept that trade.
3. What sequencing risks should you manage during the six-month transition off the Citrix farm?
Read the worked answer
The deadline forces parallelism, which is where these programmes fail. Sequence as follows.
Month 1-2: dependency discovery. Map which of the 40 AWS apps the contractors actually use versus what the asset inventory claims, and which call other services server-side. Connector placement based on a stale diagram is the classic rework driver.
Month 2-3: overlapping addressing and DNS. Confirm the subsidiary's VPC ranges and any split-horizon DNS names that currently resolve differently for employees. Bring the Singapore connector up first - it carries the loudest user pain and gives you a fast, visible win.
Month 3-4: identity front-ending. Deliver the proxy work for LDAP apps in parallel; it has the longest vendor lead time and is the likeliest item to slip past the Citrix end-of-support date.
Month 4-5: cohort migration. Move contractors in groups of roughly 100 by region, keeping Citrix available as a read-only fallback rather than an active parallel path. Instrument connector health, auth failures and session reset rates per cohort before widening.
Month 5-6: decommission gate. Retire Citrix only when the fallback has had zero logins for 14 consecutive days. Track three metrics throughout: authentication failure rate, p95 latency per app per region, and the count of emergency access exceptions - that last number is your real signal, because a rising exception count means the new path still does not fit the work.