DEV Community: Shahid Yousuf

GitHub Actions OIDC Trust Policy for AWS

Shahid Yousuf — Fri, 09 Oct 2026 06:02:53 +0000

Plenty of AWS accounts have an IAM user that exists only so a GitHub Actions workflow can push an image or run a deploy. Its access key sits in a repository secret and never expires. GitHub Actions OIDC is the better answer.

The trust policy is where this goes wrong, and it got harder this year. Create a repository in your GitHub organization today and its Actions jobs present a different identity to AWS than the repository next to it. The older one says repo:example-org/api:ref:refs/heads/main, while the new one says repo:example-org@1234567/api@456789:ref:refs/heads/main. A trust policy written only for the first format denies the second, and the error tells you nothing about why.

I designed around that trap when I built GitHub OIDC roles for CI image pushes in a multi-account AWS estate, trusted by every repository across two GitHub organizations, so the long-lived access keys those pipelines use can be retired. A GitHub Actions OIDC AWS trust policy that survives this needs three things: accept both subject formats, pin the organization by its numeric ID, and prove the policy against every repository before it ships. After that you switch workflows over additively and retire keys only after watching them go quiet. Done in that order, every step can be rolled back by reverting one workflow file while the old keys still work. More of the governance work is in my AWS multi-account governance case study.

How GitHub OIDC reaches AWS

OIDC (OpenID Connect, a standard for one system to vouch for an identity to another) replaces the stored key. GitHub signs a short-lived token describing the job, and AWS trades it for temporary credentials if the role's trust policy accepts what the token says.

View this diagram in the original post

STS issues credentials only when the token's claims satisfy the role's trust policy.

The job needs id-token: write permission to request the token. The aws-actions/configure-aws-credentials action (currently v6) does the exchange. Its default audience is sts.amazonaws.com, and its default session is one hour, adjustable from 15 minutes to 12 hours. GitHub's guide to OIDC in AWS covers the provider setup. If you lead a team, ask how many IAM users exist only so CI can reach AWS; each is a candidate for OIDC.

Two subject formats, side by side

Trust policies match on the sub claim. GitHub's OIDC reference builds it from the repository plus one context: an environment, a pull request, a branch or a tag.

Job context	Name-only format	Immutable format
Job references an environment	`repo:ORG/REPO:environment:NAME`	`repo:ORG@ORG-ID/REPO@REPO-ID:environment:NAME`
Pull request event, no environment	`repo:ORG/REPO:pull_request`	`repo:ORG@ORG-ID/REPO@REPO-ID:pull_request`
Branch, no environment, not a pull request	`repo:ORG/REPO:ref:refs/heads/BRANCH`	`repo:ORG@ORG-ID/REPO@REPO-ID:ref:refs/heads/BRANCH`
Tag, no environment, not a pull request	`repo:ORG/REPO:ref:refs/tags/TAG`	`repo:ORG@ORG-ID/REPO@REPO-ID:ref:refs/tags/TAG`

Per GitHub's reference, the pull request, branch and tag forms apply only when the job references no environment.

The immutable format is the default for repositories created after July 15, 2026. Older repositories keep the name-only format unless the organization or repository opts in, and the immutable format isn't available on GitHub Enterprise Server.

A rename flips the format

Repository renames and transfers after July 15, 2026 also move to the immutable format. A name-only policy stops matching a repository the day someone renames it.

IDs matter because the OIDC specification requires a subject to be "locally unique and never reassigned", and a recycled name breaks that. GitHub separates name and ID with @, which cannot appear in a GitHub name, after researchers showed an earlier - delimiter was squattable¹. AWS's condition key reference agrees:

AWS IAM documentation: use immutable identifiers, not names

A name that is freed by renaming or deletion can be claimed by a different account. Policies that rely solely on mutable name-based claims (such as repository or actor) could grant access to unintended identities.

If your organization has created or renamed a repository since July 15, 2026, check which format each repository now uses. Then ask whether your AWS roles accept both before the next new one needs to deploy.

Writing the GitHub OIDC trust policy

When you create or update a role that trusts GitHub, IAM checks that token.actions.githubusercontent.com:sub is present and is not solely a wildcard or null, and fails the request otherwise. That rules out trusting by organization ID alone.

You cannot trust by organization ID alone

A policy with only repository_owner_id is rejected. Existing roles are not re-evaluated until someone edits their trust policy, so an old, loose role keeps working until its next edit fails.

