DEV Community: Rafagross

Amazon Cognito Pricing: Tiers, MAU Counting, and the Defaults That Inflate the Bill

Rafagross — Tue, 13 Oct 2026 04:58:42 +0000

Cognito is one of those services nobody budgets for. The user pool goes in early, the free tier covers development, and for a while the line item on the bill is zero. Then the product grows, or someone runs a migration, or a batch job starts touching every user, and the Cognito charge becomes a number that needs explaining.

Usually that number has little to do with traffic. It comes from decisions made once, early, by whoever created the pool: which tier it runs on, what the application does with tokens, how users were imported, and which jobs read user data. This post goes through the billing model, the places where it surprises people, and the settings that keep it predictable.

All prices below come from the Amazon Cognito pricing page, checked on October 12, 2026. Every dollar figure is calculated from those published rates, and the inputs are shown so you can redo the math with your own numbers. Rates change, so check the page before you quote any of this in a planning document.

How Cognito Bills

User pools are billed per monthly active user (MAU), and the rate depends on the pool's feature tier. There are three.

Tier	Price per MAU above the free tier	Free tier	What it adds
Lite	$0.0055 up to 100,000 MAU, then $0.0046	10,000 MAU	Password sign-in, social and SAML/OIDC federation, MFA with SMS or authenticator apps, Lambda triggers
Essentials	$0.015	10,000 MAU	Managed login with the visual editor, passwordless and passkeys, email MFA, access token customization, refresh token rotation
Plus	$0.020	None	Threat protection: adaptive authentication, compromised credential detection, exportable user activity logs

A few things sit outside that table:

Federated users who sign in through SAML 2.0 or OIDC are priced separately: $0.015 per MAU, with a free tier of 50 MAU, whatever tier the pool is on.
Machine-to-machine authorization is billed per successful token response, with no free tier.
Identity pools are free.
SMS and email go out through Amazon SNS and Amazon SES and are billed by those services, not by Cognito.

The Default Tier Is Not the Cheap One

New user pools are created on Essentials unless you say otherwise. Essentials costs $0.015 per MAU. Lite costs $0.0055, and $0.0046 past 100,000 MAU. The default is almost three times the price of the cheapest tier.

At 100,000 MAU, after the free tier:

Tier	Calculation	Monthly
Lite	90,000 × $0.0055	$495
Essentials	90,000 × $0.015	$1,350
Plus	100,000 × $0.020	$2,000

Essentials is a reasonable choice when you use what it adds. If your application signs users in with a password or a social provider and you built your own login screens, you are probably paying for passkeys and a managed login editor that no one uses. Check the tier on existing pools before anything else in this post. It is the cheapest fix there is.

What Makes a User Billable

This is the part that produces the bills people don't expect. The pricing page defines an MAU as a user for whom your application generates an identity operation during the calendar month. The list is longer than most people assume:

sign-up, sign-in, and sign-out
token refresh
password change and attribute updates
administrative creation or update of the user
an attribute query on the user through AdminGetUser

Once a user is counted, nothing else about them adds cost that month. Subsequent sessions are free, users with no identity operation are free, and with multi-Region replication the same user is counted once across Regions.

Read the last two items on that list again. They are things your code does, not things your users do. That is where the four patterns below come from.

Batch jobs that read every user

A nightly job enriches a reporting table, or syncs user attributes to a CRM, and it calls AdminGetUser once per user. Every user it reads becomes an MAU for the month, including the ones who haven't opened the app in a year.

Take a pool with 300,000 users, of whom 60,000 actually sign in during a given month:

	Essentials	Lite
Only real users counted (60,000)	$750	$275
Nightly job reads all 300,000	$4,350	$1,415

The fix is to stop asking Cognito for data you already have. The ID token carries the user's attributes at sign-in. If a job needs attributes for users who are not signed in, keep your own copy in a table and update it from a Lambda trigger or from your application when attributes change.

The pricing page names AdminGetUser explicitly. It says nothing either way about ListUsers. I would not switch a job to ListUsers and assume it's free without watching a full month of billing first.

Token refresh on a timer

Token refresh counts as an identity operation. That's fine when a user is actually using the app, because they are already counted. It becomes a cost when the app refreshes tokens on its own. A mobile app that refreshes on launch or in a background task turns every installed copy into an MAU every month, whether the person did anything or not.

Refresh when an API call needs a fresh token, not on launch and not on a schedule.

Migrations that create everyone at once

