Building a Secure AWS Foundation for SaaS Migration

Securing root, structuring accounts, enabling Control Tower — the groundwork I’m laying for long-term SaaS scalability on AWS.

Author

Houssem BEN SLAMA
October 17, 2025

Laying the Groundwork: Secure AWS Setup for SaaS Migration

I just created a new AWS root account. The goal? Migrate all my SaaS platforms to AWS, one step at a time — starting with a single product and a single service: Amazon S3.

But I’m doing it the right way from day one. That means: security-first, scalable structure, clean account separation, and governance in place.

Here’s the exact approach I’m taking to build a solid AWS foundation before running any workloads.

Step 1: Lock Down the Root Account

The root account should never be used for day-to-day ops. It’s your break-glass-in-case-of-emergency user.

  • Enabled MFA on root.

  • Stored credentials securely (password manager only).

  • Removed any root access keys.

  • Set a recovery email.

  1. Sign in to AWS Console using the root user.

  2. Set a strong, unique password.

  3. Add a recovery email if not set already.

  4. Go to IAM > Users > Security credentials, and:

    • Delete any access keys for root (they shouldn’t exist).

  5. Go to IAM > Account Settings and:

    • Enable Multi-Factor Authentication (MFA).

    • Use a hardware MFA or an authenticator app like Authy or Google Authenticator.

  6. Log out — you’re done with root. Don’t use it again unless absolutely necessary.

Step 2: Create a Proper Admin IAM User

Instead of using root, I created an IAM user with full privileges but proper traceability.

  • Created an IAM group with AdministratorAccess.

  • Go to IAM > Users and click Add users.

  • Name it something like admin-john.

  • Select:

    • AWS Management Console access

    • Set a custom password

    • Require password reset on next sign-in

  • Click Next, and:

    • Create a new group AdminGroup

    • Attach the policy AdministratorAccess to that group

  • Review and create the user.

  • Log in as the new admin user.

  • Set up MFA immediately on this user as well.

Step 3: Enable AWS Organizations

To manage multiple SaaS products and environments, I activated AWS Organizations for a clean, multi-account architecture.

Example structure: 

org-root
├── security (logs, guardrails, audit)
├── shared-services (SSO, networking)
├── saas-1-dev
├── saas-1-prod
├── saas-2-dev
└── ...

Benefits:

  • Account-level isolation.

  • Central governance.

  • Easier billing and security auditing

Step 4: Launch AWS Control Tower

To automate governance, I set up AWS Control Tower, which provisions a fully-managed Landing Zone.

  • Multi-account setup.

  • Logging and auditing (CloudTrail, Config).

  • Preconfigured guardrails (SCPs, security baselines).

  • IAM Identity Center (formerly SSO) ready to go.

  • Go to AWS Control Tower in the console.

  • Click Set up landing zone.

  • Review the required accounts:

    • Audit (used for centralized logging)

    • Log archive

  • Choose your region (usually the region where you’ll run your services).

  • Select the existing organization.

  • Let Control Tower:

    • Set up SSO (IAM Identity Center)

    • Create SCPs (guardrails)

    • Enable mandatory security services (CloudTrail, Config)

  • Wait for provisioning (~1 hour).

Step 5: Configure IAM Identity Center

Instead of creating users per account, I centralized access via IAM Identity Center:

  • Defined roles by team and environment (SaaS1-Admin, Viewer, Audit, etc.).

  • Mapped access per account and permission set.

  • MFA enforced globally.

  • Go to IAM Identity Center.

  • Choose identity source (AWS managed directory or connect to an external IdP like Okta/Google Workspace).

  • Create permission sets:

    • SaaS1-Admin → AdministratorAccess

    • SaaS1-Viewer → ViewOnlyAccess

    • Audit → SecurityAudit

  • Assign users/groups to these permission sets and link them to the appropriate accounts (saas1-dev, saas1-prod, etc.).

  • Enforce MFA requirement in settings.

Step 6: Centralized Security + Monitoring

Before deploying anything, I turned on the essentials:

  • ✅ CloudTrail: Centralized across accounts (stored in security).

  • ✅ AWS Config: For compliance drift detection.

  • ✅ GuardDuty: Threat detection.

  • ✅ Security Hub: Unified view of security issues.

  • ✅ Cost Explorer & Budgets: To monitor spend from day one.

Step 7: Set Up My First SaaS Environment (S3 only to start)

Now the base is solid, I spun up two accounts:

  • saas-1-dev

  • saas-1-prod

And started with a secure S3 setup:

  • Bucket policies locked down to IAM roles.

  • Encryption enabled (SSE-S3 for now).

  • Versioning turned on.

  • Access logging enabled.

  • Lifecycle rules prepped for later.

💡 Takeaways

  • No root usage, ever.

  • Multi-account structure from day one.

  • Everything tracked, tagged, and secure.

  • Foundation built for scale, security, and clarity.

I’ll share the Terraform, account automation scripts, and migration checklists in upcoming posts.

👉 If you're planning your own AWS move, don't wait until later to get the basics right. This stuff compounds fast.