Security foundations and governance

Multi-account strategy with AWS Organizations

• A management account (payer, minimal workloads, no day-to-day use), organizational units (OUs) in a tree, and member accounts. All features mode is needed for SCPs and integrated services; consolidated billing alone isn’t enough.
• Recommended structure: Security OU (log archive and security tooling accounts), Infrastructure OU (network, shared services), Workloads OUs by environment (prod, non-prod, sandbox), plus Suspended and Policy staging OUs. Separate accounts for log archive and security tooling keep evidence away from workload admins.
• Account is the strongest isolation boundary (IAM, quotas, billing, blast radius).
• Trusted access lets an AWS service operate across the organization; delegated administrators run it from a member account so the management account stays clean.
• Policy attachment inherits: a policy at the root applies to everything below; effective permission is the intersection down the path.
• Account creation: Organizations API, or Account Factory in Control Tower, or Service Catalog for vending; use a standard baseline (IaC) on every new account. Closing and moving accounts have rules and a 90-day post-closure window.

AWS Control Tower

A managed landing zone that sets up an organization with best practice defaults.

Enrolling existing accounts and an existing organization: register OUs and enrol accounts; accounts need a role (AWSControlTowerExecution) and Config set up appropriately; you can enrol an organization by creating the landing zone in the management account. Don’t change Control Tower–managed resources by hand.

Control Tower vs plain Organizations: Control Tower is the opinionated, managed setup (fast, but less flexible); Landing Zone Accelerator is a larger, customisable solution; plain Organizations gives you full custom control.

Organization policies

SCP strategy: use a deny list for guardrails (deny leaving the organization, deny disabling GuardDuty/CloudTrail/Config, deny regions outside an allow-list via aws:RequestedRegion with global service exceptions, deny root user actions, deny creating IAM users, deny unencrypted resource creation). Use an allow list only in tightly controlled OUs. Test in a policy staging OU. SCP size limit is 5,120 characters; five SCPs per target.

Typical patterns:

• Region restriction: deny all actions where aws:RequestedRegion is not in the approved list, excluding global services via NotAction.
• Protect security tooling: deny guardduty:DeleteDetector, config:StopConfigurationRecorder, cloudtrail:StopLogging, unless the principal is a specific admin role (ArnNotLike aws:PrincipalArn).
• Data perimeter: SCPs control who (my principals only access my resources: aws:ResourceOrgID), RCPs control what reaches my resources (only my org or approved partners: aws:PrincipalOrgID), VPC endpoint policies control the network path. Together: identity, resource and network perimeters.

Centrally managing security services

Designate a delegated administrator for each service from the management account, then enable trusted access and auto-enable for new accounts:

Keep the delegated admins in the security tooling account, with Identity Center permission sets for the security team, and a log archive account for immutable logs.

Root user credentials

• Root has unrestricted power; protect it with a unique strong password, MFA (preferably multiple, including a hardware key/passkey), and a monitored email alias. AWS requires MFA for root.
• Centralised root access management: in an organization, enable it so member accounts need no root credentials (you can delete them). Then privileged tasks such as deleting a wrongly configured S3 bucket policy, deleting an SQS queue policy, or unlocking a locked-out KMS key use a short-lived root session (sts:AssumeRoot with a task policy) from the management or a delegated admin account. Also supports auditing which accounts still have root credentials and recovering a member account’s root access.
• Break-glass: a documented emergency path (sealed root credentials or a dedicated emergency role/IAM Identity Center permission set), strongly alarmed (EventBridge on ConsoleLogin by root or break-glass role), access split between people, tested regularly, and credentials rotated after use.
• Use an SCP to deny root actions in member accounts. Don’t create root access keys.
• Billing and a few account-level tasks still require root: closing an account, changing support plan, some registrations, and restoring IAM permissions when everything is locked.

Secure, consistent deployment

Infrastructure as code

• CloudFormation: change sets to preview, drift detection, stack policies, DeletionPolicy, service roles (least-privilege execution), termination protection, hooks for proactive checks.
• StackSets: deploy stacks to many accounts and Regions. Service-managed permissions use Organizations: target OUs, automatic deployment to new accounts, delegated administrator support. Self-managed uses roles you create (AWSCloudFormationStackSetAdministrationRole and an execution role in each target). Operation preferences: max concurrent accounts, failure tolerance, region order.
• CloudFormation Guard (cfn-guard): policy-as-code language that validates templates (for example “S3 buckets must have encryption and block public access”). Runs in pipelines and as CloudFormation Hooks or Control Tower proactive controls. cfn-lint checks syntax and best practice. Other tools: cfn-nag, Checkov, tfsec, OPA, Terraform with Sentinel; Service Catalog and third-party IaC (Terraform, Pulumi) can follow the same pipeline.
• Pipeline guardrails: linting and policy checks before deployment, Access Analyzer custom policy checks on IAM policies, approvals, deployment roles scoped per account, drift detection after.