Administrative creation counts. If you move 500,000 users into a new pool with AdminCreateUser in one month, that month bills 500,000 MAUs: $7,350 on Essentials, even if most of those users never come back.

The Migrate User Lambda trigger avoids this. Cognito calls it when a user who doesn't exist in the pool tries to sign in or reset their password, and the trigger creates the user from your old system at that moment. You only ever create, and pay for, the users who return.

There is a catch. The trigger needs the user's password, so it only fires for password flows that send it: USER_PASSWORD_AUTH, ADMIN_USER_PASSWORD_AUTH, and USER_AUTH with a password, plus forgot-password. It does not fire for SRP sign-in, which many client libraries use by default, or for passwordless sign-in. If your clients use SRP, they have to switch flows for the migration window, or the trigger never runs.

Load tests against a real pool

Synthetic users are users. A load test that signs in 50,000 test accounts after the free tier is used up costs $750 on Essentials for that month. Which leads to the next problem: the free tier probably isn't where you think it is.

The Free Tier Is Smaller Than It Looks

It is defined per account or per AWS organization. If your accounts sit in one organization, plan on staging, development, and production sharing a single 10,000 MAU allowance rather than getting 10,000 each. A load test in a sandbox account can use up the free tier that production was counting on.

Plus has none. On Plus you pay from the first user.

Federated users get 50. For users who sign in through SAML or OIDC, the free tier is 50 MAU and the rate is $0.015 on every tier, Lite included. A pool of 30,000 SSO users costs $449.25 a month. If someone estimated it with Lite's direct sign-in rate, they budgeted about $110.

Older pools have a better deal, and you can lose it. User pools created on or before November 22, 2024 that stay on Lite keep a free tier of 50,000 MAU. Accounts that had at least one MAU in the twelve months before that date can also create new Lite pools that count against the same 50,000.

That makes "upgrading" an older pool expensive in a way that isn't obvious. A legacy pool with 60,000 MAU on Lite pays for 10,000 users: $55. Move it to Essentials and it pays for 50,000: $750. Same users, about thirteen times the bill. There was a promotion that let existing accounts move to Essentials at the old price, but it ended on November 30, 2025.

Switching Tiers Mid-Month

When a pool changes tier during a month, each MAU is billed at the highest-priced tier that was enabled while that user was active.

That turns "let's try Plus for a couple of days" into an expensive experiment. Take a Lite pool with 400,000 MAU. Someone enables Plus on day 12 to evaluate threat protection and switches back on day 14. 150,000 users happened to sign in during those two days.

	Calculation	Monthly
150,000 users active on days 12 or 13	Plus, no free tier: 150,000 × $0.020	$3,000
250,000 users active only on other days	Lite: 90,000 × $0.0055 + 150,000 × $0.0046	$1,185
Total		$4,185
Same month, Lite throughout		$1,875

Evaluate tiers in a separate pool with test users. Never in the production pool.

Machine-to-Machine Tokens

For the client credentials flow, Cognito charges per successful token response: $0.00225 in US East (N. Virginia), with no free tier. The pricing page says there's no additional charge for the number of app clients registered. What moves the bill is how often they ask for a token.

The most expensive version of this is a service that requests a new token before every call instead of caching it. At 10 requests per second, that's about 25.9 million token responses in a 30-day month, or $58,320.

Even with caching, token lifetime moves the bill. Take 200 workers that each fetch a token when the previous one expires:

Access token validity	Token responses per month	Monthly
5 minutes	1,728,000	$3,888
15 minutes	576,000	$1,296
60 minutes	144,000	$324

Access token validity is configured per app client. Pick it on purpose, cache the token until shortly before it expires, and if you run many workers for the same client, share one cached token between them instead of letting each fetch its own.

Costs That Don't Show Up on the Cognito Line

SMS

SMS for MFA, sign-up confirmation, password recovery, and phone verification is sent through Amazon SNS and billed at SNS rates, which vary a lot by destination country. None of it appears in a Cognito estimate.

SMS also attracts abuse. Sign-up and forgot-password flows that send a text message can be driven by bots to generate messages to numbers the attacker profits from. Three things help:

Set the SNS account spend limit for SMS deliberately. The default is $1 a month, which protects you right up until someone raises it to fix a delivery problem and doesn't think about the new number. SNS can take a few minutes to stop sending once the limit is reached, so expect a little overshoot.
Associate AWS WAF with the user pool and rate limit the sign-up and recovery endpoints.
Prefer authenticator apps or email codes over SMS where your users allow it. Email one-time codes for MFA need Essentials or Plus, so weigh that against what you'd save on SMS.

