AWS Exceptions on New Accounts: What AccessDenied, OptInRequired, and LimitExceeded Actually Mean
New AWS accounts throw predictable exceptions before they are fully ready. Learn why AccessDenied, OptInRequired, InvalidClientTokenId, LimitExceeded, and PendingVerification appear, and how to fix them before they stall production.
When you create a new AWS account, the console says "active" long before every API call will succeed. The account exists, but identity propagation, region opt-in, billing verification, and default service quotas are still settling. The result is a stream of structured exceptions that look like code bugs but are usually account-state problems.
Why new accounts fail differently
A new AWS account is not a blank canvas. It is a partially provisioned identity in a global control plane. AWS activates the root account and attaches a default payment method, but it does not automatically:
Enable every region for your account.
Opt you in to services like SNS, SES, or Marketplace.
Grant high default quotas for EC2, Lambda, or spot instances.
Provision a default VPC in every region, especially in newer opt-in regions.
Propagate new IAM credentials immediately.
That means the same Terraform or CLI command can fail with a different exception depending on account age, region, and whether the caller is root, an IAM user, or an SSO role.
Read the exception, not the generic message
AWS error responses include an error code, a request ID, and a human-readable message. The code is the reliable part. For example:
`InvalidClientTokenId`: the access key ID or token is malformed, disabled, or not yet visible.
`AccessDenied`: the caller identity exists but lacks an allow policy.
`OptInRequired`: the service is not enabled in the current region.
`SubscriptionRequiredException`: the account has not subscribed to the product or service.
`LimitExceeded`: a default quota or rate limit was hit before any resource could be created.
`PendingVerification`: the account itself is still under risk or billing review.
Common new-account exceptions and fixes
1. InvalidClientTokenId / UnrecognizedClientException
This almost always means the credential is not valid for the partition or region. Check:
Are you using the right access key? Run `aws sts get-caller-identity`.
Are you pointed at the right partition (aws, aws-cn, aws-us-gov)?
Did you just create the access key? Wait a few seconds and retry. Credential propagation is eventually consistent.
2. AccessDenied before any resources exist
New accounts in AWS Organizations may have service control policies (SCPs) that deny all actions until you move the account into the correct organizational unit. IAM Identity Center permission sets can also start empty. If the session policy is empty, every action is denied. The fix is rarely in the application code; it is in the account's policy stack.
3. OptInRequired / SubscriptionRequiredException
Some services and regions are opt-in. New AWS accounts may need to enable regions like Asia Pacific (Hyderabad) or Europe (Zurich) before you can call their APIs. Services like SNS can return `OptInRequired` until you complete the console opt-in. Use `aws ec2 describe-regions --all-regions` to see enabled regions and [manage opt-in regions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html).
4. LimitExceeded / Throttling
A brand new account often starts with the lowest possible quota. SES is in sandbox mode, Lambda concurrency may be 10, and EC2 vCPU limits may be 0 in less common instance families. Request quota increases early and build retries into your bootstrapping scripts. See [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
5. PendingVerification
If your phone, tax, or billing verification is incomplete, AWS can throttle or block service provisioning. The account may be "active" in the console but return `PendingVerification` on billing-dependent APIs. Check the [account verification flow](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-verification.html).
Debugging workflow
1. Run `aws sts get-caller-identity` to confirm identity, account ID, and partition.
2. Check the error code in the response, not just the message.
3. Compare the code against the [AWS error code documentation](https://docs.aws.amazon.com/general/latest/gr/aws-error-codes.html).
4. Check the AWS Health Dashboard and Service Health for region-level anomalies.
5. Check your SCP, IAM policy, and session policy boundaries.
6. Run the same call with `--debug` or CloudTrail to capture the exact request context.
Building for new-account bootstrapping
Treat the first 24-48 hours of an AWS account as an eventually consistent system. Use idempotent creation, retry on `Throttling`, `LimitExceeded`, and `PendingVerification`, and fail loud on `AccessDenied`. If you are using infrastructure as code, make sure your Terraform or CloudFormation stacks distinguish between an API error that requires a quota increase and one that requires an IAM policy change.
Sapior captures those exceptions from your deployment pipeline and replays the failing call with the same credential context, so you can see whether the error is an account-state issue or a policy mistake before it stalls a release.
Bottom line
Most AWS exceptions on new accounts are configuration and account-state signals, not application defects. Read the code, verify the identity, check the region and quota, and then decide whether to wait, opt in, or ask AWS for more capacity.