AWS Organizations and SCPs

Sign in and set the sandbox email address:

cd C:\aws-lab
aws login --profile saat-admin
$env:AWS_PROFILE = 'saat-admin'
$sandboxEmail = 'you+saat-sandbox@gmail.com'
$ssoUser = 'yourname'

1Create the organization and a Sandbox OU

Paste this whole block:

$org = aws organizations create-organization --feature-set ALL --query Organization.Id --output text
$root = aws organizations list-roots --query "Roots[0].Id" --output text
aws organizations enable-policy-type --root-id $root --policy-type SERVICE_CONTROL_POLICY | Out-Null
$ou = aws organizations create-organizational-unit --parent-id $root --name Sandbox --query OrganizationalUnit.Id --output text
aws organizations list-policies-for-target --target-id $ou --filter SERVICE_CONTROL_POLICY --query "Policies[].Name" --output text
"$org $root $ou"

You should see something like this:

FullAWSAccess
o-a1b2c3d4e5 r-ab12 ou-ab12-c3d4e5f6

Every new OU and account inherits FullAWSAccess, the “allow everything” SCP. That is why turning SCPs on doesn’t break anything until you add a Deny. AWS also sends an email asking you to verify the management account’s address; do it, as some organization features need it.

2Create the sandbox account and reach it

Paste this whole block (account creation takes a few minutes):

$req = aws organizations create-account --email $sandboxEmail --account-name saat-sandbox --query CreateAccountStatus.Id --output text
do { Start-Sleep 15; $st, $member = (aws organizations describe-create-account-status --create-account-request-id $req --query "CreateAccountStatus.[State,AccountId]" --output text) -split '\s+' } until ($st -ne 'IN_PROGRESS')
"$st $member"
aws organizations move-account --account-id $member --source-parent-id $root --destination-parent-id $ou
aws configure set role_arn "arn:aws:iam::$($member):role/OrganizationAccountAccessRole" --profile saat-sandbox
aws configure set source_profile saat-admin --profile saat-sandbox
aws configure set region ap-south-1 --profile saat-sandbox
Start-Sleep 30
aws sts get-caller-identity --profile saat-sandbox --query Arn --output text

You should see something like this:

SUCCEEDED 444455556666
arn:aws:sts::444455556666:assumed-role/OrganizationAccountAccessRole/botocore-session-1760975678

The organization created the account with a role that trusts the management account. That role has AdministratorAccess in the sandbox, which is exactly why the management account must be protected so carefully.

3Lock the sandbox to Mumbai

Paste this whole block:

@'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideMumbai",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "organizations:*", "sts:*", "sso:*", "identitystore:*", "account:*",
        "support:*", "budgets:*", "ce:*", "billing:*", "pricing:*", "health:*", "trustedadvisor:*",
        "cloudfront:*", "route53:*", "route53domains:*", "globalaccelerator:*", "waf:*",
        "s3:GetAccountPublicAccessBlock", "s3:ListAllMyBuckets"
      ],
      "Resource": "*",
      "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "ap-south-1" ] } }
    }
  ]
}
'@ | Set-Content scp-regions.json
@'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectBaseline",
      "Effect": "Deny",
      "Action": [ "organizations:LeaveOrganization", "cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "guardduty:DeleteDetector" ],
      "Resource": "*"
    }
  ]
}
'@ | Set-Content scp-protect.json
$scpRegions = aws organizations create-policy --name deny-outside-mumbai --type SERVICE_CONTROL_POLICY --description "Only ap-south-1, except global services" --content file://scp-regions.json --query Policy.PolicySummary.Id --output text
$scpProtect = aws organizations create-policy --name protect-baseline --type SERVICE_CONTROL_POLICY --description "Keep CloudTrail, GuardDuty and org membership" --content file://scp-protect.json --query Policy.PolicySummary.Id --output text
aws organizations attach-policy --policy-id $scpRegions --target-id $ou
aws organizations attach-policy --policy-id $scpProtect --target-id $ou
Start-Sleep 30
aws ec2 describe-vpcs --region ap-south-1 --profile saat-sandbox --query "length(Vpcs)"
aws ec2 describe-vpcs --region us-east-1 --profile saat-sandbox
aws ec2 describe-vpcs --region us-east-1 --query "length(Vpcs)"

You should see something like this:

1
An error occurred (UnauthorizedOperation) when calling the DescribeVpcs operation: You are not authorized to perform this operation. User: arn:aws:sts::444455556666:assumed-role/OrganizationAccountAccessRole/botocore-session-1760975678 is not authorized to perform: ec2:DescribeVpcs with an explicit deny in a service control policy
1

Three results tell the whole story: the sandbox can use Mumbai, the sandbox’s own administrator role is refused in us-east-1 by the SCP, and your management account (the last line) is not affected at all.

4Sign in to the sandbox with IAM Identity Center

Enabling the organization instance of Identity Center and creating your first user are done in the console:

1. Open IAM Identity Center in ap-south-1 and choose Enable, keeping the organization instance option.
2. Choose Users, then Add user. Use the username you set in $ssoUser and an email you can open, and send the invitation.
3. Accept the invitation email, set a password and register an MFA device.

Then paste this whole block to give that user admin access to the sandbox only:

$inst, $idStore = (aws sso-admin list-instances --query "Instances[0].[InstanceArn,IdentityStoreId]" --output text) -split '\s+'
$userId = aws identitystore get-user-id --identity-store-id $idStore --alternate-identifier "UniqueAttribute={AttributePath=userName,AttributeValue=$ssoUser}" --query UserId --output text
$ps = aws sso-admin create-permission-set --instance-arn $inst --name SandboxAdmin --session-duration PT1H --query PermissionSet.PermissionSetArn --output text
aws sso-admin attach-managed-policy-to-permission-set --instance-arn $inst --permission-set-arn $ps --managed-policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws sso-admin create-account-assignment --instance-arn $inst --target-id $member --target-type AWS_ACCOUNT --permission-set-arn $ps --principal-type USER --principal-id $userId --query AccountAssignmentCreationStatus.Status --output text
"Start URL: https://$idStore.awsapps.com/start"

You should see something like this:

IN_PROGRESS
Start URL: https://d-9a8b7c6d5e.awsapps.com/start

Now create an SSO profile. Answer the prompts with the start URL above, Region ap-south-1, and pick saat-sandbox and SandboxAdmin when asked:

aws configure sso --profile saat-sso-sandbox
aws sts get-caller-identity --profile saat-sso-sandbox --query Arn --output text
aws ec2 describe-vpcs --region us-east-1 --profile saat-sso-sandbox --query "length(Vpcs)"

You should see something like this (the last command is refused by the SCP, as before):

arn:aws:sts::444455556666:assumed-role/AWSReservedSSO_SandboxAdmin_1a2b3c4d5e6f7a8b/yourname
An error occurred (UnauthorizedOperation) when calling the DescribeVpcs operation: ... with an explicit deny in a service control policy

A person, one sign-in with MFA, temporary credentials for one hour, and an SCP that applies whatever permission set they have. This is how most companies run AWS access. Use aws sso login --profile saat-sso-sandbox when the session expires.

The rest of the course keeps using saat-admin in your main account so earlier lessons stay valid.

✅ Checkpoint: Your organization has a Sandbox OU with saat-sandbox, the sandbox is refused in us-east-1 by an SCP while your management account is not, and you can sign in to the sandbox through Identity Center. Keep everything for the break lab.