Legacy advanced security features

Pools that enabled advanced security features (ASF) before the tiers existed still pay ASF as an add-on to Lite, with no free tier: $0.05 per MAU for the first 50,000, $0.035 for the next 50,000, and $0.02 after that.

At 100,000 MAU that is $495 for Lite plus $4,250 for ASF, $4,745 in total. Plus includes the same protections for $2,000. AWS's own example at 950,000 MAU puts Lite with ASF at $25,655 and Plus at $19,000. If any pool still has AdvancedSecurityMode set to AUDIT or ENFORCED on Lite, moving it to Plus is a straight saving.

Multi-Region replication

Replication is an add-on billed per MAU, $0.0045 on Essentials, and it is charged whether or not you ever fail over. For a pool with 500,000 MAU, that's $2,250 a month on top of a $7,350 base, about 31% more. It may be worth it. It should be a decision, not something that was switched on during a resilience review and forgotten.

Controls

Set the tier in code

Leaving the tier out means Essentials. Write it down.

resource "aws_cognito_user_pool" "main" {
  name           = "main-users"
  user_pool_tier = "LITE"
}

aws cognito-idp update-user-pool \
  --user-pool-id us-east-1_EXAMPLE \
  --user-pool-tier LITE

update-user-pool replaces any settings you don't pass with their defaults, so run it with the pool's full current configuration or make the change in your infrastructure code instead. In the AWS CDK, the property is featurePlan: cognito.FeaturePlan.LITE.

Find out what you have

This lists every pool in a Region with its tier and any legacy ASF setting:

for id in $(aws cognito-idp list-user-pools --max-results 60 \
    --query 'UserPools[].Id' --output text); do
  aws cognito-idp describe-user-pool --user-pool-id "$id" \
    --query 'UserPool.[Id,Name,UserPoolTier,UserPoolAddOns.AdvancedSecurityMode]' \
    --output text
done

User pools are regional, so repeat it with --region for every Region you use. Anything on Essentials or Plus should have a reason. Anything on Lite with ASF set to AUDIT or ENFORCED should probably be on Plus.

Put a number on it

In the console, go to Billing and Cost Management → Budgets → Create budget, choose a cost budget, and filter by the service Amazon Cognito. Set the alert a little above your normal month. Most of the patterns in this post show up as a step change, so a budget alert catches them in the month they happen rather than when the invoice lands. AWS Cost Anomaly Detection is worth enabling alongside it.

Checklist

Every user pool has its tier set in code, and the tier matches the features it uses.
No scheduled job calls AdminGetUser across the user base.
Clients refresh tokens when they need them, not on launch or on a timer.
Bulk migrations use the Migrate User trigger instead of AdminCreateUser.
Tier evaluations and load tests run against a separate pool, and nobody assumes each account has its own free tier.
M2M clients cache tokens, and the access token validity was chosen on purpose.
No pool runs Lite with legacy ASF, SMS has a spending limit, and the pool has WAF in front of sign-up.

Nearly every item on that list is a one-time decision. That's the point of making them early. A Cognito bill rarely grows because more people use the product. It grows because of what the pool was set up to count.

Sources

The Confused Deputy Problem in AWS: ExternalId, aws:Source* Keys, and RCPs

Rafagross — Thu, 08 Oct 2026 21:33:31 +0000

Most IAM incidents people talk about start with a leaked access key or a wildcard that was too generous. The confused deputy problem is different. Nothing leaks. Every API call is authorized. CloudTrail shows a party you trust doing exactly what your policy lets it do. The only thing wrong is who asked it to.

That is what makes it easy to miss in a review. This post covers the two variants AWS documents, cross-account and cross-service, the policy conditions that fix each one, and the details that decide whether the fix works in production.

The Problem

A confused deputy is a privileged party that gets talked into using its privileges for someone who doesn't have them. In AWS terms, an entity that is not allowed to perform an action coerces a more privileged entity into performing it.

The root cause is the same in every version of it. An IAM policy answers one question: who is calling? It does not ask on whose behalf the caller is acting, unless you write a condition that does.

	Cross-account	Cross-service
The actor	Another customer of the same vendor	Any account that can configure the calling service
The deputy	The vendor's AWS account	An AWS service principal such as `cloudtrail.amazonaws.com`
What the policy checks	Is the caller the vendor's account?	Is the caller that service?
What it never checks	Which customer the vendor is acting for	Which account or resource the service is acting for
Control	`sts:ExternalId`	`aws:SourceArn`, `aws:SourceAccount`, `aws:SourceOrgID`, `aws:SourceOrgPaths`

