Inside a production AWS organisation: an AWS aligned security reference architecture

Most AWS diagrams show what exists. They rarely show how a request moves through it, or why each control sits where it does. So we built a full multi-account design as a walkable model and filmed it. The video takes just under seven minutes and captions every component as the camera reaches it. This post covers the same ground in writing, and adds what the design achieves and the principles behind it.

This is Nuvrix’s AWS aligned security reference architecture to demonstrate a production ready environment for a typical company with the workloads, networking and third-party tooling they tend to need.

What the design achieves for your business

The design lets teams keep shipping on AWS while a small central team stays in control of security and recovery. In practice, that gives you:

• Problems that stay contained. A mistake or security issue in one team’s account doesn’t spread to the others by default, and Prod stays apart from Dev and QA.
• New teams that start safely and quickly. A new account inherits the guardrails, shared identity and approved images, so nobody waits on a security review of the basics.
• A clear view for a small IT team. Security findings, performance and connectivity come together in one place, with one incident queue.
• Evidence when someone asks for it. Logs that can’t be altered show who did what and when, which supports audits and investigations. The design supports compliance work, and it doesn’t replace it.
• A way back after something goes wrong. Locked backups sit apart from the workloads, and a second Region is ready to restore into.
• A safer route for AI. Generative AI workloads use the same foundation, with private connectivity and guardrails on every model call.
• Less duplicated work. Identity, pipelines and inspection are run once and shared, so each team doesn’t build its own version.

The design principles, and why they matter

Seven principles explain most of the decisions you’ll see in the film. They’re what we hold on to when a design has to change for a particular customer.

Isolate with accounts

Each workload and environment gets its own AWS account. Accounts are the strongest boundary AWS offers, so this limits how far any single problem can reach. It also makes costs and ownership easier to see.

Set guardrails centrally, and let teams deliver

Rules are set once at the OU level and inherited by every account below. Security stays consistent without a central team becoming the queue that every change waits in.

Layer the controls

A request passes edge rules, firewalls, network policies and IAM permissions on its way to the data. No single control has to be perfect, because a gap in one layer is still covered by the next.

Grant the least privilege

Each Lambda function has its own role, each Kubernetes workload gets only the permissions it needs, and third-party tools get read-only access scoped to what they use. If a credential ends up in the wrong hands, what it can reach is small.

Keep it private, with controlled paths

Workloads have no public entry, and there is one way in and one way out. Private connections replace internet routes where the service supports them. Fewer paths are easier to monitor and to explain to an auditor, and where a path is an exception, as the serverless API is, it carries its own controls.

Protect the record, and separate the duties

Logs and backups live in their own accounts, locked against change, away from the people running the workloads. You’re relying on them on your worst day, so they have to be trustworthy even if another account isn’t.

Build it in modules, from templates

Every environment comes from the same templates, so what passes in QA behaves the same way in Prod. Each capability is also a separate module that can be added, replaced or left out, which is what makes the design customisable.

A walk through the design

The rest of this post follows the film, part by part.

Accounts are the walls of the building

In the film each organizational unit (OU) is a wing and each AWS account is a room. That is close to how the isolation works: an account is the strongest boundary AWS gives you, so a problem in one team’s account stays there by default.

AWS Control Tower and AWS Organizations apply guardrails down through the OUs, so a new account starts with the same rules as the others. Service control policies and resource control policies set limits no account can exceed, and root access is centralised. People sign in through AWS IAM Identity Center, and access to the management account stays tightly limited.

One front door, and a firewall on every path

Inbound traffic follows one route. Cloudflare handles DNS and DDoS protection at the outer edge. Amazon CloudFront, AWS WAF and AWS Shield Advanced come next, then a public Application Load Balancer in a central Ingress VPC. Workload VPCs have no public entry of their own, so edge rules are applied and logged in one place.

From there AWS Transit Gateway sends the request to an Inspection VPC, where Palo Alto Networks VM-Series firewalls run across two Availability Zones behind a Gateway Load Balancer. Transit Gateway appliance mode keeps both directions of a flow on the same firewall, which stateful inspection depends on. Panorama holds the policy centrally.

The same firewalls see the other directions as well. Transit Gateway route tables send VPC-to-VPC traffic to inspection first, and separate route tables keep Prod and SDLC apart. Outbound traffic is inspected, then leaves through NAT gateways in one Egress VPC, which gives you a single exit to monitor. Traffic to Amazon Simple Storage Service (Amazon S3) and Amazon DynamoDB stays on gateway endpoints in each VPC.

Four workload types, each with its own controls

A single set of rules doesn’t fit every workload, so the film stops at four.

