What Enterprise AWS Security Actually Looks Like
The previous four posts describe a complete hardening program for one person's AWS account: root, identity, blast radius, and the long tail, with an explicit skip list and a total cost of a couple of dollars a month. This fifth post starts where that model fails.
Calling the solo program complete is accurate, but it can leave the wrong impression: that a bank runs the same program at greater scale. Enterprise AWS security differs in kind. It solves problems that do not exist at one account, with controls that would be absurd there and people whose full-time job is to operate them. The distinction matters in both directions. A solo control does not belong in an enterprise design review, and an enterprise control is rarely sensible advice for a side project.
Everything below is grounded in AWS's own Security Reference Architecture, the SRA, which is the closest thing to a canonical answer AWS publishes. Where I describe a structure, that structure is prescribed there rather than invented here.
The AWS Security Reference Architecture - AWS Prescriptive Guidance
High-level diagram and description of AWS security-related services within AWS Organizations.
docs.aws.amazon.com/prescriptive-guidance/latest/security...The account stops being the thing you protect#
The whole solo program treats the account as the perimeter. Everything happens inside it, so hardening means making that one container safe.
The SRA inverts this. The account becomes the unit of blast radius, and the organization structure becomes the thing you design. A Security organizational unit holds a Log Archive account and a Security Tooling account. An Infrastructure OU holds networking and shared services. Workloads live in their own OU, split by environment. AWS's multi-account whitepaper treats these foundational OUs as the starting point, not an advanced topic.
When a solo developer hits an isolation problem, the instinct is to write a tighter IAM policy. In an enterprise, the answer is often another account. Accounts are free, disposable, and the only boundary AWS enforces without requiring you to write a policy. A team that needs a hard separation gets an account, not a more elaborate policy.
That reframing invalidates a specific piece of advice from earlier in this series. Part four argued that creating an organization for a single account is low value, because service control policies never apply to the management account, so your guardrails would not cover your workloads. That reasoning is correct at one account and completely backwards at fifty, where an empty management account and workloads in members is the entire point.
You do not administer your own security services#
In the solo account you enabled GuardDuty, watched the console cost estimate, and decided at day thirty whether to keep it. That decision does not exist in an enterprise, because the account owner is not the one making it.
The SRA nominates the Security Tooling account as the delegated administrator for the organization's security services: the organization CloudTrail trail, AWS Config, Security Hub CSPM, and GuardDuty. GuardDuty is enabled across every account through Organizations, and findings are viewable and actionable by the security team in that delegated administrator account. The Log Archive account is the delegated administrator for Security Lake.
The logs leave the account that produced them#
Part two hardened the CloudTrail trail with log-file validation, bucket versioning, and a lifecycle rule. Those are good controls for a trail you own, and they share a weakness the post could not fix: you own the trail, so you can destroy it. Validation proves tampering after the fact; it does not prevent an administrator from deleting the bucket.
The SRA solves this structurally. The organization trail publishes to a centralized S3 bucket hosted in the Log Archive account, which is a different account with different administrators. The person who can delete resources in a workload account cannot reach the record of having done so.
A validated trail is tamper-evident. A trail stored under separate administration is tamper-resistant. At one account you can only buy the first, which is not enough when the audit question is "who can delete this bucket?"
Guardrails stop being one-off policies and get an objective#
The region-deny policy in part three is a real guardrail with real carve-outs, and it is one policy solving one problem. Enterprises pursue something broader, with a name: a data perimeter.
The goal is stated as three conditions that must all hold: only trusted identities, accessing only trusted resources, from expected networks. What makes it an architecture rather than a slogan is that each condition maps onto a specific policy type. Service control policies constrain what your principals can do, so they carry the "my identities reach only trusted resources from expected networks" half. Resource control policies constrain what can be done to your resources, so they carry "my resources are reachable only by trusted identities from expected networks." VPC endpoint policies carry the network leg. The aws:PrincipalOrgID condition key is what makes "trusted" mean something checkable.
Establishing a data perimeter on AWS: Overview | Amazon Web Services
August 28, 2025: This post has been updated to reflect the usage of the aws:VpceOrgID condition key to scale your network perimeter implementation. November 13, 2024: This post has been updated with guidance on how to use resource control policies (RCPs) and the aws:SourceOrgID condition key to establish your organization’s data perimeter. November 23, 2022: […]
aws.amazon.com/blogs/security/establishing-a-data-perimet...AWS documents the implementation in a dedicated whitepaper, with separate write-ups for the identity, resource, and network legs, and folds the whole thing into IAM's permissions guardrails guidance.
The solo series mentioned RCPs only in passing. In a data perimeter, SCPs and RCPs are two halves of one control objective. Using only one leaves a documented gap, not a partial win.
Somebody built the environment before your team arrived#
Every account in the solo series was configured by hand, in order, by the person who owned it. That is a reasonable way to configure one account and an impossible way to configure two hundred.
AWS's guidance is unambiguous about the sequence: start with Control Tower as the foundational landing zone, then extend it with the Landing Zone Accelerator where you have highly regulated workloads or compliance frameworks Control Tower does not cover on its own. They are complementary, not alternatives, and AWS recommends Control Tower first in every region where it is supported. The landing zone guidance treats networking, access management, and security strategy as decisions you still own, with the landing zone as the mechanism that applies them consistently.
In an enterprise, a hand-configured account is an incident, not a milestone. New accounts arrive with the baseline already applied, and controls detect drift from it. The satisfying part of the solo series, working through a checklist and finishing it, is precisely what does not scale.
Detection becomes a system, not an email#
The root sign-in alert in part one works because exactly one person ever signs in, so any alert is either you or an incident. That property disappears immediately at scale. Email is not a detection channel when the volume exceeds what one person reads.
This corner of AWS also changed shape recently, and it is worth getting the names right. In October 2025 the existing posture-management service was renamed AWS Security Hub CSPM, and a new AWS Security Hub went generally available alongside it. They are different products. CSPM continues as the posture and finding-aggregation service built on the AWS Security Finding Format. The new Security Hub correlates and prioritizes signals across GuardDuty, Inspector, Security Hub CSPM, and Macie, and uses the Open Cybersecurity Schema Framework instead.
AWS Security Hub now generally available with near real-time analytics and risk prioritization | Amazon Web Services
Today, AWS Security Hub is generally available, transforming how security teams identify and respond to critical security risks across their AWS environments. These new capabilities were first announced in preview at AWS re:Inforce 2025. Security Hub prioritizes your critical security issues and unifies your security operations to help you respond at scale by correlating and […]
aws.amazon.com/blogs/aws/aws-security-hub-now-generally-a...A finding is not an alert, and an alert is not a response. The solo series could collapse all three into one email because there was one recipient and one likely action. An enterprise separates signal generation, correlation, prioritization, and response, then staffs the last one around the clock.
The network comes back#
Part three told you to delete your default VPCs, on the grounds that an unused VPC is just a launch pad. Perfectly good advice, and it quietly assumes the account has no network worth defending.
Reverse that assumption and a whole discipline reappears. The network leg of the data perimeter runs on VPC endpoint policies, which only mean something if traffic is actually routed through endpoints you control. Private connectivity, centralized egress inspection, and a network account that exists solely to own that topology are all standard in the SRA's Infrastructure OU, and none of them have an analogue in an account whose entire network footprint is a hosted zone.
"I deleted my VPCs" and "our egress is inspected and our endpoints are policy-controlled" answer completely different questions. The first removes an unused launch path. It says nothing about network security once workloads have a network.
Cost stops being the thing that decides#
This is the largest inference error available, so it is worth being blunt about it.
The skip list in part four is a set of cost judgments. Defer Config because it bills on activity and can turn a small bill into a larger one. Skip the unused-access analyzer because it charges per role and you have one. Skip Security Hub because its pricing model assumes more resources than you have. Every one of those is economically correct at a single account with one IAM user, and every one of them inverts once the same reasoning runs across a large organization. Config's timeline stops being redundant with CloudTrail the moment you need to answer a compliance question about a resource that no longer exists. Unused-access analysis stops being pointless the moment there are thousands of roles nobody remembers granting.
The direction of the tradeoff flips too. In the solo account, cost is the constraint and security is the thing you buy with the money left over. In an enterprise, the compliance obligation is the constraint and cost is a line item with an owner, a forecast, and a team that negotiates it. "It is not worth the money" stops being an available argument for a control that a framework requires.
Never carry a skip recommendation across the scale boundary. The reasoning may travel; the conclusion does not.
What actually does transfer#
Not everything is different, and the parts that survive are worth naming precisely, because they are the parts you can say out loud in either room.
The threat model survives unchanged. Credentials in a leaked commit get abused within minutes whether the account belongs to a hobbyist or a bank, and the attackers monetizing them do not check first. Phishing-resistant MFA protects the most privileged identity at both scales, although the enterprise version is centralized root access management across member accounts rather than a security key in a desk drawer.
So does the goal of eliminating long-lived credentials. The solo answer was Identity Center with a built-in store plus OIDC for CI. The enterprise answer is Identity Center federated to a corporate IdP, with lifecycle managed by joiners-movers-leavers. The plumbing changes; the failure is identical if a static key survives somewhere.
Break-glass discipline gets stricter rather than disappearing. In the solo series it is a documented identity excluded from your own guardrails. In an enterprise it is documented, approval-gated, alarmed on use, and reviewed afterwards. At both scales, guardrails need a deliberate exit that cannot be reached accidentally.
Tagging grows teeth. The solo version provides cost attribution for a hosted zone. The enterprise version uses organization-wide tag policies to enforce keys and values, drive chargeback, and route ownership.
The honest summary#
The four posts before this one form a complete (question mark?) program for a small account. Some controls overlap with enterprise, but the operating model does not apply. A solo account is one person applying a checklist and finishing. An enterprise relies on standing structures: separate accounts for logs and tooling, delegated administration, a data perimeter with an explicit objective, a landing zone that provisions the baseline, and on-call response to correlated findings. No individual's diligence is supposed to be load-bearing.
If you want to go deeper than this overview, the SRA's best-practices checklist is the densest single page AWS publishes on the subject, its phased approach is the answer to "where do we start", and the SRA code repository turns the diagrams into something deployable.
The distance between the previous post and this one is not a list of remaining tasks - it is a different job.
Originally published at https://iuriio.com/blog/posts/2026/08/aws-hardening-enterprise-scale
