Fix Landing Zone Guardrails Not Applying to New AWS Accounts

A customer called me yesterday in a panic: they’d just vended a new account through Landing Zone, but the guardrails weren’t showing up. The account didn’t have the expected Config Rules, SCPs weren’t applied, and it was wide open. We spent 30 minutes digging through StackSet operations and realized the baseline StackSet had failed silently in the new account. In this post, I’ll walk through exactly why guardrails don’t apply to new accounts and how to force them to apply.

The Problem

You vend a new AWS account through the Landing Zone Account Vending Machine. The account is created and moved to the correct Organizational Unit (OU). However, the SCPs that are attached to that OU don’t show up in the account, and Config Rules that should be deployed via StackSet never appear.

When you check the StackSet in the management account, it shows “CURRENT” status for most accounts but “FAILED” for the new one. Or the operation completed but you notice the baseline CloudFormation stack doesn’t exist in the new account.

Issue	Symptom
StackSet failed	Operation shows “FAILED” or “OUTDATED” for new account
SCP not inherited	OU has SCP attached, but new account doesn’t show it
Config Rules missing	Account has no Config Rules despite baseline StackSet
IAM role missing	`AWSCloudFormationStackSetExecutionRole` doesn’t exist in new account

Why Does This Happen?

When Landing Zone vends a new account, it performs several steps in sequence. If one step is skipped or fails, guardrails don’t get applied:

Baseline StackSet failed to deploy: The StackSet exists in the management account but the stack instance creation failed in the new account. This is often silent—the operation completes with “OUTDATED” status but no one notices.
Account moved to OU after SCP attachment: If you move the account to an OU after the SCP was attached, the SCP doesn’t retroactively apply. SCPs are evaluated when the account is added to the OU, not continuously.
Execution role missing: StackSet uses either self-managed or service-managed permissions. If the execution role (AWSCloudFormationStackSetExecutionRole) doesn’t exist in the new account, the StackSet can’t deploy.
StackSet operation not triggered: The Account Vending Machine should trigger the baseline StackSet to deploy, but if that Lambda step fails or times out, the StackSet is never called.
Different StackSet permissions model: If you migrated from self-managed to service-managed permissions (or vice versa), newly vended accounts might not have the right trust relationship configured.

The Fix

Step 1: Check StackSet Operations

List all operations for the baseline StackSet:

aws cloudformation list-stack-set-operations \
  --stack-set-name AWS-Landing-Zone-Baseline \
  --region us-east-1 \
  --output table

Look for operations with status “FAILED” or “OUTDATED”. Find the operation ID:

aws cloudformation describe-stack-set-operation \
  --stack-set-name AWS-Landing-Zone-Baseline \
  --operation-id abc12345-1234-1234-1234-123456789012 \
  --region us-east-1

Step 2: Check If Stack Instance Exists

In the new account, verify the baseline stack is there:

aws cloudformation list-stacks \
  --region us-east-1 \
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE

If you don’t see AWS-Landing-Zone-Baseline or similar, the instance was never created.

Step 3: Verify the Execution Role

The new account needs the execution role. Check if it exists:

# Run this in the NEW account
aws iam get-role \
  --role-name AWSCloudFormationStackSetExecutionRole \
  --region us-east-1

If it doesn’t exist, you need to create it with the correct trust relationship. Download the template from the AWS Landing Zone documentation or create it manually.

Step 4: Force Re-deploy the Baseline StackSet

Create a new stack instance in the new account:

aws cloudformation create-stack-instances \
  --stack-set-name AWS-Landing-Zone-Baseline \
  --accounts 123456789012 \
  --regions us-east-1 us-west-2 \
  --operation-preferences FailureToleranceCount=0,MaxConcurrentCount=1 \
  --region us-east-1

This forces the baseline CloudFormation stack to deploy. Wait a few minutes and verify:

aws cloudformation describe-stack-instances \
  --stack-set-name AWS-Landing-Zone-Baseline \
  --stack-instance-account 123456789012 \
  --stack-instance-region us-east-1 \
  --region us-east-1

Step 5: Verify SCPs are Applied

SCPs attached to an OU apply to all accounts in that OU. List policies:

aws organizations list-policies-for-target \
  --target-id 123456789012 \
  --filter SERVICE_CONTROL_POLICY \
  --region us-east-1

If SCPs are missing, ensure the account is in the OU where the SCP is attached:

aws organizations list-parents \
  --child-id 123456789012 \
  --region us-east-1

Is This Safe?

Creating a stack instance is safe—if the instance already exists, AWS returns an error but doesn’t modify anything. You can run this multiple times without risk.

Key Takeaway

Guardrails don’t apply to new accounts when the baseline StackSet fails or the execution role is missing. Always verify that the baseline stack instance exists in the new account, and force re-deploy it if necessary.

Have questions or ran into a different Landing Zone issue? Connect with me on LinkedIn or X.