How do you protect data that lives everywhere?

…By governing it where it resides. 

In a large organisation on AWS, data rarely sits in one place. It is spread across many accounts and held by many different services: transactional databases, application stores, backups, event streams and caches. Each one is a place where the wrong person could reach it. 

At AWS Community Day Bulgaria 2026, Phi’s Principal Cloud Architect, Ivaylo Bahchevanov, explored this challenge in “Data Governance in AWS”: how a data perimeter lets an organisation keep control of distributed data without first moving it. 

He began his session by drawing on real experience of designing a secure zone in the AWS organisation of a large international financial services organisation. 

Why not one central data lake? 

The classic answer to scattered data is to collect it into a central data lake and protect that. In practice, most data never gets there. Transactional systems, backups and live event streams keep running where they are. 

Ivaylo’s starting point was simple to say, but harder to build: govern data where it resides. 

What a data perimeter is 

A data perimeter is a security concept, not a single product or service. It describes a boundary around an organisation’s data: a small set of broad, preventive rules that apply to everyone and are checked before any individual permission comes into play.

It complements least privilege rather than replacing it. Ordinary permissions answer the question “what may this person or application do?” The perimeter answers an earlier one: “should this request be trusted at all?” 

To decide, it checks three things: is the identity one of ours, is the resource one of ours, is the request arriving through an expected network path? If any answer is no, the request is denied, even if a permission elsewhere would have allowed it.

In the session, the concept was put into practice with two types of AWS Organizations policy. Service control policies (SCPs) limit what the organisation’s own users and applications can do. Resource control policies (RCPs) limit who can access the organisation’s resources, even from outside it. 

One perimeter, several secure zones 

The core of the design is a nested structure. One enterprise perimeter, attached at the top of the organisation, covers every AWS account automatically. Inside it, stricter secure zones can be created for parts of the business with tougher requirements. 

In the session’s example, the secure zone protected EU workloads with stronger isolation and data-residency needs. A large organisation could run several zones side by side, for example for EU data, payment data or highly privileged systems. 

Both layers use the same types of policy. What changes is where a policy is attached and which condition it checks: the whole organisation for the outer perimeter, or one branch of it for a zone. An account inside a zone must pass both.

Eight policies, four questions 

Ivaylo walked through the eight policies behind the EU zone. Two sit at the organisation level and protect every account; the other six apply only to the zone. 

Together they answer four practical questions. Who can get in? Only people and applications from the EU zone can reach its storage, encryption keys and secrets, and a separate rule stops AWS services from being tricked into acting for an outsider. Where can the zone go? Only to resources inside the zone, plus a few approved shared accounts. 

Which road must data take? Access to sensitive data must pass through private network endpoints hosted in one dedicated account, a single gate that is easy to audit. And where can workloads run? The organisation is limited to approved AWS Regions, and the EU zone is narrowed further to EU Regions only.

He was clear that the network path is one layer of protection, not a permission in itself. Arriving by the right road grants nothing; the identity and resource rules still decide.

 The exception trap

One of the most practical moments was a trap from the real project. The EU zone still depends on shared services outside it, such as central networking and an image factory that builds standard server images.

The obvious fix is an exception for those shared accounts. But that exception opens the whole account: every service and every action in it. 

The solution is a second, narrower policy for each exception. For the networking account, the zone may only perform the Transit Gateway connection tasks it needs. For the image account, it may only launch servers from approved images. Everything else stays blocked. 

The policies are the easy part 

Ivaylo closed on operations. Writing the policies is the easy part; a data perimeter is something an organisation keeps operating, not something it deploys once. 

Every exception should be treated as a governed object, with an owner, a justification and a review date. An exception that nobody reviews slowly turns a narrow gate into a permanent hole. 

Drift is the other risk. New accounts appear, network ranges change and policies get edited by hand. The perimeter can stop matching reality without a single policy changing, which is why it needs continuous monitoring rather than a check before each audit. 

The principle behind the session was straightforward: keep data where it creates value, draw one clear boundary around it, add stricter zones only where requirements demand it, and keep every exception visible and owned. 

The whitepaper behind the talk is available here.

If your data is spreading faster than your ability to govern it, Phi’s Cloud Practice can help. Get in touch. Contact | Phi Partners