AWS Setup 101: Multi-Account Setup with SSO (The Easy Way)

Setting up your AWS accounts right from the start can save you a ton of headaches later. There are multiple ways to do it, but the default setup often misses a few things that’ll make life easier for your team. This guide is designed for those new to AWS, but we’ll layer in expert-level details and best practices.

Tip: If you’re just starting with AWS, or if you’re relying heavily on IAM users and credential files, this guide will show you a more secure and scalable approach. We’re aiming for a robust, auditable, and least-privilege setup from day one.

The ideal setup involves multiple AWS accounts grouped under a single AWS Organization, with your team authenticating through Single Sign-On (SSO) to access the AWS Console and the AWS Command Line Interface (CLI).

Sounds complex? It’s a one-time process (though you’ll refine it over time), and after this, you won’t have to think about core account structure much again. Let’s get started!

1. Create a Management Account

The first step is creating the management account. This is the central hub for your AWS Organization. Think of it as the payer account and the root of your AWS organizational tree.

• Use a work email alias. Create an alias like [email protected] that forwards to your real email. This allows you to delegate access to others in the future without sharing your personal email. Important: This email address should only be used for AWS account recovery and critical notifications. Do not use it for any other purpose. Expert Tip: Use a distribution list or shared mailbox that multiple trusted individuals can access, but limit who can send as that address.
• Name the account after your company. For example, YourCompanyName. This helps with identification.
• Enter your billing information and confirm your identity. Pretty standard stuff.
• Choose basic support. You can always upgrade later if needed. Expert Tip: For production workloads, consider Business or Enterprise support for faster response times and access to Infrastructure Event Management.

Once you’re done, you should be able to log in and access the AWS Console.

Important: The credentials for this account are extremely powerful. You should rarely need them again. The root user credentials for this account give complete, unrestricted access. You can always reset it if absolutely necessary. For maximum security, consider using a hardware security key (like a YubiKey) for the root user’s MFA.

Root User Explained: When you create an AWS account, you start with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user. You sign in as the root user by using the email address and password that you used to create the account. You should never use the root user for everyday tasks, even administrative ones. Instead, adhere to the principle of least privilege and create additional IAM users or, better yet, use SSO via IAM Identity Center.

What to Do:

• ✅ Use a work email alias for long-term management (and ensure it’s a distribution list).
• ✅ Choose a clear and descriptive account name.
• ✅ Securely store the root account credentials (hardware MFA is best).
• ✅ Enable MFA immediately for the root user, ideally using a hardware security key.

What NOT to Do:

• ❌ Use your personal email address.
• ❌ Use a generic or unclear account name.
• ❌ Use these credentials for everyday tasks!

2. Setting Up Your AWS Organization (Centralized Management)

Now, create your AWS Organization. This lets you manage all your accounts under one umbrella and apply policies across them.

• Log in to the AWS Management Console using the management account credentials (the root user you just created).
• Search for AWS Organizations and click on the result.
• Follow the prompts to Create an Organization.

Key things to remember:

• Enable all features when setting up the Organization (This gives you the most flexibility, including features like Service Control Policies, which we’ll use later.). Expert Tip: Enabling all features also allows you to use features like AWS CloudTrail organizational trails and centralized AWS Config rules.
• Verify your email address when prompted.
• AWS Organizations is free. You only pay for the resources used within the individual accounts.

What to Do:

• ✅ Enable all features in your AWS Organization.
• ✅ Verify your email address to activate the Organization.

What NOT to Do:

• ❌ Skimp on enabling all features; it limits your management capabilities.

3. Create Separate Accounts for Dev, Staging, and Production (The Golden Rule)

This is where things get smart. Create dedicated accounts for each environment: Development, Staging, and Production. Expert Tip: Also consider creating a separate account for security auditing and logging, and potentially a shared services account for common infrastructure like networking components.

Why? Because chaos is bad. And accidents happen.

• Security: One compromised account doesn’t bring down your entire operation. This implements the principle of least privilege and blast radius reduction.
• Stability: No accidental “rm -rf /” commands in production (we’ve all been there, right?). Separate environments prevent unintended changes in critical systems.
• Cost Tracking: See exactly where your money is going for each environment.
• Resource Limits: Avoid hitting AWS resource limits by spreading things out. Each AWS account has its own set of service limits.
• Auditing and Compliance: Easier to audit activity and meet compliance requirements when environments are isolated.

How to Create the Accounts:

• Within the AWS Organizations console, click Add an AWS Account and choose Create an AWS account.
• For each new account, you’ll need:
  • A unique email address (you can use aliases of your main work email, like [email protected], [email protected] and [email protected]). (These aliases will receive AWS-related notifications, but they don’t need to be actively monitored like your primary work email.) Expert Tip: Use a consistent pattern for these aliases, and again, consider using distribution lists.
  • A unique account name (YourCompanyName-Dev, YourCompanyName-Staging, YourCompanyName-Prod). Expert Tip: Use a consistent naming convention that reflects the environment and potentially includes a unique identifier.

What to Do:

• ✅ Create separate accounts for each environment (Dev, Staging, Prod, Security, Shared Services).
• ✅ Use a consistent and clear naming convention for all accounts.

What NOT to Do:

• ❌ Put everything in one account (resist the urge!).
• ❌ Do not use these emails for non AWS related operations

4. Enforce MFA Across the Organization (The Security Blanket)

Protect your accounts by requiring MFA for all users. AWS Organizations makes this easy to enforce using Service Control Policies (SCPs).

• Within the AWS Organizations console, navigate to Service Control Policies (SCPs).
• Create a new SCP that enforces MFA. Here’s an example SCP you can adapt:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllUsersWithoutMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice",
        "iam:DeactivateMFADevice",
        "iam:DeleteVirtualMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

• Explanation: This SCP denies all actions (except those related to setting up MFA) if the user does not have MFA enabled. The NotAction list allows users to initially set up their MFA. The sts:GetSessionToken is included to allow users to use the AWS CLI with temporary credentials without requiring MFA on every command (though their initial login will require MFA).
• Apply this SCP to your entire Organization (the root OU).

What to Do:

• ✅ Create and apply an SCP to enforce MFA across all accounts. (Use the example above as a starting point).
• ✅ Educate your team about the importance of MFA and how to set it up.

What NOT to Do:

• ❌ Assume everyone will enable MFA on their own – enforce it!

5. Setting Up SSO Access (The Easy Way In)

Now for the magic: Single Sign-On (SSO). SSO lets your team access all your AWS accounts with a single set of credentials. We’ll use AWS IAM Identity Center (formerly AWS SSO).

• Within the AWS Organizations console (still logged in as the management account), go to AWS IAM Identity Center.
• Enable AWS IAM Identity Center. Expert Tip: Choose the region closest to your team for best performance.
• Connect your identity provider. AWS IAM Identity Center supports popular providers like Okta, Azure AD, and Google Workspace. Alternatively, you can use AWS IAM Identity Center’s built-in identity store. Expert Tip: If you’re starting small, the built-in identity store is fine. If you already have a corporate directory, integrate it for a better user experience and centralized user management. For this example, let’s assume you’re using the built-in store.
• Create users and groups within AWS IAM Identity Center (or sync them from your identity provider). Expert Tip: Follow the principle of least privilege. Create groups like “Developers,” “Administrators,” “Auditors,” etc., and assign permissions based on those roles.
• Assign users and groups to your AWS accounts and define the permission sets they have (e.g., “AdministratorAccess” for admins, “ReadOnlyAccess” for auditors). Start with the principle of least privilege – give users only the permissions they need to do their jobs. Expert Tip: AWS provides managed policies like “AdministratorAccess” and “ReadOnlyAccess,” but you should create your own custom policies for finer-grained control. For example, a “Developer” group might need access to EC2, S3, and Lambda, but not to billing or IAM.

Example: Creating a “Developer” Permission Set

1. In IAM Identity Center, go to “Permission sets”.
2. Create a new permission set.
3. Choose “Create a custom permission set”.
4. Give it a name like “DeveloperAccess”.
5. Attach policies. You might attach AmazonEC2FullAccess, AmazonS3FullAccess, and AWSLambda_FullAccess. You might also create a custom policy that grants access to specific resources (e.g., only S3 buckets with a specific prefix).
6. Do not attach “AdministratorAccess”.

Using AWS SSO with the AWS CLI:

1. Install and Configure the AWS CLI: Make sure you have the latest version of the AWS CLI installed.
2. Configure SSO: Use the aws configure sso command. This will prompt you for your SSO start URL and region, which you can find in the AWS IAM Identity Center console.
3. Login: Use the aws sso login command. This will open a browser window where you can authenticate with your SSO provider (or the IAM Identity Center built-in store).
4. Use the CLI: Once logged in, you can use the AWS CLI as usual. Your credentials will be automatically managed by AWS SSO and will expire after a set period (configurable in IAM Identity Center). Expert Tip: Use named profiles with the --profile flag to easily switch between different AWS accounts and roles. For example: aws s3 ls --profile YourCompanyName-Dev-Developer.

