Northwind Capital: Compute Location Placement and a Fixed-Egress Trading Platform
Northwind Capital runs Prisma Access for 6,500 mobile users - roughly 3,000 in the Americas, 2,400 in EMEA and 1,100 in APAC - plus 55 branches onboarded as remote networks. Every mobile user is currently assigned to the New York compute location; from there a service connection reaches the London data centre, which hosts the trading platform and the permit-to-work system. Two problems have surfaced. First, APAC users measure 280–320 ms round trip to Microsoft 365 and Salesforce against an internal target of 40 ms, and the security team refuses to back-haul branch traffic into a data centre. Second, the trading platform's allowlist accepts only a small set of source IPs and the platform owner will not widen it. Peak aggregate mobile-user throughput is 3.2 Gbps against a 4 Gbps licence. The CFO has asked for a design that survives the loss of any single compute location without a change freeze.
1. Recommend where compute locations should be placed and how mobile users should be assigned to them. Justify the design on latency and licensing grounds, and state what you would verify before committing.
Read the worked answer
Reasoning
Latency in this design has two legs: user device to compute location, and compute location to the SaaS edge. Tuning cannot shorten either leg - only placement can. A user in Singapore pinned to New York pays roughly 200 ms of pure geography before any inspection happens, which explains the 280–320 ms measurements.
Placement
Stand up compute locations adjacent to the three user populations and to the SaaS edges those populations hit:
- Americas: a US East location as primary; add US West if the Americas population is geographically split.
- EMEA: a continental location plus a UK location, since the London data centre already pulls EMEA traffic.
- APAC: Singapore as primary, Sydney for Australian users.
The target is that each user's round trip to the nearest location stays under roughly 25–30 ms, leaving budget for the egress leg.
Assignment
Mobile users should select their gateway on measured latency among the locations you allow. Do not pin users with a fixed gateway list, and do not chain them through an explicit proxy that funnels them to a distant location. Confirm that GlobalProtect app configurations and any split-tunnel or proxy settings are not overriding gateway selection.
Verify before committing
- Which locations are actually available in the tenant and whether the SaaS providers peer near them.
- Measured, not assumed, RTT per user region per candidate location from connection logs and Insights.
- Per-location bandwidth licensing - the 4 Gbps is not a single pool you can spend anywhere.
- Contractual residency constraints on where traffic may egress.
2. Design the source-IP story for the London trading platform. Explain why the mobile-user public IPs cannot simply be allowlisted, and compare the realistic options.
Read the worked answer
Why the default egress does not work
Internet-bound mobile-user traffic is translated to a pool of public addresses associated with the compute location. Those addresses are shared and are not a stable contractual anchor: they can differ per compute location, so a user who re-homes after a failure presents a different source, and you have no guarantee the platform owner will keep trusting the full range forever. Asking the vendor to allowlist the pool is possible only if you obtain dedicated mobile-user public IPs and accept that each location has its own set.
Option A - dedicated public IPs for mobile users
Palo Alto assigns dedicated egress addresses to the tenant. Pros: works for every SaaS that needs an allowlist, no hairpin through the data centre. Cons: addresses are per location, consumption is finite, and there is a commercial cost. Only choose this if the platform will accept several addresses.
Option B - force platform traffic through the London service connection with source NAT
A security rule steers the platform's destinations over the SC, and NAT translates mobile-user sources to a public address Northwind already owns at the London edge. Pros: exactly the IP the platform already trusts; traffic is going to London anyway; a second SC pair gives redundancy. Cons: all platform traffic now depends on service-connection bandwidth and health, so size the SC and add NAT on both edge devices.
Recommendation
Option B for the trading platform, with a narrow rule keyed to the platform's destinations and application, not a blanket route. Keep general internet traffic on the default egress. Confirm symmetric return paths across both SC tunnels.
3. The licence is 4 Gbps and measured peak is 3.2 Gbps. Explain how you would validate that this is sufficient, and describe what happens to capacity when a compute location is lost.
Read the worked answer
Validate the number first
3.2 Gbps is only meaningful with a method attached. Pull 30 days of per-compute-location bandwidth from Insights, not a tenant-wide average, and look at the 95th percentile and the five busiest minutes rather than the mean. Check how concurrency was derived: 6,500 licensed users does not mean 6,500 concurrent sessions, and per-user throughput assumptions for M365 and Salesforce are often understated during month-end or trading peaks. Encryption overhead means the encrypted throughput you see is what consumes the licence.
The trap in a single aggregate figure
Bandwidth is consumed and limited per compute location. A tenant sitting at 80 per cent overall can still have one location pinned at 100 per cent and shedding traffic, while a lightly used region shows plenty of headroom. Validate region by region: Americas, EMEA and APAC peaks separately.
Failure behaviour
When a location becomes unavailable, its users re-home to the next nearest location they are permitted to use. The survivor must carry its own population plus the displaced one. If Singapore normally carries 0.8 Gbps and a failure pushes another 0.9 Gbps at it, the survivor needs to be licensed and licensed-adjacent for roughly 1.7 Gbps, not 1.0. Note also that failover without warning means the capacity event happens at the worst possible moment.
Recommendation
Size n+1 within the region containing the largest population, keep at least 30 per cent headroom on each location's licensed ceiling, and alert on per-location utilisation at 70 per cent so the shortfall is found before the outage does. Verify that service connections terminate in the same region as the compute location, or a failover also breaks data-centre reachability.