How to Secure an AWS Account for a Startup

To secure an AWS account for a startup, protect the root user with MFA and no access keys, sign people in through temporary credentials, block public S3 access, keep logs beyond 90 days, and turn on a posture checker. These steps take about a day and close most common mistakes.

All facts below come from AWS documentation as of 19 October 2026.

Key takeaways

• Never use the root user for daily work, and never create root access keys.
• Humans and workloads should use temporary credentials, not long-lived IAM user keys.
• Turn on all four S3 Block Public Access settings at the account level.
• Event history keeps 90 days of management events only, so create a trail.
• Use more than one account early, with guardrails from AWS Organizations.

What should you do first on a new AWS account?

Secure the root user first. AWS says to "strongly recommend you don't access the AWS account root user unless you have a task that requires root user credentials."

Do these in order:

1. Set a strong, unique root password stored in a password manager.
2. Register MFA, ideally two devices. AWS allows up to eight MFA devices on the root user, and recommends phishing resistant options such as passkeys and security keys.
3. Do not create root access keys.
4. Use a group email address for the root user, such as a shared mailbox, so a departure does not lock you out.
5. Restrict who can reach the account recovery email and phone number. AWS advises that no one person should have access to both.

How should your team sign in to AWS?

Use federation with temporary credentials. AWS recommends requiring human users to use an identity provider, and recommends IAM Identity Center for centralized access to your accounts.

Avoid IAM users with passwords and access keys. If you must keep one, require MFA and use access last used information to find and remove stale keys.

A minimal setup:

• Connect IAM Identity Center to your company identity provider.
• Create groups such as Admins, Developers and ReadOnly.
• Assign permission sets per account.
• Sign in with the CLI through your Identity Center profile instead of copying keys.

How do workloads get credentials without access keys?

Use IAM roles. AWS says that when you build on EC2 or Lambda, AWS delivers temporary role credentials to the compute resource, so you do not need to distribute long-lived IAM user keys.

For CI systems outside AWS, AWS lists options: IAM Roles Anywhere with an X.509 certificate, or AssumeRoleWithWebIdentity with a JSON web token from an identity provider you configure. Most CI platforms can issue such tokens, so the pipeline never stores a static key.

How do you apply least privilege without slowing the team?

Start with AWS managed policies, then narrow them. AWS notes that managed policies "might not grant least-privilege permissions for your specific use cases" and recommends customer managed policies as you mature.

Use IAM Access Analyzer to generate a policy from CloudTrail activity, then test it before deployment. Review last accessed information every quarter and remove what nobody uses.

How do you stop public S3 buckets?

Turn on S3 Block Public Access for the whole account. AWS recommends turning on all four settings: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy and RestrictPublicBuckets.

aws s3control put-public-access-block \
  --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Check applications first. AWS warns that if you host a static website from a bucket, you may need to adjust individual settings. Settings apply to all Regions and propagate over time.

How do you keep logs long enough to investigate?

Create a CloudTrail trail. AWS documents that Event history is on by default, records management events only, and keeps 90 days. Data events such as S3 object activity need a trail.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name example-central-logs \
  --is-organization-trail \
  --is-multi-region-trail

Send logs to a separate account that developers cannot modify. An organization trail covers every member account.

What about EC2 instance metadata?

Require IMDSv2 on new instances. AWS says that by default you can use either IMDSv1 or IMDSv2, and you can configure an instance to accept only IMDSv2 so IMDSv1 calls fail. IMDSv2 uses session tokens, which helps against server side request forgery.

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required

Test applications first, because older SDK versions do not support IMDSv2.

Should a startup use multiple AWS accounts?

Yes, as soon as you have production and non production workloads. AWS recommends separating workloads into multiple accounts managed with AWS Organizations, and using service control policies as permission guardrails across accounts.

AWS also notes that SCPs grant no permissions on their own. They only limit what identity policies can allow. For member accounts, AWS recommends removing root user credentials or restricting root with an SCP.

How do you know when something drifts?

Turn on a posture checker. AWS Security Hub CSPM runs checks against the AWS Foundational Security Best Practices standard and others, and uses AWS Config for most control findings. It only reports findings generated after you enable it, so enable it early, in every Region you use.

Add root user alerts through CloudWatch or EventBridge so a root sign in pages someone. See also our CSPM comparison.

Startup AWS security checklist

• Root user: MFA on two devices, no access keys, group email, recovery contacts reviewed.
• People: IAM Identity Center, groups, no long-lived keys.
• Workloads: roles everywhere, web identity or Roles Anywhere for CI.
• Storage: Block Public Access on at the account level.
• Logs: organization trail, multi-region, separate log account.
• Compute: IMDSv2 required on new instances.
• Structure: separate accounts for prod and non prod, SCP guardrails.
• Monitoring: Security Hub CSPM and root user alerts enabled.

Frequently asked questions

Sources

• Security best practices in IAM
• Root user best practices
• Blocking public access to Amazon S3
• Instance metadata service configuration
• CloudTrail organization trails
• AWS Security Hub CSPM

Last reviewed: 19 October 2026.