What to Do:

• ✅ Enable AWS IAM Identity Center in your AWS Organization.
• ✅ Connect your existing identity provider (if you have one) or use the built-in store.
• ✅ Assign users and groups to your AWS accounts with least privilege permission sets.
• ✅ Create custom permission sets for fine-grained control.

What NOT to Do:

• ❌ Create individual IAM users within each AWS account (use AWS IAM Identity Center for centralized management).
• ❌ Give everyone “AdministratorAccess” – use the principle of least privilege.

6. Billing and Cost Management (The Bottom Line)

Centralized billing with AWS Organizations lets you see all your costs in one place (the management account).

• Enable consolidated billing in the AWS Organizations console (this is usually enabled by default when you enable all features).
• Use AWS Cost Explorer to analyze your spending across all accounts. Expert Tip: Use cost allocation tags to further categorize your spending (e.g., by project, team, or environment).
• Set up AWS Budgets and CloudWatch alarms (as described below) to track your costs and prevent surprises.

Setting Up a Basic Budget:

• Go to AWS Budgets in the Billing and Cost Management console.
• Create a cost budget.
• Set a monthly budget amount (e.g., $100).
• Configure alerts to be sent to your email alias when the budget is exceeded (e.g., at 80% and 100%).
• Expert Tip: Create separate budgets for each account or environment (Dev, Staging, Prod) for better granularity.

Setting Up a CloudWatch Alarm:

• Go to CloudWatch in the Management Console.
• Create an alarm.
• Choose the “Billing” -> “Total Estimated Charge” metric. Choose USD as currency.
• Set a threshold (e.g., $80).
• Configure an SNS topic to send notifications to your email alias.
  • Creating an SNS Topic:
    1. Go to the Simple Notification Service (SNS) console.
    2. Create a new topic.
    3. Give it a name (e.g., “AWS-Billing-Alerts”).
    4. Create a subscription.
    5. Choose “Email” as the protocol.
    6. Enter your email alias.
    7. Confirm the subscription (you’ll receive an email).
  • Back in CloudWatch: When creating the alarm, select this SNS topic as the notification target.

What to Do:

• ✅ Enable consolidated billing in your AWS Organization.
• ✅ Use AWS Cost Explorer to analyze spending patterns.
• ✅ Set up AWS Budgets and CloudWatch alarms for cost control.
• ✅ Use cost allocation tags for granular cost tracking.

What NOT to Do:

• ❌ Ignore the centralized billing features – it’s essential for cost management.

7. The Management Account: Put it Away!

That management account? Lock it down! Now that everything is set up with AWS Organizations and SSO access, you rarely, if ever, need to log in to it again using the root user.

• Change the root account password to something long, complex, and virtually unguessable (at least 20 characters, random, with upper/lower case, numbers, and symbols).
• Store the password securely in a highly secure and reputable password manager like 1Password, LastPass, or Bitwarden, and have a physical backup (e.g., written on paper and stored in a fireproof safe) in case the digital password manager becomes unavailable. Do not use simple text files or cloud storage for this critical password.
• Document the process for accessing the management account in case of emergencies (and ensure multiple trusted individuals know the process).

What to Do:

• ✅ Store the root account credentials securely, in multiple locations (digital and physical), in case you lose access to AWS IAM Identity Center or SSO breaks for some reason.
• ✅ Regularly review and update your emergency access procedures.

What NOT to Do:

• ❌ Use the management account for any everyday tasks. It’s for emergencies only!
• ❌ Use any easy-to-remember-or-guess password.

8. Troubleshooting (Common Issues)

• Email Verification Problems: If you’re having trouble verifying your email address, check your spam folder and ensure that the email alias is correctly forwarding to your main inbox. You may need to contact AWS Support. Expert Tip: Sometimes email delivery can be delayed. Wait a few minutes and try resending the verification email.
• MFA Setup Issues: If users are having trouble setting up MFA, ensure they are following the instructions in the AWS documentation Expert Tip: Provide clear, step-by-step instructions and screenshots for your users. Consider holding a training session.
• SSO Login Issues: Double check the start URL and ensure that the user has the correct permissions assigned in AWS IAM Identity Center. Expert Tip: Check the CloudTrail logs in the member account (and the management account) for any authentication failures. This can provide valuable debugging information.

9. Advanced: Infrastructure as Code (Optional)

For a more automated approach, consider using Infrastructure as Code (IaC) tools like AWS CloudFormation or Terraform. These tools allow you to define your AWS infrastructure (including accounts and configurations) as code, making it repeatable and consistent.