Cross-Account: The Vendor as Deputy

If you have onboarded a cost, monitoring, or security posture SaaS, you know the routine. You create a role in your account, trust the vendor's AWS account, and paste the role ARN into their console. From then on the vendor calls sts:AssumeRole and reads what the role allows.

The vendor does this for every customer, from the same AWS account. So picture another customer of that vendor, tenant B, pasting your role ARN into their own onboarding form. A role ARN is an identifier, not a credential. It shows up in tickets, in infrastructure code, in screenshots. Learning or guessing one is not hard.

Now look at the trust policy most onboarding guides hand you:

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

When the vendor assumes the role for tenant B, STS checks whether the caller is in the principal (yes, it is the vendor's account), whether the action is allowed (yes), and whether there is a condition to satisfy (there is none). The result is an Allow. The request the vendor sends for tenant B is identical to the one it sends for you. The policy has nothing to tell them apart with.

The Fix: sts:ExternalId

The external ID adds the missing fact to the request. The vendor assigns a unique value to each customer and passes that value on every AssumeRole call it makes for that customer. Your trust policy requires yours:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::999988887777:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "7f3c2b1e-58d4-4c0a-9e6f-b2d1c4a7a91e" }
  }
}

And the vendor's side of it:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/vendor-readonly \
  --role-session-name tenant-a-sync \
  --external-id 7f3c2b1e-58d4-4c0a-9e6f-b2d1c4a7a91e

When tenant B submits your role ARN, the vendor sends tenant B's external ID, because that is who triggered the work. It doesn't match the condition on your role, no statement allows the call, and STS returns AccessDenied.

A few things about external IDs that are worth getting right:

The vendor generates it, not you. If customers could pick their own, tenant B would simply pick yours. AWS recommends one random string per customer AWS account.
It is not a secret. Anyone with permission to view the role can read it. Its job is to be unique per customer and outside the customer's control, not to be hidden.
Format. Between 2 and 1,224 characters, alphanumeric, no whitespace, plus a handful of symbols such as + = , . @ : / -.
If you are the vendor, test at onboarding. Try to assume the customer's role with and without the correct external ID. If it works without it, the trust policy isn't enforcing anything and you should not store that ARN.

The whole scheme depends on the vendor always sending the ID of the customer that triggered the request. A condition in your trust policy only does its job if the vendor does theirs. That's a fair question to ask during vendor review.

Cross-Service: An AWS Service as Deputy

The second variant has no third party at all. The deputy is an AWS service.

Many services reach into your resources using their service principal. CloudTrail writing to a central log bucket is the textbook case. The bucket policy has an Allow for cloudtrail.amazonaws.com, and that feels specific. It isn't. That principal is CloudTrail for every AWS account, not CloudTrail for yours.

So an account you have never heard of can create a trail, name your bucket as the destination, and CloudTrail will write there, because your bucket policy told S3 that CloudTrail is welcome.

The useful part is that the service already tells the target on whose behalf it is acting. Requests made by AWS service principals carry that context in global condition keys. Your policy only has to test it.

Key	The service is acting on behalf of	Reach for it when
`aws:SourceArn`	One specific resource	You know the exact ARN: one trail, one topic, one fleet
`aws:SourceAccount`	Any resource in one account	The ARN has no account ID, or many resources share one grant
`aws:SourceOrgID`	Any account in one organization	A central resource serves every account, or you enforce it in an RCP
`aws:SourceOrgPaths`	Accounts under an Organizations path	Only part of the organization, such as one OU, should reach it

CloudTrail to S3: pin the bucket to one trail

This is the statement the CloudTrail documentation recommends, with aws:SourceArn set to the trail:

{
  "Sid": "AWSCloudTrailWrite",
  "Effect": "Allow",
  "Principal": { "Service": "cloudtrail.amazonaws.com" },
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::example-org-trail-logs/AWSLogs/111122223333/*",
  "Condition": {
    "StringEquals": {
      "s3:x-amz-acl": "bucket-owner-full-control",
      "aws:SourceArn": "arn:aws:cloudtrail:us-east-1:111122223333:trail/org-trail"
    }
  }
}

Put the same aws:SourceArn condition on the s3:GetBucketAcl statement next to it. For an organization trail, the ARN is the trail in the management account, not in the member accounts.

S3 events to Lambda: when the ARN has no account ID

{
  "Sid": "allow-s3",
  "Effect": "Allow",
  "Principal": { "Service": "s3.amazonaws.com" },
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-2:111122223333:function:ingest",
  "Condition": {
    "StringEquals": { "aws:SourceAccount": "111122223333" },
    "ArnLike": { "aws:SourceArn": "arn:aws:s3:::example-bucket" }
  }
}

Both keys are there for a reason. An S3 bucket ARN carries no account ID, and bucket names are global. If that bucket is ever deleted, another account can create one with the same name, and its events would still match aws:SourceArn. aws:SourceAccount ties the grant to the owner, not just the name. The CLI makes this easy to do properly: aws lambda add-permission takes both --source-arn and --source-account.

Service roles need it too

The trust policy of a role that a service assumes is the same kind of grant. Without a condition it says only "Systems Manager may assume me." The Systems Manager documentation recommends scoping it:

{
  "Effect": "Allow",
  "Principal": { "Service": "ssm.amazonaws.com" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "aws:SourceAccount": "111122223333" },
    "ArnLike": { "aws:SourceArn": "arn:aws:ssm:us-east-1:111122223333:*" }
  }
}

When you don't know the full ARN, or several resources use the role, keep the account and Region and use a wildcard for the rest.

Enforcing It Org-Wide with an RCP

Fixing bucket policies one by one doesn't scale, and it does nothing for the bucket someone creates next month. A resource control policy applies the rule centrally. This is the example from the IAM documentation:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RCPEnforceConfusedDeputyProtectionForS3",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": { "aws:SourceOrgID": "o-exampleorgid" },
        "Null": { "aws:SourceAccount": "false" },
        "Bool": { "aws:PrincipalIsAWSService": "true" }
      }
    }
  ]
}

The three conditions are evaluated together, and each one has a job:

aws:PrincipalIsAWSService limits the deny to calls made by service principals. Your own users and roles are not affected.
The Null check on aws:SourceAccount applies the deny only when the service sends that key, so integrations that don't use it keep working.
aws:SourceOrgID is the actual test: deny when the service is not acting for your organization.

The Null check uses aws:SourceAccount rather than aws:SourceOrgID on purpose. If the request comes from an account that belongs to no organization, aws:SourceOrgID is absent. Testing for the account key keeps the control in force for that case.

Production Gotchas

An RCP never grants access. It sets a ceiling. Each resource policy still needs its own Allow for the service principal.
RCPs skip the management account. Resources there still need the condition in their own policies. RCPs also don't change the permissions of service-linked roles and don't apply to AWS managed KMS keys.
RCPs cover supported services only. The list has grown well past the original S3, STS, KMS, SQS, and Secrets Manager, but check it before you rely on one.
Both keys in one statement must agree. If the aws:SourceArn value contains an account ID, it has to be the same account as aws:SourceAccount.
Not every integration sends these keys. Requiring a key that a service doesn't populate breaks that integration. The service's own documentation says which keys it supports.
Some services have their own mechanism. AWS KMS, for example, uses the encryption context together with the key grant.
The external ID is only as good as the vendor's handling of it. A vendor that lets customers type their own, or that sends a shared value, has not solved anything.

Finding What You Already Have

A quick way to list roles that trust an AWS principal without requiring an external ID:

aws iam list-roles --output json | jq -r '.Roles[]
  | select(any(.AssumeRolePolicyDocument.Statement[];
      .Effect == "Allow" and (.Principal.AWS? != null)
      and ((.Condition // {} | tostring) | contains("sts:ExternalId") | not)))
  | .Arn'

This is a starting point, not an audit. Roles trusted by your own accounts will show up and are usually fine. Any role that trusts a vendor's account should carry the condition.

Two more places to look:

IAM Access Analyzer. External access findings cover role trust policies, S3 buckets, KMS keys, Lambda functions, SQS queues, and SNS topics, among others. Treat each finding as a prompt to read the policy's conditions.
CloudTrail. A cross-account AssumeRole is logged in both accounts, and sharedEventID ties the two records together. That is how you confirm which external principal used a role, and when.

Checklist

Every trust policy for a vendor account requires an sts:ExternalId that the vendor issued.
Every resource policy and service-role trust policy that names a service principal has an aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, or aws:SourceOrgPaths condition.
An RCP enforces aws:SourceOrgID for the services that support it, and the management account is handled separately.
For each service in use, the documentation confirms which keys it supports and whether it has its own mechanism.

The principle underneath all four is short. A policy that trusts a deputy should also say on whose behalf the deputy may act.

Sources

AWS Organizations in Production: Structure, SCP Evaluation, and Landing Zone Gotchas

Rafagross — Sun, 27 Sep 2026 05:20:57 +0000

Most teams adopt AWS Organizations for consolidated billing and stop there. The real value is the control plane: a tree of accounts where guardrails attached at the top apply to everything below. That same tree is also where most "why is this denied?" tickets come from, because the evaluation rules are less intuitive than IAM alone.

This post covers the structure, how policies are evaluated, and the gotchas worth knowing before you run it in production.

The Account Is the Boundary

An AWS account is the hard boundary for resources, security, and billing. IAM manages identities inside an account. Organizations manages the accounts themselves.

That distinction drives the whole multi-account model: separate accounts give you blast-radius isolation, clean cost attribution, and a place to attach controls that no one inside the account can override.

Structure

An organization has:

One management account. It owns the organization and is the payer account. It should run org and billing tasks only. No workloads.
One root. The top of the tree. Policies attached here apply to every account.
Organizational units (OUs). Containers for accounts. OUs can nest up to five levels deep under the root.
Member accounts. Where workloads, logging, and security tooling live.
Policies. Attached at the root, an OU, or an individual account.

A common baseline layout:

OU	Accounts	Purpose
Security	Log Archive, Security Tooling (Audit)	Centralized logs, delegated admin for security services
Infrastructure	Network, Shared Services	Transit, DNS, shared tooling
Workloads	Prod, NonProd	Application accounts, grouped by lifecycle
Sandbox	Per-developer or per-team	Experimentation with looser controls
Suspended	Accounts pending closure	Deny-all quarantine

Tip: Design OUs around the controls and lifecycle you want to apply, not around the org chart. Teams get reorganized; "prod needs stricter guardrails than sandbox" does not change.

Enable All Features

Organizations has two feature sets. Consolidated-billing mode only merges invoices. All features adds the authorization policies (SCPs, RCPs), management policies (tag, backup, EC2), trusted access for service integrations, and delegated administrators. If you are building a landing zone, you need all features.

Policy Types That Matter Day to Day

Policy	What it does
SCP (service control policy)	Sets the maximum permissions for IAM users and roles in member accounts. Grants nothing on its own.
RCP (resource control policy)	Sets the maximum permissions on resources in member accounts (S3, KMS, Secrets Manager, SQS, and many more), regardless of who is calling. Grants nothing on its own.
Tag policy	Standardizes tag keys and values so cost allocation and ABAC stay consistent.
Backup policy	Deploys AWS Backup plans centrally across accounts and Regions.
EC2 policy (declarative)	Enforces EC2, VPC, and EBS baselines org-wide, such as IMDS defaults, AMI and EBS snapshot block public access, serial console access, and VPC Block Public Access. The configuration is maintained even as the service adds new APIs.

How Inheritance Actually Works

This is the part that trips people up.

A Deny is simple: attach it anywhere and it applies to everything below that point.

An Allow is not inherited the way people expect. For an action to be permitted in an account, an SCP must allow it at every level from the root down to the account: the root, each OU in the path, and the account itself. If any level is missing the Allow, the action is implicitly denied, even if an IAM policy in the account grants *:*.

Root            FullAWSAccess        -> allows *
  OU Workloads  AllowOnlyApprovedSvc -> allows ec2:*, s3:*, ... (no dynamodb:*)
    Prod acct   FullAWSAccess        -> allows *

Result in Prod: dynamodb:* is denied. The OU level never allowed it.

This is why the default FullAWSAccess SCP exists at every level. If you replace it with an allow-list at the OU, that allow-list becomes the ceiling for every account underneath.

Most common SCP incident: Someone detaches FullAWSAccess from an OU while testing an allow-list SCP, and every account under that OU loses access to services that weren't on the list. Prefer deny-list SCPs (explicit Deny statements on top of FullAWSAccess) unless you have a specific reason to allow-list.

How a Request Is Evaluated

For a principal in a member account, access requires an Allow from every applicable layer:

Identity-based policy on the user or role must allow the action.
SCPs in the account's path must allow it.
RCPs in the path must allow it for the target resource (if the service supports RCPs).
Permission boundaries, session policies, and resource-based policies still apply as usual.

An explicit Deny at any layer wins. SCPs and RCPs only ever reduce what is possible; they never grant access.

A practical consequence: when you debug an AccessDenied in a member account and the IAM policy looks correct, check the SCPs on every node in the account's path, not just the ones attached directly to the account.

Landing Zone Pattern

The goal is to separate the governance plane from workloads:

Management account: org and billing only. Tightly restricted human access.
Security OU: Log Archive receives org-wide CloudTrail and Config data. Security Tooling (Control Tower calls it Audit) is the delegated administrator for GuardDuty, Security Hub, and similar services.
Infrastructure OU: networking and shared services.
Workloads OU: prod and non-prod split so guardrails can differ.

AWS Control Tower orchestrates this on top of Organizations: Account Factory for provisioning, managed controls (preventive via SCPs/RCPs, detective via AWS Config, proactive via CloudFormation hooks), and drift detection. If you manage infrastructure as code, Account Factory for Terraform (AFT) provisions accounts through a Terraform pipeline.

Operating Lifecycle

Identity: IAM Identity Center for human access, cross-account roles for automation, least privilege throughout.
Provisioning: Account Factory, AFT, or the Organizations API. Never click-ops accounts in production.
Baseline: logging, Config, security services, and networking applied from day one, typically via StackSets or Control Tower.
Guardrails: preventive, detective, and proactive controls, plus drift detection.
Lifecycle: move accounts between OUs as their purpose changes. To retire one, move it to a Suspended OU with a deny-all SCP, then close it. A closed account can be reopened during the post-closure period (90 days).

Production Gotchas

SCPs and RCPs never restrict the management account. Anything you run there is outside your guardrails. That is the main reason to keep workloads out of it.
SCPs don't affect service-linked roles. AWS services acting through service-linked roles are not limited by your SCPs.
SCPs do apply to delegated administrator accounts. They are member accounts. Make sure your guardrails don't block the security services you delegated.
OUs nest at most five levels deep. Deep hierarchies are also harder to reason about during an incident. Keep it shallow.
Delegate security services to the Audit/Security Tooling account instead of administering them from the management account.
Limits: SCP documents max out at 10,240 characters, and each root, OU, or account can have up to 10 SCPs attached. Plan statement consolidation early.

Quick Inventory Commands

# Root ID and enabled policy types
aws organizations list-roots

# All accounts in the org
aws organizations list-accounts

# OUs under a parent (root or OU)
aws organizations list-organizational-units-for-parent --parent-id r-examplerootid

# SCPs attached to a specific target
aws organizations list-policies-for-target \
  --target-id 123456789012 \
  --filter SERVICE_CONTROL_POLICY

Run these from the management account or a delegated administrator.

Sources

EC2 Instance Unreachable via SSM Session Manager

Rafagross — Sun, 13 Sep 2026 03:12:04 +0000

Summary

This runbook resolves the situation where an EC2 instance is running and visible in the console but either does not appear in the Systems Manager Fleet Manager inventory, or returns a connection error when you attempt to start a Session Manager session.

When to Use This Runbook

Use this runbook when you observe any of the following:

Session Manager shows "Instance not connected" or "Unable to start session"
The instance does not appear in Systems Manager → Fleet Manager → Managed Nodes
ssm:StartSession returns TargetNotConnected
A previously working instance stopped responding to SSM after a restart, IAM change, or network modification

Step 1: Verify Instance State

Console path: EC2 → Instances → [Instance ID]

Confirm the instance is in running state and that both Status checks show 2/2 passed.

If status checks are failing, stop here and use the EC2 Status Check runbook. SSM is irrelevant if the instance itself is impaired.

Expected result: Instance state = running, 2/2 status checks passed.

Step 2: Check SSM Managed Node Status

Console path: Systems Manager → Fleet Manager → Managed nodes

Search for the instance ID. If it does not appear, or shows Connection Lost, the issue is one of: missing IAM role, stopped SSM agent, or blocked network path.

Expected result: Instance appears with status Online. If missing or Connection Lost, continue to Step 3.

Step 3: Verify IAM Instance Profile

Console path: EC2 → Instances → [Instance ID] → Security tab → IAM Role

The instance must have an IAM role attached with the AmazonSSMManagedInstanceCore managed policy (or equivalent custom policy granting the minimum SSM actions).

Minimum required IAM actions if using a custom policy:

ssm:UpdateInstanceInformation
ssm:ListInstanceAssociations
ssm:DescribeInstanceProperties
ssm:DescribeDocumentParameters
ssmmessages:CreateControlChannel
ssmmessages:CreateDataChannel
ssmmessages:OpenControlChannel
ssmmessages:OpenDataChannel
ec2messages:AcknowledgeMessage
ec2messages:DeleteMessage
ec2messages:FailMessage
ec2messages:GetEndpoint
ec2messages:GetMessages
ec2messages:SendReply

Note: IAM propagation delay:
IAM role changes applied to a running instance take effect on next SSM agent heartbeat, typically within 2-3 minutes. If you just updated the role, wait 5 minutes and re-check Fleet Manager before continuing.

Expected result: IAM role attached with AmazonSSMManagedInstanceCore or equivalent. If missing, attach the role and wait 5 minutes.

Step 4: Check SSM Agent on the Instance

Console path: EC2 → Instances → [Instance ID] → Actions → Monitor and troubleshoot → Get system log

Look for lines referencing amazon-ssm-agent. A healthy agent shows:

amazon-ssm-agent.service: active (running)

Errors to look for:

Failed to start Amazon SSM Agent — agent start failure, likely OS-level issue
Error connecting to endpoint — network path problem (proceed to Step 5)
No SSM lines at all — agent not installed or not running

If the agent is not running, you can use EC2 Run Command with AWS-RunShellScript to restart it — but only if the instance is already registered (partial connectivity). If it's fully unreachable, use EC2 Instance Connect or serial console (if available) to restart manually.

Expected result: SSM agent running. No connection errors.

Step 5: Diagnose the Network Path

SSM Session Manager requires outbound HTTPS (port 443) from the EC2 instance to three regional endpoints:

Endpoint	Purpose
`ssm.{region}.amazonaws.com`	Agent registration
`ssmmessages.{region}.amazonaws.com`	Session data channel
`ec2messages.{region}.amazonaws.com`	EC2 message delivery

For private instances (no NAT Gateway, VPC endpoint required):

Console path: VPC → Endpoints

Verify that all three interface endpoints exist, are associated with the correct VPC, and have status available. Check that the endpoint security group allows inbound HTTPS from the instance's security group.

Console path: VPC → Security Groups → [Endpoint SG]

Inbound rule required:

Type: HTTPS (443)
Source: [Instance security group ID]

For instances with NAT Gateway:

Console path: VPC → Route Tables → [Instance subnet's route table]

Confirm a 0.0.0.0/0 route pointing to the NAT Gateway exists and the NAT Gateway is in available state.

Note:
If the instance has a public IP and is in a public subnet with an IGW route, outbound port 443 directly to AWS endpoints is sufficient. No VPC endpoints needed in that case.

Expected result: Either VPC endpoints present and available, or valid NAT/IGW route exists. Instance SG allows outbound 443.

Step 6: Check Instance Security Group Outbound Rules

Console path: EC2 → Instances → [Instance ID] → Security tab → Security groups → [SG ID] → Outbound rules

Confirm outbound HTTPS is allowed. The default AWS SG allows all outbound traffic. If rules have been tightened:

Type: HTTPS (443)
Destination: 0.0.0.0/0

OR (preferred, more restrictive):

Type: HTTPS (443)
Destination: [VPC endpoint prefix list or specific endpoint IPs]

Expected result: Outbound 443 allowed from instance security group.

Step 7: Force SSM Agent Re-Registration (Last Resort)

If all above checks pass but the instance still doesn't appear in Fleet Manager, the agent's registration may be stale (common after AMI snapshots or instance cloning).

Use EC2 Run Command with AWS-RunShellScript:

# Amazon Linux 2 / AL2023
sudo systemctl stop amazon-ssm-agent
sudo rm -rf /var/lib/amazon/ssm/registration
sudo systemctl start amazon-ssm-agent
sudo systemctl status amazon-ssm-agent

Wait 2 minutes, then re-check Fleet Manager.

Validation Checks

Check	How to Verify	Expected Result
Instance in Fleet Manager	SSM → Fleet Manager → search instance ID	Status: Online
Session starts	SSM → Session Manager → Start session → select instance	Terminal opens
Agent heartbeat	CloudWatch Logs → /aws/ssm/amazon-ssm-agent	Recent heartbeat log entries

Rollback

No destructive changes are made by this runbook. If you attached a new IAM role that you want to remove:

Console path: EC2 → Instances → [Instance ID] → Actions → Security → Modify IAM role → No role

Escalation

Condition	Next Action
All steps pass but instance still unreachable	Open AWS Support case — provide instance ID, region, VPC endpoint IDs, and CloudWatch agent logs
Agent crashes immediately on start	Check OS disk space (`df -h`), memory, and `/var/log/amazon/ssm/amazon-ssm-agent.log` for errors
Instance in private subnet, no VPC endpoints, no NAT	Network path is broken by design — work with network team to add VPC endpoints or NAT