Tags

• Tag by owner, department, cost centre, environment, data classification, compliance scope. Tags drive cost allocation, ABAC, automation (backup selection, patch groups), and Config/Resource Groups.
• Tag policies standardise; SCPs can require tags on creation (Null on aws:RequestTag/...) and stop tag changes; Config rule required-tags detects drift; Tag Editor and Resource Groups find and fix at scale; AWS Config / Resource Explorer inventory.
• Don’t put secrets or personal data in tags; they’re widely visible and appear in billing.

Central policy deployment with Firewall Manager

Firewall Manager applies and audits protections across accounts and resources by policy and scopes by account, OU, resource type and tag; it auto-remediates and covers new resources and accounts.

Prerequisites: Organizations with all features, a Firewall Manager administrator account, and AWS Config enabled in member accounts.

Sharing resources securely

• AWS Resource Access Manager (RAM): share subnets (VPC sharing), Transit Gateway, Route 53 Resolver rules, License Manager configs, Private CA, and so on, with accounts, OUs or the whole organization. Enable sharing with Organizations so shares don’t need invitations. The consumer gets use (not ownership); it’s the way to avoid resource duplication. Managed permissions limit what consumers can do.
• AWS Service Catalog: governed portfolios of approved CloudFormation/Terraform products, launch constraints (a role that provisions on behalf of users, so users don’t need broad permissions), template constraints, tag options, and sharing portfolios to accounts or the organization. Use for self-service with guardrails.
• Other sharing mechanisms: AMI and snapshot launch permissions, ECR cross-account permissions, resource policies, and Lake Formation shares. Prefer organization-scoped conditions over public sharing.

Evaluating compliance

AWS Config

• Records resource configuration items and changes; rules evaluate them; conformance packs bundle rules and remediation; aggregators collect from all accounts and Regions in an organization; advanced queries (SQL) search current configuration.
• Rule types: managed, custom Lambda, custom Guard; triggers: configuration change or periodic; proactive evaluation checks a resource configuration before provisioning (for example in CloudFormation hooks).
• Remediation: attach an SSM Automation document, automatic with retry or manual; set an execution role. Remediation also supports organization conformance packs. Notifications through EventBridge and SNS.
• Organization Config rules and organization conformance packs deploy from the management or delegated admin account to all members.
• Config evaluates the state (detective); SCPs prevent. Config is Regional, so enable it in each Region and in each account.

Security Hub

Security Hub CSPM runs controls against standards (AWS Foundational Security Best Practices, CIS AWS Foundations, PCI DSS, NIST SP 800-53, others), computes a security score per standard, aggregates findings across accounts and Regions (a home Region with linked Regions) and supports central configuration policies: set which standards and controls are on, for which OUs/accounts, from the delegated administrator. Automation rules update findings; custom actions trigger EventBridge; findings can open tickets (Jira, ServiceNow) and send to SIEM. Security Hub relies on Config recording being on.

Audit evidence

Shared responsibility: AWS reports cover “security of the cloud” (Artifact), and your evidence covers “security in the cloud” (Audit Manager).

Well-Architected

The AWS Well-Architected Tool lets you run a workload review against the Well-Architected Framework (including the Security pillar) and the Security lens, records answers, flags high and medium risk items, builds an improvement plan and milestones, and can share reviews across accounts. Trusted Advisor security checks (open ports, IAM key rotation, public snapshots) and Security Hub provide automated checks. Security pillar areas: security foundations, identity and access management, detection, infrastructure protection, data protection, incident response, application security.

Common traps

• SCPs don’t apply to the management account; keep it empty of workloads.
• Detaching FullAWSAccess without adding allows denies everything.
• Tag policies don’t block untagged creation; SCP or Config does.
• RCPs and SCPs are different axes: principal vs resource.
• Declarative policies are service-level baselines; they aren’t IAM permissions.
• StackSets: service-managed for Organizations with auto-deploy; self-managed requires roles.
• Firewall Manager needs Config and a designated administrator.
• Artifact is about AWS, not about your configuration.
• Config rules don’t prevent; they detect and optionally remediate.
• Control Tower guardrails are SCPs (preventive), Config rules (detective) or CloudFormation hooks (proactive).