• Servers on Amazon Elastic Compute Cloud (Amazon EC2). An internal load balancer feeds Auto Scaling groups across two Availability Zones, with Amazon Aurora behind them. IMDSv2 is required, engineers connect through AWS Systems Manager Session Manager rather than SSH, and Amazon Inspector scans the fleet.
• Containers on Amazon Elastic Kubernetes Service (Amazon EKS). The cluster endpoint is private and worker nodes sit in private subnets. Network policies separate namespaces, EKS Pod Identity scopes each workload’s AWS permissions, and images come from a central Amazon Elastic Container Registry (Amazon ECR).
• Serverless APIs. Amazon API Gateway calls AWS Lambda functions, with one IAM role per function. This is the one path that doesn’t cross the firewalls: it comes through Amazon CloudFront and AWS WAF instead of the VPC, so sign-in through Amazon Cognito and narrow roles carry more of the weight.
• Generative AI on Amazon Bedrock. The application reaches the service through an interface VPC endpoint on AWS PrivateLink, not the internet. Amazon Bedrock Guardrails check requests and responses, including removing PII. Amazon Bedrock doesn’t share your data with model providers or use it to train foundation models.

Dev and QA sit behind each production account, in a separate SDLC OU. They are built from the same templates at smaller sizes and take no production dependencies. The Sandbox has no Transit Gateway attachment at all.

Connections to the outside world

Third-party APIs get two routes. Where a partner offers AWS PrivateLink, as the payment processor does in the film, the traffic never crosses the internet. Other APIs go out through the firewalls and the Egress VPC, limited to approved destinations over TLS, with keys held in AWS Secrets Manager.

The data centre also has two paths. AWS Direct Connect is the primary link, through a Direct Connect gateway to Transit Gateway, and a Site-to-Site VPN stands by. BGP preference keeps traffic on Direct Connect and moves it to the VPN if the link fails, which the film simulates. AWS publishes this pattern as a reference. Traffic from on-premises goes through the firewalls on either path.

Seeing all of it from one room

Security Tooling is the delegated administrator for AWS Security Hub, Amazon GuardDuty, Amazon Inspector and Amazon Macie. Log Archive receives the organization trail and network logs on Amazon S3 with Object Lock. Keeping those in two accounts means the people who run the tools can’t alter the record.

The third-party tools then read from that foundation rather than replacing it. Microsoft Sentinel reads logs from the Log Archive bucket, with Amazon SQS announcing each new file and a narrowly scoped IAM role limiting it to that bucket and queue. Wiz connects at organisation level through a read-only cross-account role with nothing installed on workloads. Datadog or New Relic, depending on what the company runs, takes traces, metrics and logs from agents and extensions in each workload.

All of those feeds, along with Amazon CloudWatch, come together in the operations command centre, with a single incident queue for the teams on shift. Operators can see everything, and they change production only through the normal pipelines.

Backups kept out of reach

AWS Backup copies recovery points into a logically air-gapped vault, which is immutable and locked by default. Veeam Backup for AWS can run alongside it, keeping its copies under Amazon S3 Object Lock. A Disaster Recovery account in a second Region restores directly from the shared vault.

Customised to your requirements, and built to grow

Nuvrix’s AWS aligned security reference architecture is customisable to your requirements. Its modular structure means you adopt the components you need today and extend the design as your requirements change. A company with a small IT team shouldn’t try to build the whole model at once, and doesn’t have to.

We usually start with the account structure and guardrails, then central logging, because both get harder to change once workloads are running. Central inspection comes when you have enough VPCs to justify it. The command centre can begin as one shared dashboard.

From there, the design changes with the business:

• Workloads. Keep only the patterns you run. A new business unit gets its own set of accounts from the same templates, and a new workload type attaches to the same hub.
• Tools. The third-party products in the film are examples of each category. If you already run a different firewall, SIEM, posture or monitoring tool, it can take the same place in the design, and AWS services can fill those roles too.
• Connectivity. With no data centre, the Direct Connect and VPN module drops out. If you need more resilience later, it can be added without reworking the accounts.
• Edge and ingress. A public load balancer in a central VPC is one of several valid patterns, and many companies would use Cloudflare or Amazon CloudFront rather than both.
• Structure. OU names and groupings, such as the Resilience OU, are ours and can follow how your organisation works.
• Compliance and recovery. New obligations can be applied as policies at the OU level, and backup scope and second-Region recovery can grow to match what the business needs.

Every module adds running cost and something else to operate, so each one should earn its place. Bring your account structure to a call and we’ll tell you what we’d do first.