• AWS CloudFormation: AWS’s native IaC service. Uses JSON or YAML templates.
• Terraform: A popular open-source IaC tool that supports multiple cloud providers, including AWS. Uses HashiCorp Configuration Language (HCL). Expert Tip: Use a version control system (like Git) to manage your IaC templates. This allows you to track changes, collaborate with others, and roll back to previous versions if needed.

10. Introduce AWS Control Tower (Optional Advanced)

AWS Control Tower provides a simple way to set up and govern a secure, multi-account AWS environment. It automates many of the steps described in this guide, including creating accounts, setting up guardrails (like SCPs), and configuring centralized logging and security auditing. If you prefer a more guided approach, consider using AWS Control Tower.

• Key Features: Account Factory (for automated account creation), Guardrails (preventive and detective), Centralized Logging (CloudTrail and Config), and Dashboard (for visibility).
• Best For: Organizations that want a prescriptive, best-practice approach to multi-account management.
• Expert Tip: Control Tower is excellent for establishing a baseline, but you can still customize it and add your own configurations on top of it.

11. Bonus: Scoring AWS Credits (The Startup Lifeline)

AWS understands that startups need a boost. They offer various programs to provide free credits, which can significantly reduce your initial cloud costs. Here’s how to find them:

• AWS Activate: This is the primary program for startups. It offers credits, technical support, training, and other resources. There are different tiers based on your startup’s stage and affiliation with AWS partners:

  • Founders Package: Designed for early-stage startups with no institutional funding. Typically offers a smaller amount of credits.
  • Portfolio Package: For startups associated with an AWS Activate Provider (accelerators, incubators, VC firms, etc.). This usually provides a larger amount of credits and more benefits. You’ll need a valid “Org ID” from your affiliated organization to apply for this package.
  • Search the AWS Activate website for the application process and eligibility requirements.

• AWS Promotional Credits: AWS sometimes offers promotional credits for specific services or to new customers. Keep an eye on the AWS website and your email (if you’ve signed up for marketing communications).

• Partner Programs: Many AWS partners (consulting firms, technology providers) offer their own credit programs to clients. If you’re working with a partner, ask them about potential credit opportunities.

• Events and Workshops: AWS frequently hosts events and workshops (both online and in-person) where they may offer credits to attendees.

Tips for Maximizing Your Credits:

• Apply Early: Don’t wait until you’ve already incurred significant costs. Apply for AWS Activate as soon as you’re eligible.
• Be Specific: When applying, clearly explain your startup’s mission, your use case for AWS, and your projected growth.
• Use Credits Wisely: Treat your credits like real money. Optimize your resource usage and avoid unnecessary spending. The goal is to use the credits to build a sustainable foundation, not to burn through them quickly.
• Understand Credit Expiration: AWS credits usually have an expiration date. Keep track of this and plan your usage accordingly.
• Combine with Cost Optimization: Use the credits in conjunction with the cost management practices discussed in Section 6 (budgets, alarms, cost allocation tags).

What NOT to do:

• ❌ Don’t apply multiple times under different names: AWS will detect this and you may be disqualified.
• ❌ Don’t use credits for non-business purposes: The credits are intended for your startup’s AWS usage.
• Don’t inflate your needs: Be realistic in your application.

By actively seeking out and effectively utilizing AWS credits, you can significantly reduce your cloud costs in the early stages of your startup, giving you more runway to focus on building your product.

Conclusion: AWS Account Setup

You’ve now set up a secure, scalable, and well-organized AWS environment for your startup. By following these steps, you’ve avoided common pitfalls and created a foundation for long-term success. You’ve implemented best practices like least privilege, separation of duties, and centralized management.

Now go build something amazing!

TLDR; AWS Account Setup Checklist:

• ✅ Create a Management Account: Use a work email alias (distribution list). Enable MFA immediately (hardware key is best).
• ✅ Set Up AWS Organizations: Enable all features.
• ✅ Create Separate Accounts: Dev, Staging, Production, Security, Shared Services (at least).
• ✅ Enforce MFA: Use SCPs to require MFA across the organization.
• ✅ Set Up SSO Access: AWS IAM Identity Center, integrated with your existing identity provider if possible. Use least-privilege permission sets.
• ✅ Enable Consolidated Billing: For easy cost management. Set up budgets and CloudWatch alarms. Use cost allocation tags.
• ✅ Secure The Management Account And hide it from everyone. Store the root credentials very securely (password manager + physical backup).
• ✅ Document Emergency Procedures.