I was on a call with a customer last week when their Landing Zone pipeline suddenly failed halfway through an account provisioning. The error message in the CodePipeline console was unhelpful—just “Failed” in the Source stage. After checking S3 permissions, KMS keys, and CloudFormation stacks, we discovered it was a disabled KMS key blocking artifact decryption. In this post, I’ll walk through exactly what causes Landing Zone pipeline failures and how to fix them.

The Problem

Your AWS-Landing-Zone-Initiation or AWS-Landing-Zone-CodePipeline pipeline executes, but it fails at one of the stages: Source, Build, Deploy, or a Lambda-based custom stage. The pipeline console shows “Failed” but the error details are vague or missing. You’re not sure if it’s a permissions issue, a resource conflict, or something else entirely.

Error Stage Common Cause
Source S3 artifact bucket policy or KMS key issue
Build CodeBuild timeout or missing environment variable
Deploy CloudFormation stack in failed state
Lambda Lambda timeout or missing IAM permission

Why Does This Happen?

The Landing Zone pipeline is a sophisticated orchestration of multiple AWS services: CodePipeline, CodeBuild, Lambda, CloudFormation, and S3. Several things can break the chain:

  • S3 artifact bucket policy too restrictive: CodePipeline stores pipeline artifacts in an S3 bucket. If the bucket policy denies GetObject or PutObject permissions, the pipeline can’t read source artifacts or store outputs.
  • KMS key disabled or access revoked: If the artifact encryption key is disabled or the CodePipeline service role loses kms:Decrypt permissions, the pipeline can’t decrypt artifacts.
  • Lambda function timeout: The Account Vending Machine uses Lambda with a 15-minute timeout. Complex account creation steps (baseline StackSet deployment, cross-account role creation) can exceed this limit.
  • CloudFormation stack in failed state: If a previous pipeline execution left a CloudFormation stack in CREATE_FAILED or UPDATE_FAILED state, the next execution fails when trying to update it.
  • CodeBuild service role missing permissions: CodeBuild executes build steps with a specific IAM role. If it lacks cloudformation:*, s3:*, or organizations:* permissions, builds fail silently.

The Fix

Step 1: List Recent Pipeline Executions

Start by viewing all executions to find the failed one:

aws codepipeline list-pipeline-executions \
  --pipeline-name AWS-Landing-Zone-Initiation \
  --region us-east-1 \
  --max-results 10 \
  --output table

Find the execution ID for the failed run. Get detailed status:

aws codepipeline get-pipeline-execution \
  --pipeline-name AWS-Landing-Zone-Initiation \
  --pipeline-execution-id abc12345-1234-1234-1234-123456789012 \
  --region us-east-1

Step 2: Check the Failed Action

In the output, find which action failed. For example, if it failed in the “Deploy” stage, check that stage:

aws codepipeline get-pipeline-state \
  --name AWS-Landing-Zone-Initiation \
  --region us-east-1 \
  --query 'stageStates[?stageName==`Deploy`]'

Click the action in the console to see “Details”. If there’s a CloudWatch Logs link, click it to view logs.

Step 3: Check S3 Artifact Bucket

Verify the artifact bucket exists and has the right permissions:

# List the bucket
aws s3 ls s3://aws-landing-zone-artifacts-123456789012-us-east-1/ \
  --region us-east-1

# Check the bucket policy
aws s3api get-bucket-policy \
  --bucket aws-landing-zone-artifacts-123456789012-us-east-1 \
  --region us-east-1

The bucket policy should allow:

  • s3:GetObject (CodePipeline reading artifacts)
  • s3:PutObject (CodePipeline storing outputs)
  • s3:GetBucketVersioning (versioning support)

Step 4: Check KMS Key Status

If the bucket is encrypted with KMS, verify the key is enabled:

aws kms describe-key \
  --key-id arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012 \
  --region us-east-1

Look for "Enabled": true. If it’s disabled, enable it:

aws kms enable-key \
  --key-id arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012 \
  --region us-east-1

Also verify the CodePipeline service role has kms:Decrypt on the key:

aws kms get-key-policy \
  --key-id arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012 \
  --policy-name default \
  --region us-east-1

Step 5: Check CloudFormation Stacks

If the failure is in the Deploy stage, verify no stacks are in failed state:

aws cloudformation list-stacks \
  --stack-status-filter CREATE_FAILED UPDATE_FAILED \
  --region us-east-1

If you find a failed stack, delete it (if safe to do):

aws cloudformation delete-stack \
  --stack-name my-failed-stack \
  --region us-east-1

Step 6: Retry the Pipeline

Once you’ve fixed the underlying issue, restart:

aws codepipeline start-pipeline-execution \
  --pipeline-name AWS-Landing-Zone-Initiation \
  --region us-east-1

Monitor the execution:

aws codepipeline get-pipeline-execution \
  --pipeline-name AWS-Landing-Zone-Initiation \
  --pipeline-execution-id xyz789-xyz-xyz \
  --region us-east-1 \
  --query 'pipelineExecutionStatus'

Wait for it to show Succeeded or Failed.

Is This Safe?

Checking permissions and KMS status is always safe. Deleting a CloudFormation stack is safe only if it doesn’t contain production resources. Always verify the stack contents before deletion.

Key Takeaway

Landing Zone pipeline failures usually come down to S3 artifact bucket permissions, KMS key status, or CloudFormation stack state. Always check logs first, verify S3/KMS access, and ensure no stacks are in failed state before retrying.

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