The sub condition lists both formats for your organization, and a separate repository_owner_id condition pins the organization by its numeric ID. AWS evaluates multiple values for one key as a logical OR and separate keys or operators as a logical AND, so the token must match one of the sub patterns and carry the right owner ID and the right audience. The slash in each pattern matters: repo:example-org/* doesn't match repo:example-orgX/..., because the character after example-org must be /. The four variants run from widest to narrowest. Account 123456789012, example-org and the IDs are placeholders.

Org-wide

trust-policy-org-wide.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:repository_owner_id": "1234567"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": [
            "repo:example-org/*",
            "repo:example-org@1234567/*"
          ]
        }
      }
    }
  ]
}

One repository

trust-policy-one-repo.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:repository_owner_id": "1234567",
          "token.actions.githubusercontent.com:repository_id": "456789"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": [
            "repo:example-org/example-repo:*",
            "repo:example-org@1234567/example-repo@456789:*"
          ]
        }
      }
    }
  ]
}

One environment

trust-policy-environment.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:repository_owner_id": "1234567",
          "token.actions.githubusercontent.com:repository_id": "456789",
          "token.actions.githubusercontent.com:sub": [
            "repo:example-org/example-repo:environment:production",
            "repo:example-org@1234567/example-repo@456789:environment:production"
          ]
        }
      }
    }
  ]
}

Branch main

trust-policy-ref-main.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:repository_owner_id": "1234567",
          "token.actions.githubusercontent.com:repository_id": "456789",
          "token.actions.githubusercontent.com:sub": [
            "repo:example-org/example-repo:ref:refs/heads/main",
            "repo:example-org@1234567/example-repo@456789:ref:refs/heads/main"
          ]
        }
      }
    }
  ]
}

For the image-push roles I built, I chose org-wide. Each environment account got one OIDC provider and one narrowly scoped role, which can do only the push and pull actions the existing CI key's IAM user uses, only against its own account's registries, with the session capped at four hours. The worst case is a compromised workflow in any repository overwriting an image tag that production pulls. Tag immutability on the registries, or one role per registry, narrows that further.

I rejected a named repository allow-list, because an allow-list is only as complete as the inventory behind it. One built from default-branch workflows misses repositories that run only on other branches, every new repository needs a policy change before it can push, and a name-only list denies every new-format repository. I'd rather accept breadth in the trust policy and keep the permission policy narrow.

AWS warns that sub must be limited to your organization or repository, and strongly recommends protection rules wherever you use GitHub environments. For a role that can change production, I go further: scope it by environment or ref, behind protection rules. Org-wide trust is a deliberate exception I make only when the permission policy is narrow.

I also left GitHub's subject customization (include_claim_keys) alone. A custom template changes the sub for every repository that adopts it, so every trust policy those repositories reach has to change in step with it, and the default format needs no such coordination. Whatever width you choose, ask for a one-line note per role: who can assume it, and the worst case if a workflow is compromised.

Prove it against every repository

A trust policy that looks right is still only a claim, so before shipping I checked it against every repository in both organizations. The first step reads each repository's subject template. The REST endpoint returns use_default, include_claim_keys, use_immutable_subject and sub_claim_prefix.

audit-oidc-subjects.sh

#!/usr/bin/env bash
set -euo pipefail

for org in example-org example-org-two; do
  gh repo list "$org" --limit 1000 --json nameWithOwner --jq '.[].nameWithOwner' |
    while read -r repo; do
      gh api "repos/${repo}/actions/oidc/customization/sub" \
        --jq "[\"${repo}\", .use_default, (.use_immutable_subject // false), (.include_claim_keys // [] | join(\",\"))] | @tsv" ||
        printf '%s\tERROR\n' "$repo"
    done
done

gh needs a token with the repo scope, and --limit 1000 caps the list silently, so raise it for larger organizations. Any repository with a custom template or the immutable flag is one your policy must handle. When I ran this check across both organizations, several recently created repositories already used the new format.

The second step is a simulation. I generated the sub each repository would send for a fixed set of trigger shapes and matched it against the policy's patterns locally. This was a local pattern-match simulation, not the IAM policy simulator. Every real repository was allowed.

A minimal version of the local check

fnmatchcase treats * and ? the way StringLike does. It also treats [ specially, which StringLike does not, so this is a sanity check rather than an IAM evaluation.

simulate_trust.py

from fnmatch import fnmatchcase

OWNER_ID = "1234567"
PATTERNS = ["repo:example-org/*", "repo:example-org@1234567/*"]

def allowed(sub: str, owner_id: str) -> bool:
    return owner_id == OWNER_ID and any(fnmatchcase(sub, p) for p in PATTERNS)

cases = {
    "repo:example-org/api:ref:refs/heads/main": ("1234567", True),
    "repo:example-org@1234567/api@456789:pull_request": ("1234567", True),
    "repo:example-orgx/api:ref:refs/heads/main": ("1234567", False),
    "repo:other-org/api:ref:refs/heads/main": ("1234567", False),
    "repo:example-org-fork/api:pull_request": ("1234567", False),
    "repo:someone@999/example-org@1234567:ref:refs/heads/main": ("1234567", False),
}

for sub, (owner_id, expected) in cases.items():
    assert allowed(sub, owner_id) is expected, sub
print("all cases match")

Allows alone prove half the policy, so the third step is a set of negative controls: subjects that should never get credentials.

Negative control	What it imitates	Result
Look-alike organization name	Your org name plus one character	Denied
Foreign organization	Any other GitHub organization	Denied
Fork-style owner	An organization named after yours with a suffix, such as `example-org-fork`	Denied
Embedded `@` identity	Another owner whose `sub` carries your `org@ID` after its own name	Denied

Each was denied by the sub patterns alone, and the owner-ID condition is a second, independent check. The last two steps cover permissions. I pulled the existing key's last 90 days of API calls and confirmed every one fit inside the new role's allowed actions, and IAM Access Analyzer policy validation returned no errors. Before a trust policy ships, ask for that evidence: every repository simulated, negative cases denied, the existing key's real usage covered.

Switch workflows over additively

The role sits alongside the keys, so you can switch one workflow at a time while the old keys still work as a fallback. For a typical image-push workflow the diff is small.

Before: access keys

.github/workflows/push-image.yml

name: push-image
on:
  push:
    branches: [main]

jobs:
  push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: aws-actions/configure-aws-credentials@v6
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - run: aws sts get-caller-identity

After: OIDC

.github/workflows/push-image.yml

name: push-image
on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  push:
    runs-on: ubuntu-latest
    environment: dev
    steps:
      - uses: actions/checkout@v6
      - uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: ${{ vars.AWS_ROLE_ARN }}
          role-duration-seconds: 3600
          aws-region: us-east-1
      - run: aws sts get-caller-identity

Three details in that diff matter:

contents: read stays. A permissions block sets every scope you do not list to none, and actions/checkout needs read access.
The role ARN lives in a GitHub environment variable, one per environment, which keeps dev, staging and prod roles apart.
environment: dev changes the sub. The job now sends repo:...:environment:dev, not ref:refs/heads/main. The org-wide pattern accepts both. A branch-scoped policy would deny it.

role-duration-seconds must not exceed the role's maximum session duration. I show tags for readability; pin both actions to a full commit SHA in real workflows, as GitHub's own example does.

Roll out in environment order: dev, then staging, then prod. For each one, verify three ways: the run succeeds, CloudTrail, in the Region the workflow sets as aws-region, shows an AssumeRoleWithWebIdentity event whose userIdentity.userName is the actual sub, and the role's last activity in IAM updates. If anything fails, revert the workflow change, because the keys still work. Ask for one environment at a time, a named rollback and CloudTrail proof, not just a green build.

Retire the keys, then close the door

Retirement runs per environment. These two commands check when a key was last used and switch it off without deleting it.

check-and-deactivate-key.sh

aws iam get-access-key-last-used --access-key-id "${ACCESS_KEY_ID}"

aws iam update-access-key \
  --user-name "${CI_USER_NAME}" \
  --access-key-id "${ACCESS_KEY_ID}" \
  --status Inactive

The sequence for each environment:

Confirm every workflow in that environment uses the role.
Watch GetAccessKeyLastUsed through a quiet period, for example seven days, with no key use.
Deactivate the key, then wait one release cycle.
Delete the GitHub secrets that held it.
Delete the key, then the IAM user.

Deactivate before you delete

An inactive key can be reactivated in seconds if a forgotten job surfaces. A deleted key cannot. Also look for keys created outside your infrastructure-as-code state: a terraform destroy of the user fails while such a key still exists, because IAM will not delete a user that has an access key.

The last step of the method is a guardrail so new keys don't creep back: an SCP (a service control policy, an organization-level policy that can only deny) that blocks IAM user and key creation for everyone except your landing-zone automation. Stage it before enforcing it.

scp-deny-iam-user-credentials.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLongLivedIamUserCredentials",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateAccessKey",
        "iam:CreateLoginProfile"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/example-landing-zone-automation",
            "arn:aws:iam::*:role/example-break-glass-admin"
          ]
        }
      }
    }
  ]
}

With multiple values under a negated operator, AWS evaluates them as a logical NOR: the deny applies unless the caller matches one of the exempt roles. SCPs do not affect the management account or service-linked roles, so they are not a complete fence. Denying CreateAccessKey also blocks key rotation for any IAM user still in service, so retire those first or exempt them deliberately.

Before attaching, search CloudTrail for the last 90 days of CreateUser, CreateAccessKey and CreateLoginProfile calls. Every caller you find either moves off keys first or goes on the exemption list. For AWS Control Tower, the exemptions include AWSControlTowerExecution. Attach to a small OU first. If you are weighing an SCP against the newer policy types, I compare them in SCP vs RCP vs declarative policies.

"Keys retired" should mean deleted after a watched quiet period, not deactivated and forgotten. Ask for the guardrail to land last, on a test OU first.

Migration checklist

Track the method per environment. Close the ticket only when every box is ticked.

☐ Inventory every IAM user whose keys live in GitHub secrets
☐ Audit every repository's OIDC subject template with the gh api script
☐ One OIDC provider per account; one role per environment, permissions copied from the existing key's real usage
☐ Trust policy accepts both sub formats and pins repository_owner_id
☐ Local simulation of every repository, plus negative controls
☐ Access Analyzer validation clean
☐ Workflows switched dev, staging, prod, each verified in CloudTrail
☐ Quiet period observed per key, then deactivate, wait, delete secrets, delete key and user
☐ Credential-creation SCP staged on a test OU, then enforced

What to do next

Run the audit script against your own organization; it's read-only. If any repository reports use_immutable_subject as true and your trust policies only list names, you have found a repository that will be denied the first time a workflow there tries to assume one of those roles.

Then check your CI roles' sub conditions against the two-format table in Two subject formats, side by side. If you want to talk through the rollout order before touching a pipeline, book a free intro call.

Boost Security Labs, "Sleeper Squats: How a Hyphen (Almost) Unraveled GitHub's Immutable OIDC Subject Claim". ↩

SCP vs RCP vs Declarative Policies in AWS

Shahid Yousuf — Fri, 09 Oct 2026 06:02:48 +0000

Once an AWS organization has more than a handful of accounts, guardrails stop being something each account team sets up for itself. A typical request: S3 Block Public Access switched on in every account, and kept on. AWS Organizations has three policy types that look like they could do that, a service control policy (SCP), a resource control policy (RCP) and a declarative-style policy. Only one of them can actually hold the setting, and picking the wrong one either leaves a gap or blocks your own fix.

The obvious control is an SCP denying s3:PutBucketPublicAccessBlock. Check CloudTrail before you write it: in a real estate most calls to that API are Terraform turning protection on. No condition key separates enabling Block Public Access from disabling it, so the deny stops the safe change along with the dangerous one.

The three types answer different questions. SCPs limit what your own principals can do, RCPs limit how anyone can reach your resources, and declarative policies hold a setting at a fixed value, so the useful question for any guardrail is whether you need to deny a verb or assert a state. The examples come from governing a real multi-account estate, written up as a multi-account AWS governance case study. Every policy is generic, with placeholders for Regions and AWS's documentation example account 123456789012 for every account ID.

SCP vs RCP vs declarative policy at a glance

All three are authorization or management policies in AWS Organizations, attached to the root, an OU (organizational unit, a folder of accounts) or an account. Strictly, AWS calls the EC2 type a declarative policy (DECLARATIVE_POLICY_EC2) and the S3 one an Amazon S3 policy (S3_POLICY). Both use the same syntax and hold a setting, so this guide groups them as "declarative".

	SCP	RCP	Declarative (EC2) / S3 policy
What it limits	IAM users and roles in member accounts, including the member root user	Requests to your resources, from any principal	A service setting, held at a fixed value
Grants access?	Never	Never	Not an access policy; it sets state
Management account	Not affected	Not affected	Not stated in AWS docs; test before relying on it
Service-linked roles	Not affected	Not affected	Governed
Principals outside your org	Not affected	Affected	Not applicable
Report-only mode	None	None	Some attributes have one (Allowed AMIs `audit_mode`, VPC Encryption Controls `attempt_monitor`)
`DescribeEffectivePolicy`	Not supported	Not supported	Supported (EC2 and S3 types)
Size and per-target limit	10,240 characters, 10	5,120 characters, 5	10,000 characters, 10

Sources: the AWS Organizations user guide pages for SCPs, RCPs and declarative policies.

The service-linked roles row matters most: AWS services acting on your behalf slip past SCPs and RCPs, but not past a declarative policy, which the service enforces in its control plane. And none of the three grants anything. If someone proposes an SCP "to give the team access", send the plan back before it starts.

Deny a verb or assert a state

I run every proposed guardrail through three questions:

Who is acting? If the control is about your own users and roles doing something, it is an SCP.
What resource is being reached? If the control is about any caller touching your data (including outsiders), it is an RCP.
What setting must hold? If the control is "this must be on", look for a declarative attribute first.

View this diagram in the original post

Start from the end state you want, not the API you want to block.

Block Public Access is the clean example. The Organizations S3 policy asserts "on" for every account in scope, and in my test Terraform's bucket-level calls kept succeeding (more on that in the declarative section). It also avoids an ordering trap. If you deny the account-level Block Public Access API before the value is set, you've blocked your own fix until you detach the SCP or add an exemption, while with the S3 policy Organizations sets the value for you.

When a team asks for a guardrail, ask them to describe the state they want rather than the action they want to block. The answer usually picks the tool.

SCPs for your own principals

An SCP is a ceiling on IAM permissions in member accounts, and that includes member accounts acting as delegated administrators. An action must be allowed at every level from the root down to the account, and a deny at any level wins. That's why the default FullAWSAccess SCP must stay attached or be replaced by your own allow list.

A baseline that has held up well for me covers five things: no leaving the organization, no closing accounts, no turning off the main security services, no new unencrypted EBS volumes, and no root user minting access keys, IAM users or passwords. Treat the action lists below as a starting point: each service has more off switches (for example guardduty:UpdateDetector and cloudtrail:UpdateTrail).

baseline-scp.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrgAndCloseAccount",
      "Effect": "Deny",
      "Action": ["organizations:LeaveOrganization", "account:CloseAccount"],
      "Resource": "*"
    },
    {
      "Sid": "ProtectSecurityServices",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "guardduty:DeleteDetector",
        "securityhub:DisableSecurityHub",
        "access-analyzer:DeleteAnalyzer"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/AWSControlTowerExecution"
        },
        "StringNotEquals": {
          "aws:PrincipalAccount": "123456789012"
        }
      }
    },
    {
      "Sid": "DenyUnencryptedEbs",
      "Effect": "Deny",
      "Action": ["ec2:CreateVolume", "ec2:RunInstances"],
      "Resource": "arn:aws:ec2:*:*:volume/*",
      "Condition": {
        "Bool": { "ec2:Encrypted": "false" }
      }
    },
    {
      "Sid": "ProtectEbsDefaultEncryption",
      "Effect": "Deny",
      "Action": "ec2:DisableEbsEncryptionByDefault",
      "Resource": "*"
    },
    {
      "Sid": "DenyRootCredentials",
      "Effect": "Deny",
      "Action": ["iam:CreateAccessKey", "iam:CreateUser", "iam:CreateLoginProfile"],
      "Resource": "*",
      "Condition": {
        "ArnLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" }
      }
    }
  ]
}

The two conditions in the security statement are ANDed, so the deny skips both the Control Tower role and the security tooling account (123456789012 here). It exempts the whole account because that account is the delegated administrator for these services and manages them for every member. If you can, narrow it to the specific roles there. EBS encryption-by-default has no declarative attribute, so protecting it stays an SCP job.

Turn on EBS encryption-by-default first

Enable EBS encryption-by-default in every account and Region before you attach the unencrypted-volume deny. Otherwise every volume create that does not ask for encryption fails.

I keep the Region restriction in a separate SCP. Region rules and data-protection rules change at different speeds, and a separate policy keeps the blast radius of each edit small. The pattern follows AWS's deny-by-requested-Region example. The NotAction list here is a short sample of global services; extend it with every global service you use before attaching.

region-scp.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "sts:*",
        "support:*",
        "route53:*",
        "cloudfront:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["${APPROVED_REGION_1}", "${APPROVED_REGION_2}"]
        },
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/AWSControlTowerExecution"
        }
      }
    }
  ]
}

Sweep every service before a Region lock

A pre-check that only lists EC2 resources misses S3 buckets in non-approved Regions. S3 bucket operations resolve to the bucket's Region, so once the SCP lands, such a bucket can no longer be managed. Inventory every service in every Region first.

If you use Control Tower, know that registering an OU attaches only its own aws-guardrails-* SCP. Your baseline needs its own attachment, and you shouldn't edit or detach Control Tower's SCPs. If you're moving accounts between organizations, the order of operations is in how to move an AWS account to another organization.

I handle exceptions with placement, not conditions: put the account that needs one in an OU without the policy, or attach the policy to its siblings individually. That's easier to audit than a tangle of exemption conditions. When you plan the work, budget for a baseline SCP, a separate Region SCP and a pre-attach inventory across every service. The inventory is the part teams skip.

RCPs for the data perimeter

An RCP is evaluated on the resource side and, unlike an SCP, applies to principals outside your organization too. That makes it the right place for data-perimeter rules: "nobody reaches these resources without TLS", whoever they are.

Beyond the table's exceptions, RCPs also skip AWS-managed KMS keys and kms:RetireGrant. They cover a growing list of services, including S3, STS, KMS, SQS, Secrets Manager, DynamoDB, ECR, Cognito, CloudWatch Logs and OpenSearch Serverless. RDS is not on it, so an RCP will not protect an RDS or Aurora database. The TLS-only policy here is AWS's published example, with a Sid added.

tls-only-rcp.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceSecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*",
        "sts:*",
        "kms:*",
        "sqs:*",
        "secretsmanager:*",
        "cognito-identity:*",
        "cognito-idp:*",
        "logs:*",
        "dynamodb:*",
        "ecr:*",
        "aoss:*"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

Pilot it on a non-production OU first. S3 website endpoints serve HTTP only, so a CloudFront distribution whose origin is an S3 website endpoint talks to it over HTTP, and under a TLS-only RCP that origin breaks. Find those distributions before you attach.

An RCP is how you protect data from callers you don't control. Before anyone assumes it protects a given data store, ask which services it covers.

AWS declarative policies vs SCP

A declarative policy does not block an API. It tells the service what the setting is, and the service enforces it in its control plane. Three properties follow:

It governs service-linked roles, which SCPs cannot.
It stays in force as the service adds new APIs, so there is no deny list to keep current.
New accounts inherit it the moment they join the OU.

s3-policy.json

{
  "s3_attributes": {
    "public_access_block_configuration": {
      "@@assign": "all"
    }
  }
}

EC2

ec2-declarative.json

{
  "ec2_attributes": {
    "image_block_public_access": {
      "state": { "@@assign": "block_new_sharing" }
    },
    "snapshot_block_public_access": {
      "state": { "@@assign": "block_new_sharing" }
    },
    "serial_console_access": {
      "status": { "@@assign": "disabled" }
    }
  }
}

The S3 policy makes public buckets private on attach

Setting all turns on all four Block Public Access settings and overrides the account's own. A bucket serving public content today stops serving it the moment the policy applies. Find those buckets first, then attach the policy to the other accounts individually, or move the account that needs public access to an OU without it.

The S3 policy has a single attribute, public_access_block_configuration, and it is all or none. AWS's guidance is to disable the S3 policy type if you want to manage Block Public Access per account. It shipped in November 2025, so guides written before then don't mention it. On detach, the setting rolls back to its pre-attach value, so know that value before you count on detach as a rollback.

In my test, with the S3 organization policy in force, a bucket-level PutBucketPublicAccessBlock call still succeeded. Public bucket policies and public ACLs were denied, because S3 applies the most restrictive combination of settings. That was a single test, so verify it yourself before you depend on it.

The EC2 declarative attributes also cover VPC Block Public Access, Allowed AMIs, IMDS defaults and VPC Encryption Controls. An EC2 declarative policy can replace SCP statements that block AMI and snapshot sharing, but prove the new coverage is a strict superset of the old before you remove anything.

IMDSv2 enforcement can stop launches

AWS warns that turning on http_tokens_enforced while launches still allow IMDSv1 (http_tokens optional, from a launch template, launch call or AMI default) causes launch failures. Set http_tokens to required and find IMDSv1 callers first. I left that attribute out deliberately.

For snapshots I chose block_new_sharing over block_all_sharing. block_new_sharing leaves anything already public as it is and stops new public shares, so it can't cut off a consumer you haven't found yet. block_all_sharing makes existing public snapshots private the moment it applies, so inventory them first. Neither mode affects sharing with specific accounts.

For Block Public Access and AMI or snapshot sharing, I'd choose an S3 or EC2 declarative policy over an SCP. It covers more principals and needs no maintenance as APIs change.

Quotas changed in 2026

AWS raised the SCP quotas on 15 May 2026. Current values from the Organizations quotas page, which does not list the S3 policy type separately:

Policy type	Max size	Max attached per root, OU or account
SCP	10,240 characters	10
RCP	5,120 characters	5 (`RCPFullAWSAccess` uses one)
Declarative (EC2)	10,000 characters	10

Inherited policies do not count toward a target's limit. A policy type must be enabled on the root before you can use it. Enabling SCPs auto-attaches FullAWSAccess; enabling the S3 policy or EC2 declarative policy type attaches nothing. RCP slots are the scarce ones, so plan RCPs as a few broad policies rather than one per rule.

Rolling out without breaking production

Testing is where these tools are weakest. There is no report-only mode for SCPs or RCPs. The IAM policy simulator evaluates SCPs that already apply but does not support RCPs, and it will not simulate a draft you have not attached. AWS's advice is to test on a test OU or account, use CloudTrail and last-accessed data, then move up the tree. Checking coverage afterwards is awkward too: DescribeEffectivePolicy does not support SCPs or RCPs, so to confirm an account is covered, walk its parent chain with ListParents and call ListPoliciesForTarget at each level.

validate-before-create.sh

aws accessanalyzer validate-policy \
  --policy-type SERVICE_CONTROL_POLICY \
  --policy-document file://baseline-scp.json

IAM Access Analyzer's validate-policy catches invented action names. For example, there is no s3:DeleteBucketPublicAccessBlock; deleting maps to the Put permission. It also recommends ArnLike over StringLike on ARN condition keys, which is why validation is the first line of the checklist I run for every attachment.

Comparing deployed policy JSON

AWS returns policy documents with keys and arrays in varying order. A plain string diff reports drift that is not there. Sort keys and arrays recursively on both sides before comparing.

☐ Validate the JSON with Access Analyzer before creating the policy
☐ Sweep every service in every Region for resources the policy would strand
☐ Set any value you are about to protect (encryption-by-default, Block Public Access) first
☐ Find every bucket that is public today before attaching the S3 policy
☐ For EC2 declarative policies, generate the Organizations account status report first
☐ Attach to a canary OU with non-production accounts
☐ Prove a fast detach works, and know what the setting reverts to
☐ Walk each account's parent chain to confirm coverage
☐ Check CloudTrail for new access denied errors the next day
☐ Move up one OU at a time

When one of these lands in a change request, look for the canary OU, the detach plan and the next-day CloudTrail check. If any of them is missing, the rollout isn't ready.

What to do next

List every guardrail you have and the state each one is meant to guarantee. Anything that reads "this setting must be on" moves to a declarative policy, anything about outsiders reaching your data belongs in an RCP, and the rest is SCP work.

Then run the checklist above on one policy and one low-risk OU. If you want a second pair of eyes on an estate before you start, book a free intro call; the multi-account governance case study shows the kind of estate this came from.

Move an AWS Account to Another Organization

Shahid Yousuf — Fri, 09 Oct 2026 06:02:44 +0000

When you need to move an AWS account to another organization, the move itself takes minutes. Getting the account governed afterwards is the real work. In a multi-account AWS governance engagement, I worked on exactly this: production accounts that had to end up under the destination's AWS Control Tower, reachable by the same people, and inside the destination's own guardrails.

Done casually, a move looks finished long before it is. The account shows up in the new organization, the Control Tower dashboard says enrolled, and people sign in through the new portal. Meanwhile the old organization can still administer the account, and your own guardrail policies may not reach it at all. Nothing on the screen tells you either of those things.

The right route is to invite the account from the destination organization's management account. When it accepts, AWS moves it across directly: it never leaves its old organization by itself and never runs standalone in between. The older leave-then-join route is the one that produces this error, and you don't need to fix it:

The member account is missing one or more of the prerequisites required to operate as a standalone account. To add what is missing, sign-in to the member account using the AWS Organizations console, then select to leave the organization...

What follows is the order of operations that works with Control Tower, and the three checks that decide whether a moved account is actually governed: sign-on, your own guardrail policies, and the old organization's admin role. On those moves, the client's cloud admin sent and accepted the invitations and ran the enrollment. I planned the sequence, prepared the landing OU, sign-on and baseline policies, and verified each account afterwards.

Why leave-then-join gets refused

The classic way to move an account is leave, then join: the account leaves its organization as a member, runs standalone for a while, then accepts an invite from the new one. To leave, it must be able to stand alone, and that is where it gets stuck.

In accounts created inside an organization, the payment method is usually missing. That was true here, but adding a card wasn't enough: Leave still refused, and AWS's message doesn't say what else it wants. No public API reads whether a payment instrument exists (billing, invoicing, billingconductor, account, ce and budgets all come up empty), but the console does: Billing, then Payment preferences, in the member account lists payment methods. The Leave dialog itself only said:

You can't leave the organization yet

AWS documents a "Complete the account sign-up steps" link for this message. With the invite path, you can skip it. If your migration plan depends on someone typing a payment card into every account by hand, send it back; there's a better path.

A refused removal is safe, but it is not a dry run

The 400 changes nothing. But if the prerequisites are met, that same call removes a production account from its organization on the spot. Do not use it to "test" readiness.

Invite from the destination instead

On 19 November 2025 AWS announced direct account transfers. The destination management account invites the account, the account accepts, and it moves straight across without leaving its old organization first or running standalone in between. In practice the invitation went through, and on acceptance the account left its old organization automatically, with no separate leave step.

The API reference makes this easy to miss. The InviteAccountToOrganization reference still lists ALREADY_IN_AN_ORGANIZATION as a failure reason, though read closely, that list sits under a caveat:

Some of the reasons in the following list might not be applicable to this specific API or operation.

The account migration guide describes the direct transfer, and the API reference's error list is shared boilerplate. When the two disagree, I go with the user guide.

	Leave, then join	Invite from destination
Standalone prerequisites	Required before leaving	AWS's docs say none needed
Payment card per account	Typed in by hand	Not mentioned in AWS's docs. Untested here: the one invited account already had a card.
Billing gap	A standalone period outside consolidated billing	None
Who acts	Member account leaves, then accepts an invite	Destination invites, member accepts
Outcome here	Refused, even with a card added	Worked

The two ways to move an account, as they played out here.

The commands themselves are short. Invite from the destination's management account, then accept in the member account:

Run in the destination management account

aws organizations invite-account-to-organization \
  --target Id=123456789012,Type=ACCOUNT

Run in the member account

aws organizations accept-handshake --handshake-id h-examplehandshakeid111

Read the guide's prerequisites first: rules on the age of the account and the organization, a Seller of Record that must match, and the fact that the account lands in the root of the new organization. Per the invitations page, invitations expire after 15 days and the new organization's policies apply as soon as the account joins. If your team plans to leave, then join, ask them why; the invite path skips per-account billing setup and the standalone gap.

How to move an AWS account to another organization, step by step

With AWS Control Tower in the destination, "moved" really means "moved and enrolled in the right organizational unit (OU)". The sequence:

Register the landing OU with Control Tower while it is still empty. For an empty OU it took about two minutes here; AWS's guidance is to plan for ten or more. Control Tower attaches its own aws-guardrails-* SCP (a service control policy: an org-level policy that can only deny, never grant). That is expected, not drift.
Associate security monitoring with the OU before anything arrives.
Invite from the destination; accept in the member account.
Create the AWSControlTowerExecution role in the account.
Enroll the account through Control Tower into the OU. Until enrollment, the account sits in the root under whatever policies are attached there, so enroll it the same day.

View this diagram in the original post

The full move, from invitation to the cleanup that makes the account fully yours.

The execution role trusts the destination's management account. This is the shape from the enrollment prerequisites; replace 111122223333 with your destination management account ID:

trust.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

The role also needs the AdministratorAccess managed policy, or enrollment fails:

Run in the member account

aws iam create-role --role-name AWSControlTowerExecution \
  --assume-role-policy-document file://trust.json
aws iam attach-role-policy --role-name AWSControlTowerExecution \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

I don't use aws organizations move-account for step 5. With auto-enrollment off, a manual move into a Control Tower OU does not enroll the account and causes inheritance drift. If you want moves to enroll on their own, Control Tower offers automatic enrollment on landing zone 3.1 and later.

I also wouldn't move every account at once. Order them by access risk, and hold back any account whose permission sets don't yet exist in the destination. Whoever owns the migration should confirm the landing OU and its security monitoring are in place, and checked, before the first account arrives.

Sign-on after the move

For users, the account disappeared from the old access portal and appeared in the new one with the same groups, with no access requests to re-file. This works only because the destination's directory already had the same groups, and permission sets were assigned to them on arrival. Nothing in Identity Center carries over by itself. The destination's IAM Identity Center creates the new sign-on roles (AWSReservedSSO_*) when permission sets are assigned, as Identity Center does.

If a group doesn't exist in the destination's directory, its members lose that path into the account, so create groups and permission sets in the destination before you move anything. Engineers will also hit a confusing error: a CLI profile still pointing at the old portal fails with ForbiddenException ... No access. It reads like a missing permission, but it's just the old portal. Point the profile at the new start URL and sign in again.

Root email addresses come across unchanged. One of ours pointed at a mailbox on a legacy domain, so check each one. Budget an identity prep step before the move, and tell engineers ahead of time that their CLI profiles will need a new start URL.

Enrolled is not the same as governed

Run a parity check against the organization's own guardrails after each move. On these moves, the accounts were enrolled, recording AWS Config and reporting to the security services, yet outside every one of the organization's own baseline policies, the SCPs and configuration policies (an EC2 declarative policy and an S3 policy, which set a service's configuration directly), for most of a week.

A dashboard showing "enrolled" means Control Tower's own controls apply, nothing more. Your organization's policies apply to an OU only if they are attached to it or inherited from above it. Here the baseline was attached OU by OU, not at the root, so a brand-new OU inherited none of it. Attaching policies that are safe everywhere at the root closes this class of gap; the trade-off is a wider blast radius for every change to them.

There is no effective-policy API for SCPs, so the check walks the parent chain. Configuration policies do have one:

policy-parity.sh

#!/usr/bin/env bash
# Run with management account credentials.
# List the SCPs that reach an account: its own, each parent OU's, and the root's.
set -euo pipefail
target="${ACCOUNT_ID:?set ACCOUNT_ID}"

while true; do
  echo "== ${target}"
  aws organizations list-policies-for-target \
    --target-id "${target}" --filter SERVICE_CONTROL_POLICY \
    --query 'Policies[].Name' --output text
  read -r parent_id parent_type < <(aws organizations list-parents \
    --child-id "${target}" --query 'Parents[0].[Id,Type]' --output text)
  target="${parent_id}"
  if [["${parent_type}" == "ROOT"]]; then
    echo "== ${target} (root)"
    aws organizations list-policies-for-target \
      --target-id "${target}" --filter SERVICE_CONTROL_POLICY \
      --query 'Policies[].Name' --output text
    break
  fi
done

# Configuration policies have an effective-policy API.
# Repeat with --policy-type DECLARATIVE_POLICY_EC2.
aws organizations describe-effective-policy \
  --policy-type S3_POLICY --target-id "${ACCOUNT_ID}"

Two details keep a check like this honest. Control Tower's list-enabled-baselines returns an OU as an ARN, while Organizations uses the bare ou- ID, so compare like with like. And list the policy types your organization has enabled (aws organizations list-roots --query 'Roots[0].PolicyTypes') instead of hard-coding them, or a check can silently skip one.

Attach missing policies one at a time, smallest blast radius first, and take care with one type in particular:

An S3 policy changes live state on attach

An SCP only denies future calls. An Organizations S3 policy overrides the account's Block Public Access settings the moment you attach it. A bucket that is public today stops being public. Detaching it restores the previous settings. If one account in the OU has public content that must stay public until its owner decides, attach the S3 policy to the other accounts individually and move it to the OU later.

The same check found a long-governed account missing baseline policies too, so the gap is not unique to new OUs. Make the parity check a runbook step after every move, and don't accept a dashboard's "enrolled" as proof that your own policies apply.

The old organization's admin role

Accounts created inside an organization get OrganizationAccountAccessRole, an admin role the management account can assume. Invited accounts do not get one in the new organization.

The old one is the problem. It survives the move, still trusts the old organization's management account, and still has admin rights, so whoever controls that old management account can still administer the account you just moved. The cleanup comes after the move because, until AWSControlTowerExecution and Identity Center access exist, the old role is the only admin path. Do it the same day.

Inspect who the role trusts

aws iam get-role --role-name OrganizationAccountAccessRole \
  --query 'Role.AssumeRolePolicyDocument'

It isn't the only role to check. Old-org StackSets execution roles can also trust the old management account:

Find every role that trusts the old management account

aws iam list-roles \
  --query "Roles[?contains(to_string(AssumeRolePolicyDocument), '${OLD_MGMT_ACCOUNT_ID}')].RoleName"

Replace your access path before you remove the old one

Verify both paths first: the human path (you can sign in through the new organization's Identity Center) and the automation path (AWSControlTowerExecution is assumable from the new management account). Then delete the old role, or retrust it to the new management account.

An account is not migrated until the old organization can no longer administer it. Make that an explicit exit criterion for every move, with someone named to verify it.

Running the next move

Treat each account as its own change: one ticket, both checklists, and a named person for the exit check. Put the baseline attach and the old-role cleanup inside the enrollment runbook, so they happen on move day rather than in a follow-up. If the payment question matters for your budget, invite one account that has no card on file before you plan the rest around either answer.

Before the move:

☐ Read the account migration prerequisites: account and organization age, matching Seller of Record
☐ No SCP or IAM policy in the source organization blocks the migration
☐ Resource policies using aws:PrincipalOrgID found and updated (they break silently after the move)
☐ Account deregistered as a delegated administrator, if it is one
☐ Organization-level billing history exported (AWS deletes it on removal)
☐ No existing AWS Config recorder or delivery channel left in the account (remove before enrolling)
☐ Groups and permission sets exist in the destination's Identity Center
☐ Landing OU registered with Control Tower while empty
☐ Security monitoring associated with the landing OU
☐ Accounts ordered by access risk; any account missing identity prep held back
☐ Root email addresses reviewed

After the move:

☐ Invitation accepted within its 15-day window
☐ AWSControlTowerExecution created with AdministratorAccess and the account enrolled into the OU (not move-account)
☐ Users can sign in through the new portal; CLI profiles updated
☐ Parity check: the organization's baseline SCPs and configuration policies reach the account
☐ Sanctioned public content checked before any S3 policy is attached
☐ Old OrganizationAccountAccessRole, and any other role trusting the old management account, deleted or retrusted

Paste both lists into the ticket for each account, and don't close it until every box is ticked. If you're planning a move like this and want a second pair of eyes on the order of operations, book an intro call. The full engagement it came from is in the AWS governance case study.

AWS Security Checklist for Small Teams

Shahid Yousuf — Thu, 08 Oct 2026 11:30:13 +0000

A small team's AWS setup usually grows by accident. There are one or two accounts, a handful of IAM users created years ago, an access key in the CI system that nobody remembers creating, and the root user still signs in with the founder's personal email. Nothing is on fire, so the AWS security checklist everyone means to work through keeps losing to the roadmap.

The trouble with doing it casually is that most AWS security controls fail quietly. A service shows as enabled while it evaluates nothing, or a guardrail covers EC2 but not the S3 bucket in another Region. You find out at the worst moment: an unexpected invoice, a leaked key, an auditor's question nobody can answer.

This checklist is the short, ordered version. Lock identity down this week, turn on detection this month, and add organization-wide guardrails as you grow. Verify every control after you enable it, because "enabled" and "actually evaluating" are different states. Most of the high-value items cost nothing, and the paid detection services each have a 30-day trial, so you can measure the bill before you commit to it.

AWS already publishes the AWS Startup Security Baseline (SSB), a list of account controls ACCT.01 to ACCT.17 and workload controls WKLD.01 to WKLD.15. It's good, but it isn't ordered by urgency, and it doesn't tell you how to prove a control is working or what it will cost. This guide takes the SSB controls that matter most early on, puts them in order, adds the multi-account guardrails the SSB leaves out, and gives each a verify step and a cost. Where I hit a trap governing a multi-account estate, written up as a multi-account AWS governance case study, I say so.

Prerequisites

To follow along, you need:

The AWS CLI version 2, configured with credentials for the account you're securing.
Administrator access to a standalone account, or to the management account if you already use AWS Organizations (the service that groups accounts under one payer and one set of policies).
A shared mailbox or distribution list for security and billing mail, such as aws-security@your_domain. Personal inboxes leave with people.

Commands use placeholders such as ${ACCOUNT_ID} or your-region. Replace them with your own values.

How to use this checklist

The 19 controls fall into three tiers. The first tier is free and mostly about identity, because a leaked key or a taken-over root user hands over everything. The second turns on detection and data protection. The third only makes sense once you run more than one account.

View this diagram in the original post

Work top to bottom, and verify each control before moving on.

The effort column is my rough judgement for a small team that knows its own systems. Treat it as an order of magnitude, not an estimate.

#	Control	Risk it closes	Rough effort	Cost
This week
1	Root MFA, no root keys, group email	Takeover through the one user you can't restrict	Minutes	Free
2	Security alternate contact	AWS security notices reach nobody	Minutes	Free
3	People sign in through IAM Identity Center	Passwords and keys tied to individuals	Hours	Free
4	Find and retire long-lived access keys	A leaked key works until someone deletes it	Hours	Free
5	CI through OIDC, not stored keys	Keys sitting in CI secrets	Hours per pipeline	Free
6	Budget and Cost Anomaly Detection	Abuse found on the invoice	Minutes	Free
This month
7	Multi-Region CloudTrail trail	No record of who did what	An hour	First management copy free, S3 storage billed
8	GuardDuty in every Region	Nobody watching for threats	An hour	Usage-based, 30-day trial
9	IAM Access Analyzer, external access	Resources shared outside the account	Minutes	Free
10	S3 Block Public Access, account level	Public buckets	An hour with inventory	Free
11	EBS encryption by default	Unencrypted volumes	Minutes per Region	Free
12	IMDSv2 as the account default	Instances on the older metadata service	Hours	Free
13	Secrets out of code and env files	Credentials in repositories	Varies	From free
14	Security Hub CSPM, standards chosen on purpose	No continuous configuration checks	Hours	Per check, plus AWS Config
As you grow
15	Centralized root access	Root credentials in member accounts	An hour	No extra charge
16	Baseline SCP	Someone switches detection off	A day with testing	No extra charge
17	Region SCP	Resources in Regions nobody watches	Days, mostly inventory	No extra charge
18	RDS snapshot sharing check	Database snapshots shared publicly	An hour	Free
19	Declarative policies	Settings drifting back	Hours	No extra charge

AWS Organizations is offered at no additional charge, so the policies in the last tier add nothing to the bill.

Most items below follow the same shape: what to do, why it matters, how to do it, how to verify it, and what it costs.

Do this week: identity and account basics

1. Lock down the root user

The root user can do anything in the account, including things no IAM policy can stop, so it's the one identity you can't afford to lose. AWS now requires MFA on the root user for all account types, with registration due within 35 days of first sign-in. Delete any root access keys, and move the root email to a group address so recovery doesn't depend on one person's inbox.

Console

Sign in as the root user. On the right of the navigation bar, choose your account name, then Security credentials. In the Multi-factor authentication (MFA) section, choose Assign MFA device (AWS steps). Delete any keys in the Access keys section on the same page. To change the email, choose your account name, then Account ; next to Account details , choose Actions , Update email address and password (AWS steps).

CLI

aws iam get-account-summary \
  --query 'SummaryMap.{MFA:AccountMFAEnabled,RootKeys:AccountAccessKeysPresent}'

The output will look similar to:

Output

{
    "MFA": 1,
    "RootKeys": 0
}

AccountMFAEnabled should be 1 and AccountAccessKeysPresent should be 0. Anything else means the root user still needs work. Cost: free.

2. Set the security alternate contact

AWS sends security notices to the security alternate contact. If it's empty or points at someone who left, the notice goes nowhere. See updating alternate contacts.

aws account put-alternate-contact \
  --alternate-contact-type=SECURITY \
  --email-address=aws-security@your_domain \
  --name="Security team" \
  --phone-number="${PHONE_NUMBER}" \
  --title="Security contact"
aws account get-alternate-contact --alternate-contact-type=SECURITY

The second command should show your group address. From a management account, add --account-id ${ACCOUNT_ID} to set the contact on a member account; that needs trusted access for AWS Account Management enabled in Organizations first. Cost: free.

3. Give people IAM Identity Center, not IAM users

IAM users carry a password and often an access key that never expires. IAM Identity Center gives each person one sign-in, short-lived credentials and permission sets you manage centrally, which is what the IAM best practices recommend for human access. Set it up, move each person across, then remove their IAM user. Verify with the credential report from the next item: no human IAM user should have a password. Cost: free.

4. Find and retire long-lived access keys

Access keys don't expire. A key that leaks into a repository, a laptop backup or a CI log keeps working until someone deletes it. Start with the credential report, a CSV of every IAM user and the state of their credentials.

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text \
  | base64 --decode > credential-report.csv

Run generate-credential-report until it returns "State": "COMPLETE", then download; the second command decodes the base64 content to a file. AWS regenerates the report at most once every four hours. For each user, read access_key_1_last_rotated and access_key_1_last_used_date (and the access_key_2_ pair). Old or idle keys are your first candidates.

Retire keys in two moves: deactivate first, delete later. A deactivated key can be switched back on in seconds if something breaks; a deleted one can't. See managing access keys.

aws iam update-access-key --user-name ${USER_NAME} \
  --access-key-id ${ACCESS_KEY_ID} --status Inactive

Recent use is not the full inventory

Before you deactivate a key, find every workflow that references it, not only the ones that ran recently. A release job or a quarterly report can sit idle for months and then fail on the day it matters. The same applies to roles: IAM's last-used data for a role only covers the trailing 400 days.

Cost: free.

5. Move CI to OIDC instead of stored keys

The most common long-lived key is the one in your CI system's secrets. With OIDC federation, the CI job presents a signed token and assumes an IAM role for the length of the run, so there's no key to leak. I cover the full trust policy in GitHub Actions OIDC trust policy for AWS.

Three things matter when you plan this across many repositories. Keep a sub condition, because IAM rejects a GitHub trust policy without one, and add the repository_owner_id claim to pin your organization by its numeric ID. Accept both subject formats GitHub now issues, because newer repositories use the immutable one. And run OIDC alongside the old key: retire the key only after each environment has had a green run on OIDC.

Verify by watching the old key's last-used date in the credential report. When it stops moving, the pipeline no longer needs it. Cost: free.

6. Turn on a budget and Cost Anomaly Detection

Abuse of a compromised account, such as crypto-mining instances, often shows up on the bill first. AWS Budgets are free to monitor, and the first two action-enabled budgets are free too. Cost Anomaly Detection watches spending patterns rather than a fixed ceiling.

Console

In Billing and Cost Management , open Budgets , create a monthly cost budget a little above your normal spend, and add email alerts at 80% and 100% of actual spend to your group address. Then open Cost Anomaly Detection and review the monitor and its alert subscription.

CLI

aws budgets create-budget --account-id ${ACCOUNT_ID} \
  --budget '{"BudgetName":"monthly-cost","BudgetLimit":{"Amount":"500","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --notifications-with-subscribers '[
    {"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80,"ThresholdType":"PERCENTAGE"},
     "Subscribers":[{"SubscriptionType":"EMAIL","Address":"aws-billing@your_domain"}]},
    {"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":100,"ThresholdType":"PERCENTAGE"},
     "Subscribers":[{"SubscriptionType":"EMAIL","Address":"aws-billing@your_domain"}]}
  ]'

Replace 500 with a figure that fits your account.

The default anomaly alert is set for a bigger bill than yours

If you started using Cost Explorer on or after 27 March 2023, AWS created a default anomaly monitor for you. Its alert only fires on anomalies above $100 and above 40%, according to the Cost Anomaly Detection FAQ. On a small bill that may never trigger. Lower the threshold to something that would actually surprise you.

Cost: free.

Do this month: detection and data protection

7. Record every Region with CloudTrail

CloudTrail is your record of who did what, and when; without it, an incident investigation has nothing to read. A multi-Region trail also covers the Regions you don't use. With Organizations, create an organization trail from the management account so every member account is covered.

First enable trusted access for CloudTrail (organizations only) and create a bucket for the logs:

aws organizations enable-aws-service-access \
  --service-principal cloudtrail.amazonaws.com
aws s3 mb s3://${TRAIL_BUCKET} --region your-region
aws s3api put-bucket-policy --bucket ${TRAIL_BUCKET} \
  --policy file://trail-bucket-policy.json

The bucket policy has to let CloudTrail write to the bucket. Copy it from the Amazon S3 bucket policy for CloudTrail, using the organization variant if you're creating an org trail. Then create the trail and start it, following the organization trail CLI steps:

aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name ${TRAIL_BUCKET} \
  --is-multi-region-trail \
  --is-organization-trail
aws cloudtrail start-logging --name org-trail
aws cloudtrail get-trail-status --name org-trail --query IsLogging

Drop --is-organization-trail (and the trusted-access command) for a standalone account. The output will look similar to:

Output

true

Per CloudTrail pricing, the first copy of management events is free; you pay for the S3 storage. If you later enroll accounts into AWS Control Tower while they still have their own account-level trails, you can end up paying for the same events twice, so remove the redundant trails first.

8. Turn on GuardDuty in every Region

GuardDuty is AWS's threat detection service: it analyzes CloudTrail events, VPC flow logs and DNS logs and raises findings for suspicious activity. It's Regional, and a Region where workloads can run but GuardDuty is off is a Region nobody is watching.

aws guardduty create-detector --enable --region your-region

Route findings to email through an EventBridge rule and an SNS topic. Start with the event pattern:

guardduty-findings-rule.json

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"]
}

Then create the topic, subscribe your group address, and point the rule at the topic:

TOPIC_ARN=$(aws sns create-topic --name guardduty-findings \
  --query TopicArn --output text)
aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email \
  --notification-endpoint aws-security@your_domain
aws events put-rule --name guardduty-findings \
  --event-pattern file://guardduty-findings-rule.json
aws events put-targets --rule guardduty-findings \
  --targets "Id"="sns","Arn"="$TOPIC_ARN"

The topic's access policy must allow events.amazonaws.com to call sns:Publish, or EventBridge drops the findings without telling you. Confirm the subscription email, too. EventBridge rules are Regional, so repeat this in each Region. With a GuardDuty delegated administrator, create the rules in that account, one per Region, because it receives member findings in each Region.

To verify the whole path, generate sample findings and confirm one reaches the inbox:

DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty create-sample-findings --detector-id ${DETECTOR_ID}

GuardDuty keeps findings for 90 days, so export them to S3 if you want a longer record. You don't need to turn on VPC flow logs for GuardDuty, which reads that data independently; enable them later if you want them for your own forensics.

Cost is usage-based. In the first pricing tier in us-east-1, GuardDuty pricing lists $4.00 per million CloudTrail events and $1.00 per GB of flow and DNS logs analyzed. New detectors also turn on most protection plans (S3, EKS, Malware, RDS, Lambda), each billed separately; review them on the trial's usage page and turn off what you don't run. The 30-day trial lets you measure first.

9. Run IAM Access Analyzer for external access

IAM Access Analyzer reads your resource policies and reports anything reachable from outside your account or organization. External access analysis is free. Analyzers are Regional, so create one per Region.

aws accessanalyzer create-analyzer --analyzer-name external-access \
  --type ACCOUNT --region your-region
aws accessanalyzer list-findings-v2 --analyzer-arn ${ANALYZER_ARN}

Use --type ORGANIZATION from the management or delegated administrator account to cover every member account. Organization analyzer findings are visible only in the account that owns the analyzer (the management account or the delegated administrator). Don't create a duplicate analyzer in a member account because the list looked empty from there.

The finding I once reasoned my way past was a queue policy that allowed any principal ("Principal": "*") and relied on an aws:SourceArn condition naming an S3 bucket. S3 bucket ARNs carry no account ID, so that condition doesn't pin access to your account; if the bucket is ever deleted, anyone can create one with the same name. Access Analyzer was right to call it public. If isPublic disagrees with your reading of a policy, trust the analyzer. AWS's confused deputy guidance recommends pairing it with aws:SourceAccount:

Condition block that pins the source account

"Condition": {
  "ArnLike": { "aws:SourceArn": "arn:aws:s3:::example-bucket" },
  "StringEquals": { "aws:SourceAccount": "123456789012" }
}

Optional: the unused-access analyzer

A second analyzer type reports roles, users, keys and permissions nobody has used in a set period. It isn't Regional.

aws accessanalyzer create-analyzer --analyzer-name unused-access \
  --type ACCOUNT_UNUSED_ACCESS \
  --configuration '{"unusedAccess":{"unusedAccessAge":90}}'

This one is paid: $0.20 per IAM role or user per month. AWS's pricing example puts 70 principals at $14 a month; at thousands of roles it becomes hundreds of dollars a month. Setup details are in creating an unused access analyzer.

10. Block public S3 access at the account level

Bucket-level settings protect one bucket. The account-level Block Public Access setting protects every bucket, including the next one somebody creates.

Find your intentionally public buckets first

The account setting overrides bucket policies and ACLs that grant public access. If you serve a static site or public downloads straight from S3, turning this on breaks them. List those buckets first and move them behind CloudFront, or accept that this account can't use the setting yet.

Console

In the S3 console, choose Account and organization settings in the navigation pane. Under Block Public Access settings for this account , choose Edit , turn on all four settings and choose Save changes , then type confirm and choose Confirm.

CLI

aws s3control put-public-access-block --account-id ${ACCOUNT_ID} \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Verify with aws s3control get-public-access-block --account-id ${ACCOUNT_ID}. The output will look similar to:

Output

{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": true,
        "RestrictPublicBuckets": true
    }
}

Cost: free. To hold this setting across an organization, use an Organizations S3 policy (a declarative policy type) rather than an SCP deny (item 19).

11. Encrypt new EBS volumes by default

EBS encryption by default makes every new volume and snapshot copy encrypted without anyone remembering a flag. It's a per-Region setting, and existing volumes stay as they are.

Console

In the EC2 console, select the Region, choose Settings in the navigation pane, then the Data protection and security tab. In the EBS encryption section, choose Manage , select Enable , then choose Update EBS encryption.

CLI

aws ec2 enable-ebs-encryption-by-default --region your-region
aws ec2 get-ebs-encryption-by-default --region your-region \
  --query EbsEncryptionByDefault

The output will look similar to:

Output

true

Repeat for every Region you use. Cost: free.

12. Make IMDSv2 the account default

The instance metadata service hands an EC2 instance its role credentials, and IMDSv2 requires a session token for every request. You can set it as the account default for new instances, per Region:

aws ec2 modify-instance-metadata-defaults --region your-region \
  --http-tokens required --http-put-response-hop-limit -1
aws ec2 get-instance-metadata-defaults --region your-region \
  --query AccountLevel.HttpTokens

The output will look similar to:

Output

"required"

Set the hop limit to 2 only if containers on the instance need the instance role, because going into a container counts as an extra network hop. To keep containers away from the instance's credentials, set it to 1 on those instances. -1 means no preference: at launch it becomes 2 for AMIs marked ImdsSupport: v2.0, such as Amazon Linux 2023, and 1 otherwise. Existing instances are unchanged. Cost: free.

Enforcement makes launches fail

Adding --http-tokens-enforced enabled turns the default into a hard rule: any launch that explicitly asks for IMDSv1 (a launch template or AMI with HttpTokens: optional) fails, and IMDSv1 can't be re-enabled on existing instances. Update your templates first, then turn on enforcement.

While you're on EC2: use Session Manager instead of opening SSH to the internet. The SSB lists it as WKLD.06. Instances no longer need port 22 open, and every session can be logged.

13. Move secrets out of code and environment files

Database passwords and API tokens in a repository or a committed .env file outlive every rotation policy you write. Move them to Secrets Manager at $0.40 per secret per month, or to Parameter Store SecureString parameters, where standard parameters are free. I'd use Secrets Manager where you want automatic rotation. To check a repository's history for secrets already committed, run a scanner such as gitleaks (gitleaks detect in the repository).

14. Turn on Security Hub CSPM with standards you chose

Security Hub CSPM (cloud security posture management) runs continuous checks against your configuration using AWS Config, and gathers findings from GuardDuty and Access Analyzer in one place. It needs the AWS Config recorder on in each Region, with IAM and other global resources recorded in one Region only, as the Security Hub prerequisites describe. Two settings then decide whether it's useful.

The first is the standards. Turning CSPM on with default standards enables AWS Foundational Security Best Practices and CIS v1.2.0, even though CIS v1.4.0, v3.0.0 and v5.0.0 are available. Decline the defaults and pick the versions you actually want to be measured against:

aws securityhub enable-security-hub --no-enable-default-standards
aws securityhub describe-standards --query 'Standards[].StandardsArn'
aws securityhub batch-enable-standards \
  --standards-subscription-requests StandardsArn=${STANDARDS_ARN}

Pass each ARN you want from the describe-standards output. The second setting is the home Region.

Match the home Region to where IAM is recorded

If you use central configuration or cross-Region aggregation, and your home Region differs from the Region recording global resources, the IAM controls sit at WARNING or DISABLED and never evaluate. On the estate I worked on, that is exactly where they sat until the home Region was moved to match.

Verify that the IAM. controls show PASSED or FAILED; DISABLED or WARNING means they aren't running.

CSPM costs $0.0010 per check for the first 100,000 checks, and the first 10,000 finding ingestions a month are free, per CSPM pricing. AWS Config is billed separately at $0.003 per configuration item recorded (Config pricing). There's a 30-day trial, and the console shows estimated costs during the trial.

AWS also sells a newer unified Security Hub, priced differently: the Essentials plan is $3.75 per resource unit, where one unit is one EC2 instance, 12 Lambda functions, 18 ECR images or 125 IAM users and roles (unified pricing). Make sure you're signing up for the product you meant.

Do as you grow: multi-account guardrails

One account means one blast radius: a mistake in a test stack can reach production, and everyone who needs test access gets a door into prod. Once you have more than a couple of people shipping, move to AWS Organizations with at least separate production and non-production accounts, keep the management account for billing and policies only, and apply the guardrails below.

15. Turn on centralized root access

Your security tooling will flag "root MFA missing" on member accounts. Accounts created in Organizations now start with no root credentials, but older and invited accounts often still have a password, and anyone who controls that root email inbox can reset it. The fix is centralized root access, which removes member root credentials and lets the management account run privileged root tasks when one is needed.

aws organizations enable-aws-service-access --service-principal iam.amazonaws.com
aws iam enable-organizations-root-credentials-management
aws iam enable-organizations-root-sessions

Once member root credentials are removed, AWS evaluates those accounts as not applicable for root MFA rules, so the Security Hub root MFA control (IAM.9) stops failing for them.

16. Attach a baseline SCP

A service control policy (SCP) caps what principals in member accounts can do, whatever their IAM permissions say. A baseline SCP stops anyone, including an attacker with an admin role, from leaving the organization, switching off detection or acting as root. The SCP guide covers the mechanics, and AWS's deny-changes-to-security-services examples go further than this one.

baseline-scp.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrg",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectDetection",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail",
        "cloudtrail:PutEventSelectors",
        "guardduty:DeleteDetector",
        "guardduty:UpdateDetector",
        "guardduty:DisassociateFromMasterAccount",
        "securityhub:DisableSecurityHub",
        "securityhub:DisassociateFromAdministratorAccount",
        "access-analyzer:DeleteAnalyzer"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": ["arn:aws:iam::*:role/your-security-admin-role"]
        }
      }
    },
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "ArnLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" },
        "Null": { "aws:AssumedRoot": "true" }
      }
    }
  ]
}

The Null condition exempts privileged root sessions started from the management account (item 15), so centralized root tasks keep working. The root statement follows AWS's own example.

Replace your-security-admin-role with the name of the role your security tooling uses. If you use Control Tower, add arn:aws:iam::*:role/AWSControlTowerExecution to the same ArnNotLike list. Attach the policy to a test OU (organizational unit, a folder of accounts) first, watch CloudTrail for AccessDenied errors from legitimate work, then widen it.

Control Tower has one more catch: registering an OU attaches its own guardrails, not your baseline SCP, so compare attached policies with a governed OU. I cover that gap in how to move an AWS account to another organization.

17. Restrict Regions with an SCP

A Region-deny SCP limits accounts to an allowed list, so resources can't appear in Regions nobody watches. Start from the Region-controls/Deny-access-to-AWS-based-on-the-requested-AWS-region.json example in the aws-samples SCP examples repository, the IAM Region-deny example, or the Control Tower Region deny control.

Inventory S3 and every Regional service, not only EC2

S3 operations resolve to the bucket's own Region. If a bucket lives outside your allowed list, the policy makes it unmanageable. On the estate I worked on, a pre-check that only looked at EC2 missed buckets in another Region. The policy was detached within minutes and only a sandbox was affected, but the pre-check now sweeps S3 bucket locations and the other Regional services before any attach, not EC2 alone.

If one team needs an extra Region, attach a variant policy to its OU rather than widening a shared one, which would loosen it for production too.

18. Check RDS snapshot sharing

Resource control policies (RCPs) set an organization-wide data perimeter for supported services, but they don't cover RDS, so check database snapshot sharing directly:

for id in $(aws rds describe-db-snapshots --snapshot-type manual \
    --query 'DBSnapshots[].DBSnapshotIdentifier' --output text); do
  aws rds describe-db-snapshot-attributes --db-snapshot-identifier "$id" \
    --query "DBSnapshotAttributesResult.DBSnapshotAttributes[?AttributeName=='restore'].AttributeValues[]" \
    --output text | grep -qw all && echo "PUBLIC: $id"
done

A restore attribute value of all means the snapshot is public. For Aurora, run the same check with describe-db-cluster-snapshots and describe-db-cluster-snapshot-attributes. Repeat per Region.

19. Hold settings in place with declarative policies

Some controls are states, not actions: S3 Block Public Access on, IMDSv2 required, AMIs and snapshots never shared publicly. Declarative policies hold those settings at a fixed value across the organization, enforced by the service itself. SCP vs RCP vs declarative policies compares all three policy types, RCPs included.

Verify the controls actually work

When a check fails, suspect the check first. On the estate I worked on, I logged more than a dozen cases where a "failure" turned out to be a bug in the tooling, not drift in the account. The habits that came out of it:

Sort before you diff. AWS returns policy JSON with keys and arrays in no fixed order. Sort both recursively before comparing a deployed policy with the one in your repository, or every comparison reports drift.
Normalize identifiers. Some APIs return full ARNs where others return bare IDs. aws controltower list-enabled-baselines, for example, returns ARNs. Compare like with like.
Ask the right account. Before declaring a service absent, query the delegated administrator account. Organization-wide findings often live only there.
Treat errors as unknown, not clean. I've seen a rate-limited code search report "no matches" because every throttled call came back empty. A sweep must tell "checked and clean" apart from "the check failed".
Include a control case. Run every check against one resource you know is compliant and one you know isn't. If both pass, the check is broken.

A small helper for the first habit:

normalize_policy.py

import json

def normalize(value):
    """Recursively sort dict keys and list items so two policies compare equal."""
    if isinstance(value, dict):
        return {key: normalize(value[key]) for key in sorted(value)}
    if isinstance(value, list):
        items = [normalize(item) for item in value]
        return sorted(items, key=lambda item: json.dumps(item, sort_keys=True))
    return value

def same_policy(deployed: str, expected: str) -> bool:
    return normalize(json.loads(deployed)) == normalize(json.loads(expected))

What it costs

You can't price this without your own usage numbers, so price from the model and let the trials measure it. Every figure below comes from AWS's pricing pages; check them for your Region.

Service	What you pay for	Free allowance or trial
CloudTrail	Additional event copies, S3 storage	First copy of management events free
GuardDuty	$4.00 per million CloudTrail events, $1.00 per GB flow and DNS logs (first tier, us-east-1), plus protection plans	30-day trial
Access Analyzer	Unused access: $0.20 per role or user per month	External access analysis free
Security Hub CSPM	$0.0010 per check (first 100,000)	10,000 finding ingestions a month free; 30-day trial
AWS Config	$0.003 per configuration item recorded	No free tier
Secrets Manager	$0.40 per secret per month	Parameter Store standard parameters free
AWS Budgets	Action-enabled budgets beyond the first two	Monitoring free

Pricing models only. Your total depends on activity, account count and Regions.

The only worked totals I'd quote are AWS's own: 70 principals in Access Analyzer's unused-access analysis cost $14 a month, and the AWS Config pricing page walks through its own example. For everything else, start the GuardDuty and Security Hub CSPM trials in the same week and take their real usage to whoever approves the spend.

Troubleshooting

Symptom	Likely cause	Fix
Security Hub IAM controls stuck at WARNING or DISABLED	Home Region differs from the Region recording global resources	Align the home Region with the AWS Config global-resource Region (item 14)
Access Analyzer shows no findings in a member account	Organization analyzer findings are visible only in the account that owns the analyzer	Look there; don't create a duplicate analyzer (item 9)
No GuardDuty emails after sample findings	SNS topic policy doesn't allow EventBridge to publish, or the subscription isn't confirmed	Fix the topic policy and confirm the subscription (item 8)
Duplicate CloudTrail charges after Control Tower enrollment	Old account-level trails still running alongside the organization trail	Remove the redundant trails (item 7)
EC2 launches fail after an IMDS change	Enforcement on, with templates still asking for IMDSv1	Update templates to require IMDSv2, then re-enable enforcement (item 12)
`AccessDenied` on an S3 bucket after a Region SCP	Bucket lives in a Region outside the allow list	Detach or adjust the policy, then inventory S3 in every account (item 17)
Public website bucket stopped working	Account-level Block Public Access overrides the bucket policy	Serve it through CloudFront, or exclude that account (item 10)
No anomaly alerts ever arrive	Default monitor threshold of $100 and 40% is above your spend pattern	Lower the alert threshold (item 6)

The full checklist

Copy this into your tracker; it adds three related tasks to the 19 controls. Tick an item only after its verify step passes.

☐ Root user: MFA on, no access keys, group email address
☐ Security alternate contact set to a group address
☐ People sign in through IAM Identity Center; no human IAM users with passwords
☐ Credential report reviewed; old access keys deactivated, then deleted
☐ CI pipelines on OIDC; old CI keys' last-used dates have stopped moving
☐ Monthly budget with alerts; anomaly alert threshold lowered
☐ Multi-Region (or organization) CloudTrail trail logging
☐ GuardDuty on in every allowed Region; sample finding reached the inbox; unused protection plans off
☐ Access Analyzer external access analyzer in every Region; findings reviewed
☐ S3 Block Public Access on at the account level
☐ EBS encryption by default on in every Region
☐ IMDSv2 required as the account default; enforcement planned
☐ SSH closed to the internet; Session Manager in use
☐ Secrets moved to Secrets Manager or Parameter Store; repository history scanned
☐ Security Hub CSPM on, standards chosen, IAM controls showing PASSED or FAILED
☐ AWS Backup plan running; one restore tested
☐ Organizations with separate prod and non-prod accounts
☐ Centralized root access on
☐ Baseline SCP tested on an OU, then attached; every Control Tower OU carries it
☐ Region SCP attached after a full S3 and Regional-service inventory
☐ No RDS or Aurora snapshots shared publicly
☐ Declarative policies holding S3, IMDS and public-sharing settings

Conclusion

You now have a working order for the controls that matter most from the AWS Startup Security Baseline, plus the multi-account guardrails it leaves out: identity this week, detection this month, guardrails as you add accounts. The first tier costs nothing; the second has a real but measurable bill. The decision to bring to whoever owns the budget: approve the free items now, and approve the GuardDuty and Security Hub CSPM trials with a date to review their usage.

Whatever you turn on, run its verify step. A control that is enabled but not evaluating looks exactly like one that works, right up until you need it. If you're moving to more than one account, read SCP vs RCP vs declarative policies before writing your first guardrail, and GitHub Actions OIDC trust policy for AWS before retiring your CI keys.

If you'd rather have someone walk your accounts against this list, I do short AWS security and governance reviews: written findings, prioritized fixes and the commands to verify each one. Consulting starts at $75 an hour (see rates). The first step is a free 20-minute intro call, or you can request a quote for a security review directly.

🚀 Embracing the Inevitable: Change as the Sole Constant in Software

Shahid Yousuf — Sat, 11 Nov 2023 15:08:51 +0000

In the exhilarating realm of software development, one fundamental truth prevails – change is the only constant. As technology hurtles forward, the evolution of design patterns and principles has become the compass guiding developers through the dynamic landscape of innovation

In the ever-changing landscape of software design, the evolution of patterns and principles has been pivotal. Over the years, these design foundations have adapted to meet the demands of dynamic development. Here's a glimpse into this transformative journey:

Object-Oriented Design to SOLID Principles: From the foundational principles of Object-Oriented Design (OOD), the industry embraced SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion). This shift refined the approach to building maintainable and scalable software by emphasizing modularity and flexibility.
Evolution of Gang of Four (GoF) Design Patterns: The timeless Gang of Four design patterns (like Singleton, Factory, Observer) laid the groundwork for effective software design. As development needs evolved, so did these patterns. Modern applications often incorporate variations and adaptations, showcasing the dynamic nature of design patterns to address contemporary challenges.
Introduction of Domain-Driven Design (DDD): DDD emerged as a paradigm shift, placing a strong focus on the domain itself. By aligning design with the business domain, DDD provides a strategic approach to modeling complex systems. This design evolution fosters a shared understanding between developers and domain experts, enhancing the effectiveness of software solutions.
Event-Driven Architecture (EDA): With the rise of scalable and distributed systems, Event-Driven Architecture gained prominence. Design patterns like Event Sourcing and CQRS (Command Query Responsibility Segregation) allow systems to handle events efficiently, enabling adaptability to changing business requirements and ensuring robustness in complex workflows.
Microservices and Design Patterns: The shift towards microservices architecture introduced new design challenges and opportunities. Patterns like API Gateway, Service Mesh, and Circuit Breaker became crucial for managing the intricacies of microservices. These patterns enable the construction of resilient, scalable, and independently deployable services, aligning with the need for agile development.
Responsive UI with Frontend Design Patterns: As user interfaces evolved, so did frontend design patterns. The advent of patterns like Redux for state management, and Component-Based Architecture for building reusable UI elements, showcased a shift towards more responsive and modular frontend design, accommodating the demands of modern user experiences.

In conclusion, the evolution of design patterns and principles mirrors the industry's commitment to refining approaches for building robust and adaptable software. Embracing new paradigms and adapting existing patterns ensures that software design remains responsive to the ever-changing demands of technology. 🌐