Four Clouds, One Compliance Boundary

When I joined the engagements with AndBank, Santander, and LATAM Airlines at everis, the brief sounded like a single sentence: isolate the workloads that touch PII, control what talks to what, and be able to prove it. In practice that sentence had to be translated four times, because the clients' infrastructure spanned GCP, AWS, Azure, and OCI, and none of those four platforms agree on what a network boundary is made of. A VPC in GCP is a global resource with regional subnets. A VPC in AWS is regional by default, with peering and transit gateways doing the work GCP gives you for free. Azure's VNets carry their own service endpoint and private link model. OCI, still newer to most architects at the time, had its own take on security lists and network security groups layered on top of a topology that borrowed from all three of the others without matching any of them exactly. Compliance doesn't care about any of that. It just asks whether cardholder data or personal information can reach somewhere it shouldn't. The architecture has to answer that question consistently, even when the underlying primitives don't.

The actual work started with mapping, not building. Before any subnet got drawn, I had to establish which workloads handled PII at all, because sensitive data is not self-declaring in a running system: it hides in log pipelines, in caching layers, in batch jobs that pull a nightly extract for reconciliation. Once that inventory existed, the segmentation question became simpler to state and harder to solve: put every PII-handling workload behind a boundary where east-west traffic is default-deny, and make every exception to that default an explicit, auditable rule rather than an accident of a permissive security group. On AWS that meant security groups scoped tightly enough that a compromised instance in the general application tier had no route to the tier holding customer records. On GCP it meant VPC Service Controls and firewall rules built around service accounts rather than IP ranges, since IP-based trust breaks down fast in an autoscaling environment. On Azure it meant NSGs paired with subnet delegation so that PaaS services didn't quietly get a default path into the same address space as everything else. On OCI it meant learning, sometimes the hard way, which of its network security constructs mapped to concepts I already trusted, and which just looked like them.

The harder problem was never any single cloud's controls. It was translation. A compliance boundary defined once, for a banking regulator or an aviation security standard, has to be mapped onto four different enforcement surfaces so that the statement 'PII workloads are isolated' means the same thing everywhere an auditor might look. I ended up keeping a boundary map that was independent of any provider: which workloads are in scope, what they are allowed to talk to, what they are never allowed to talk to, and then a per-cloud translation layer underneath it showing exactly which security group, firewall rule, or NSG enforced each line. Without that separation, the temptation is to let the architecture drift toward whichever cloud's model is easiest to reason about, and quietly under-segment the others to match. That drift is invisible until an audit or an incident makes it visible, and by then it is a finding, not a design conversation.

IAM made this harder still, because network segmentation and identity segmentation are supposed to reinforce each other, and across four clouds they don't share a vocabulary either. A network boundary that is airtight but paired with an identity model that lets a service account or app registration reach across it accomplishes nothing: the perimeter is fine and the actual control has moved elsewhere. Part of the design was making sure the IAM boundary and the network boundary were drawn around the same set of workloads on every platform, not just conceptually similar sets. That required going platform by platform and asking the same question with no shortcuts: given this identity's actual permissions, not its intended permissions, can it reach a PII-handling resource it shouldn't. GCP service accounts, AWS IAM roles, Azure managed identities, and OCI dynamic groups all needed that same audit, and none of the answers transferred cleanly from one cloud to the next.

What stayed with me from that engagement is that multi-cloud segmentation is not a networking problem that happens to touch compliance. It is a compliance problem that happens to require four separate networking implementations. The regulator's boundary is the constant. The VPC, the VNet, and whatever OCI calls its equivalent are just the current vocabulary for expressing it, and that vocabulary will keep changing as providers add new primitives. The discipline that survives a platform migration is keeping the compliance boundary defined once, in provider-neutral terms, and treating every cloud-specific control as a translation of it that can be checked, not a policy in its own right.