
AWS Landing Zone Disaster: Learn From My Costly Mistakes (Entra ID & Security Woes)
Don't make the same mistakes I did! Building an AWS Landing Zone can quickly turn into a multi-day headache. As an AWS Community Builder, I learned the hard way about service quotas, SCP limits, and account lifecycle complexities while trying to integrate with Entra ID. This is my cautionary tale to help you avoid the pitfalls.
The Dream: Streamlined AWS Access with Entra ID and Trusted Enclaves
My goal was simple: Build a secure AWS Landing Zone using Trusted Enclaves, integrated with Entra ID for seamless access management. I wanted a robust and secure environment, leveraging AWS's best practices for multi-account management, all while documenting the journey for others. Little did I know the number of roadblocks I was about to face!
The Initial Plan: Seemingly Simple
My plan of attack looked straightforward:
- Utilize my AWS Community Builders credits.
- Deploy AWS Landing Zone Accelerator with Control Tower.
- Apply the Trusted Enclaves configuration.
- Connect to Entra ID for smooth user authentication.
What could go wrong? Plenty, as it turns out.
Day 1: Quota Limbo – The First Sign of Trouble
The first hurdle was AWS service quotas. Before I could even begin, I needed to increase the number of accounts allowed in my Organization. A 12-hour wait for a quota increase request was just the beginning.
Takeaway: Request quota increases well in advance of starting your AWS Landing Zone deployment.
Day 2: SCP Nightmares and Broken Trust
After successfully deploying Stage One, I applied the Trusted Enclaves configuration, triggering my first major crisis. The configuration attempted to create a new OU and apply a 6th Service Control Policy (SCP), exceeding the default limit of 5 SCPs per OU. Removing the direct all-access SCP proved disastrous, severing trust relationships between accounts, and wedging the entire process.
Important: Grasp the intricacies of AWS SCP limits and their impact on your architecture before making changes.
Days 3-4: The "Clean Slate" Mirage
Desperate, I decided to start over. The plan involved closing child accounts, removing all resources, and returning the master billing account to a pristine state. However, the Landing Zone Accelerator detected my suspended accounts as active, blocking further deployment!
Lesson Learned: Understand the AWS account lifecycle. Suspended accounts can still impact your deployment.
Days 5-6: Account Purgatory – Trapped in AWS Limbo
Now, I needed to unsuspend those accounts to properly remove them. Cue another support case and waiting game. Once unsuspended, I tried to cleanly remove them from the Organization, only to be met with unexplained errors. I'm still waiting for a solution.
Real-World Example: Think of AWS accounts like adult children refusing to leave your basement!
Key Takeaways to Avoid My Headaches
Learn from my painful experience! Here's a summary of crucial lessons for your AWS Landing Zone journey:
- Plan Ahead: Service quotas can halt your progress.
- SCP Mastery: Know your SCP limits before deployment. Test in a dev environment.
- Document Diligently: Keep a detailed record of every change and error.
- Account Lifecycle Awareness: Suspended accounts can linger, blocking deployments
- Patience is Key: Allocate significantly more time than you initially estimate.
Share Your Stories: The Silver Lining to the Cloud (Migration)
Have you tackled an AWS Landing Zone deployment with enhanced security controls, or perhaps Entra ID integration? I'd love to hear your trials and tribulations!