Why this matters
AWS Organizations gives you one place to manage many accounts. Without organization-wide guardrails, each account owner picks their own defaults. One public bucket or one unused admin key can undo a good design. Guardrails are the rules that still hold when someone is in a hurry.
Preventive controls stop an action before it happens. Service control policies are the main preventive tool in AWS Organizations. Detective controls find drift after the fact, through AWS Config rules, Security Hub findings, and Amazon GuardDuty. You need both. Preventive controls alone can block a release. Detective controls alone depend on someone reading the queue.
Guardrails also make new accounts safe by default. When an account is created through AWS Control Tower Account Factory or your own pipeline, it should land in the right organizational unit with the baseline already attached. That is cheaper than cleaning up an account six months later.
Before you start
Start with AWS Organizations set to all features, not consolidated billing only. Sign in to the management account with a role and MFA, not the root user. Name one owner for the guardrail set, usually a platform or security team, and write down how a team requests an exception. You will need that process on day two, not month six.
Inventory your accounts, regions, and workloads. Note that service control policies do not apply to the management account, so keep workloads out of it. Check for service-linked roles that need to create resources. Pick a pilot organizational unit with non-critical accounts. Do not test a new deny policy on production.
Choose your baseline. A practical set includes a short root SCP, OU-level SCPs, an organization trail, AWS Config rules, GuardDuty, Security Hub, backup policies, and tag policies. AWS Control Tower can set up much of this for you. If you already have Organizations, you can add controls without moving every account at once. Decide what your break-glass access looks like before you deny anything.
How to do it
Work from the top down, but roll out in waves. The root SCP should protect the organization itself: no account leaves, no one turns off the log archive, no one deletes the trail. OU-level SCPs then add limits for production, sandbox, and regulated workloads. Keep the policy text small enough that a new engineer can read it in one sitting.
Add detective controls next, and make them visible where engineers already work. A Security Hub finding that lands in a ticket queue gets fixed. A finding in a console nobody opens does not. Use AWS Config conformance packs to apply the same rules across every account in an OU, and use tag policies to make ownership and cost reporting reliable.
Test every guardrail in a sandbox account. Try the action the guardrail is meant to stop. Check the error message and the CloudTrail event. Then test the exception path. A guardrail without a tested exception path will be removed the first time it blocks a release.
- Enable all features in AWS Organizations. In the AWS Organizations console, choose Settings and enable all features. This is required before you can use service control policies, backup policies, and tag policies. Confirm the management account has MFA on the root user and that day-to-day work uses a role.
- Build a small OU tree. Create organizational units by control need, not by team chart. A common start is Security, Infrastructure, Production, and Sandbox. Put accounts that need the same deny list in the same OU, and leave room to add a regulated OU later.
- Attach a short SCP at the root. Write one SCP that denies organizations:LeaveOrganization, cloudtrail:StopLogging, cloudtrail:DeleteTrail, and deletion of the log archive bucket. Attach it to the root. Keep the default FullAWSAccess policy attached so you do not accidentally remove all permissions.
- Add OU-level SCPs for production. For production, use the ec2:Encrypted condition key to block unencrypted volumes on RunInstances. Deny actions that disable GuardDuty, AWS Config, and Security Hub. Test each statement in a pilot OU first.
- Turn on an organization trail and log archive. Create an organization trail in the management account and send its logs to a dedicated log archive account. Restrict access so only the security team can read or delete the bucket. This gives you one record of denied API calls across every account.
- Deploy AWS Config rules to every OU. Use an organization aggregator and a conformance pack in the delegated administrator account. Start with S3_BUCKET_PUBLIC_READ_PROHIBITED, ENCRYPTED_VOLUMES, IAM_ROOT_ACCESS_KEY_CHECK, and MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS. Assign an owner to each noncompliant resource.
- Turn on GuardDuty and Security Hub with a delegated admin. Designate a security account as the delegated administrator for GuardDuty and Security Hub. Enable the AWS Foundational Security Best Practices standard. Send high-severity findings to your ticketing system and set a review cadence.
- Apply tag and backup policies. Create a tag policy that requires Environment, Owner, and DataClass on resources that support tags. Create a backup policy that applies a daily backup plan to production accounts. Attach both policies to the OUs, not to individual accounts.
- Test in a sandbox before wider rollout. In a sandbox account, try to stop the trail, delete a Config recorder, and create a public S3 bucket. Confirm the SCP denies the action and that AWS Config records the resource if it appears. Then repeat the test in one production account during a change window.
How to check it worked
Open AWS Config in the delegated administrator account and filter compliance by OU. Check that each rule has recorded resources. A rule that shows no resources may be misconfigured, not clean. Do the same in Security Hub, filtering findings by account and by control.
Run a denied action in a sandbox account and read the error. For an SCP, the error should say the request was denied by an organization policy. Then open CloudTrail and find the event. You want a record of the attempt, even though the action failed.
Create a new test account through Account Factory or your account pipeline. Confirm it lands in the intended OU, inherits the SCPs, has a Config recorder, and shows up in GuardDuty and Security Hub. Check for drift if you use Control Tower. A baseline that only works on old accounts is not a guardrail.
Mistakes to avoid
The most common mistake is expecting SCPs to control the management account. They do not. Another is treating an SCP as a grant: it only filters permissions, and removing the default FullAWSAccess policy without an allow list locks everyone out. Keep a tested break-glass role and use it only for recovery.
Do not write one giant deny rule. A broad deny on iam:* or s3:* breaks backups, logging, and deployments in ways you will not predict. Deny the exact actions that remove visibility or create public exposure, then use AWS Config and Security Hub to catch the rest.
Do not skip the pilot or the exception process. A guardrail that blocks a release at 2 a.m. gets removed, and then you have no guardrail. Put exceptions in a separate OU or behind a role condition, give them an owner and an end date, and review them on a schedule.
If you want an outside read before you lock things down, the Cloud security review from Cloudverg is $6,500/month, fixed scope, and it reviews up to 5 cloud accounts read-only. It is one option among others.
Frequently asked questions
Do SCPs apply to the AWS Organizations management account?
No. SCPs apply to member accounts, not the management account. Keep workloads out of the management account and protect it with MFA and a small break-glass role. Use it for billing and organization tasks only.
Should I use AWS Control Tower or build guardrails with SCPs?
Control Tower gives you a landing zone, Account Factory, and managed controls, which is faster for many teams. Building directly with Organizations, SCPs, and AWS Config gives you more control but more work. You can start with Control Tower and add your own SCPs and conformance packs.
How do I stop public S3 buckets across all AWS accounts?
Turn on account-level S3 Block Public Access in every account, and deny changes to that setting with an SCP in production OUs. Add an AWS Config rule such as S3_BUCKET_PUBLIC_READ_PROHIBITED to catch buckets that are already public. Review the findings and remove public access at the bucket or policy level.