Zero trust in practice: what it actually means on AWS

Zero trust is being sold as a product

If you have attended a cloud security conference in the past three years, you have heard "zero trust" more times than you can count. You have also probably seen it attached to firewalls, identity platforms, network appliances, and access management tools, each promising to deliver it in four easy steps.

Zero trust is not a product. It is a principle: never assume that a request is legitimate because of where it came from. Always verify identity. Always enforce least privilege. Always assume breach.

On AWS, implementing that principle means making specific engineering decisions. Here is what those decisions actually look like.

Identity is the first boundary

Traditional network security works on perimeter assumptions. Once you are inside the VPC, the model trusts you more. Zero trust replaces the perimeter with identity — the question is never "where is this request coming from?" but "who is making this request and what are they allowed to do?"

On AWS this means every workload, every service, every pipeline has its own IAM identity. Workloads do not share roles. Humans do not use shared accounts. No long-lived access keys sit in environment variables or in configuration files.

The identity should be the smallest thing that can do the job. A Lambda function that reads from one S3 bucket has a role that permits reads from one S3 bucket — not a role that permits reads from S3 in general, and certainly not a role that permits writes.

Network segmentation is the second boundary

Zero trust does not mean zero network controls. Network controls are a defence layer — they are just not the primary one.

On AWS this means private subnets for workloads that do not need public access, security groups written as allow-lists rather than block-lists, and VPC endpoints that keep service traffic inside the AWS network without crossing the public internet. It also means flow logs enabled so that unexpected traffic is visible.

The test: from any compromised workload in your VPC, what else answers on the network? If the answer is "most things," the network layer is not doing its job alongside IAM.

Encryption and key management are the third boundary

Data at rest encrypted with a key is only as secure as the key. If the workload holds the key, a compromised workload is a compromised dataset.

On AWS this means separate KMS keys per data classification, with key policies that name which identities may use them. A key policy that permits any IAM principal in the account to use the key is not encryption — it is encryption theatre.

Logging is not optional

Zero trust assumes breach. Assuming breach without logging is hoping you will notice. You will not.

On AWS this means CloudTrail enabled in all regions with immutable log storage, VPC flow logs retained for analysis, and CloudWatch alarms on the things that should never happen: root account login, API calls without MFA, changes to security group rules, public S3 bucket creation.

Logs that go unread are a cost, not a control. The alerting and the alert-response process are as important as the logging.

What zero trust does not require

It does not require a third-party product. Everything described above is available in AWS's native services.

It does not require a year-long programme. The identity hardening work — scoping roles, removing long-lived keys, enabling MFA everywhere — is a sprint, not a project.

It does not require a compliance certification. Zero trust and SOC 2 are complementary but independent. You can have one without the other, and the right sequence depends on your business situation.

If you want to understand where your current AWS posture sits against these principles, our free Well-Architected Review maps it against the framework and hands you the gap list.