AWS security fundamentals for small teams

AWS security best practices start with a handful of account-level settings: protecting the root user, giving people their own sign-ins with only the access they need, keeping an activity record, stopping storage from being made public by accident, and getting an early warning when spending jumps. This guide explains each one in plain English, based on Amazon Web Services’ own documentation (checked October 2026), with links to AWS’s pages for the latest steps.

It is written for small teams that have one or a few AWS accounts and no dedicated cloud security staff.

Why it matters

In the cloud, the provider secures its data centres and the underlying services, while the customer is responsible for how their own account is set up: who can sign in, what they can do, and what data is exposed. Our guide to the cloud shared responsibility model explains this split in more detail.

That means a cloud account is only as secure as its settings. A single reused password on an all-powerful account, or one storage bucket left open to the internet, can undo a lot of good work elsewhere.

How to protect the root user

The root user is the account’s master key. When an AWS account is created, it comes with a root user: the email address and password used to sign up. AWS says the root user “has full access to all AWS services and resources in the account, including billing information.”

AWS’s root user best practices include:

• Use it only for tasks that need it. AWS says it strongly recommends not accessing the root user “unless you have a task that requires root user credentials”.
• Strong, unique password. AWS recommends “a password that is strong and unique.”
• Multi-factor authentication (MFA). AWS says “it’s crucial to add MFA for the root user”, and strongly recommends registering more than one MFA device.
• No access keys. AWS strongly recommends not creating access keys (long-term programmatic credentials) for the root user.
• A group email address. AWS suggests using “an email address that is managed by your business” that forwards to a group of people, so the account doesn’t depend on one person’s inbox.
• Split the recovery channels. AWS says “No one person should have access to both the email inbox and phone number”, because both can be used to recover the root password.
• Watch for root sign-ins. AWS recommends alerting on root user sign-in and usage.

How to add MFA to the root user

Based on AWS’s instructions (checked October 2026). The console can change; AWS’s guide to enabling a virtual MFA device for the root user has the latest steps.

1. Sign in to the AWS Management Console with the root user credentials.
2. Choose the account name at the top right, then choose Security credentials.
3. In the Multi-Factor Authentication (MFA) section, choose Assign MFA device.
4. Enter a device name, choose Authenticator app, then choose Next.
5. In the authenticator app, add a new account, then choose Show QR code in the wizard and scan it (or choose Show secret key and type the key into the app).
6. Enter the code from the app in MFA code 1, wait up to 30 seconds for the next code, enter it in MFA code 2, then choose Add MFA.

AWS notes that up to eight MFA devices can be registered, and that if the MFA device is lost and the root user can’t sign in, AWS customer service has to be contacted to remove MFA protection. AWS suggests registering multiple MFA devices or keeping a secure backup of the QR code or secret key. AWS’s IAM best practices also say it recommends “phishing-resistant MFA such as passkeys and security keys wherever possible”. Our comparison of MFA methods, from text codes to security keys explains the difference.

How to give people their own sign-ins

Because the root user is reserved for rare tasks, people need their own sign-ins for daily work. AWS offers two main ways to do this:

• IAM Identity Center. AWS describes it as “the AWS solution for connecting your workforce users” to AWS accounts and applications. People can be created directly in it, or synced from an existing identity provider. Users sign in through the AWS access portal, which AWS describes as giving them access to all their assigned applications and AWS accounts.
• IAM users. Individual users created inside one AWS account, which can have long-term passwords and access keys.

AWS’s IAM best practices say to “Require your human users to use temporary credentials when accessing AWS”, through federation with an identity provider, preferably IAM Identity Center. Its guide for new account administrators describes creating an administrative user in IAM Identity Center, then “least-privilege users for other humans”, and creating access keys “only for use cases that require long-term credentials.” For software running in AWS, AWS says there is “no need to distribute long lived credentials” because workloads can use IAM roles instead.

Where long-term access keys are still used, AWS recommends updating them when needed, “such as when an employee leaves your company.”

How to limit access to what each job needs

Least privilege means each person or system can do what their job requires and nothing more. AWS’s best practices describe granting “only the permissions required to perform a task.”

AWS describes a practical path:

• Start with AWS managed policies, which are ready-made permission sets, but note AWS’s caution that they “might not grant least-privilege permissions for your specific use cases.”
• Use IAM Access Analyzer to generate tighter policies based on what a role actually used, and to check for public or cross-account access.
• Remove what isn’t used. AWS says IAM provides “last accessed information” to help find users, roles, permissions and credentials that are no longer needed.
• Add conditions. AWS says policies can grant access to actions and resources “only if the access request meets specific conditions.”

The ACSC’s small business cloud security guides (written for Microsoft 365 and ChromeOS rather than AWS) make a similar point in general terms: restricting privileged access “to only users with a demonstrated business need is essential.” Our Essential Eight explainer covers where this fits among the ACSC’s priority controls.

How to keep an activity record with CloudTrail

AWS CloudTrail records actions taken in an AWS account, such as who changed a setting or created a resource. AWS describes three ways it keeps records:

• Event history is “a viewable, searchable, downloadable, and immutable record of the past 90 days of management events in an AWS Region.” AWS says it is available automatically when an account is created, with no CloudTrail charge to view it.
• Trails deliver an ongoing copy of events to an S3 bucket. AWS says one copy of management events can be delivered at no CloudTrail charge, though S3 storage charges apply.
• CloudTrail Lake is a managed store for querying events over longer periods, which AWS says incurs charges.

The practical point: Event history only looks back 90 days. Keeping records longer requires a trail or a CloudTrail Lake event data store. Logs are one of the main ways to work out what happened after a suspected incident.

How to stop S3 storage being made public by accident

Amazon S3 stores files (“objects”) in containers called buckets. Misconfigured buckets can expose data to anyone on the internet. S3 Block Public Access is a set of four settings that AWS says override bucket policies, access point policies and object permissions.

AWS’s documentation explains:

• The settings can be applied at the organisation, account, bucket or access point level, and S3 applies “the most restrictive combination”.
• By default, new buckets, access points and objects don’t allow public access.
• AWS recommends turning on “all four settings for block public access for your account”, and also for each bucket.
• Block Public Access doesn’t change existing policies or permissions, so turning it off again can make public resources accessible again.
• AWS says to verify that applications still work without public access before applying the settings.

How to turn on Block Public Access for the whole account

Based on AWS’s instructions (checked October 2026). The console can change; AWS’s guide to configuring Block Public Access for an account has the latest steps.

1. Sign in to the AWS Management Console and open the Amazon S3 console.
2. In the navigation pane, choose Account and organization settings.
3. Under Block Public Access settings for this account, choose Edit.
4. Choose the settings to change, then choose Save changes.
5. When asked to confirm, enter confirm, then choose Confirm.

AWS says that if an error mentions an “organizational S3 Block Public Access policy in effect”, the account’s settings are managed at the organisation level and the organisation’s administrator controls them. AWS’s S3 Block Public Access overview explains how the levels interact.

Threat detection with GuardDuty and Security Hub

Two AWS services are often mentioned together:

• Amazon GuardDuty is, in AWS’s words, “a threat detection service that continuously monitors, analyzes, and processes AWS data sources and logs”. AWS says it automatically starts analysing CloudTrail management events, VPC flow logs and DNS logs once enabled, and generates findings for threats such as compromised credentials or unauthorised cryptomining. AWS says an account is automatically enrolled in a 30-day free trial the first time GuardDuty is used in each AWS Region.
• AWS Security Hub is described by AWS as “a unified cloud security solution that prioritizes your critical security issues”. AWS says it correlates security signals from services such as Amazon GuardDuty, Amazon Inspector and Amazon Macie, and receives findings from Security Hub CSPM (the related service that checks resources against security standards). AWS also says it identifies IAM roles, users, access keys and permissions that haven’t been used within a 90-day lookback period.

Both services have ongoing costs after any trial. AWS’s pricing pages have current details.

How to get an early warning with budget alerts

Unexpected spending can be an early sign that something is wrong, for example resources someone else has started using the account’s credentials. AWS Budgets lets account owners set spending or usage limits and receive alerts when costs approach or exceed them, or are forecast to.

AWS says alerts can go to an email address, an Amazon SNS topic or both. It also notes that budget information “is updated up to three times a day” and that “There can be a delay between when you incur a charge and when you receive a notification”, so a budget alert is a warning, not a hard spending cap.

How to create a budget from a template

Based on AWS’s instructions (checked October 2026). The console can change; AWS’s guide to using a budget template has the latest steps.

1. Open the Billing and Cost Management console.
2. In the navigation pane, choose Budgets.
3. At the top of the page, choose Create budget.
4. Under Budget setup, choose Use a template (simplified).
5. Under Templates, choose a template, such as Zero spend budget or Monthly cost budget.
6. Update the details and settings for the template, then choose Create budget.

Things to watch for

• The root user in daily use, or root access keys that exist at all.
• Shared sign-ins, where several people use one IAM user or one password.
• Old access keys belonging to people who have left or projects that have ended.
• Broad “administrator” permissions given to everyone to save time.
• Buckets with Block Public Access turned off without a clear, documented reason.
• No trail configured, so activity older than 90 days isn’t kept.
• Root account email and phone number out of date. AWS asks administrators to keep these current so they receive account and security notifications.
• Unexplained cost spikes or unfamiliar resources. GuardDuty’s documentation lists compromised credentials and unauthorised cryptomining among the threats it looks for. Access keys stored in code or shared files are one way credentials leak; our guide to protecting secrets and API keys explains the risk.

Common questions

How do I secure my AWS account?

AWS’s own documentation starts with a handful of account-level settings: add MFA to the root user and stop using it day to day, give each person their own sign-in (AWS prefers IAM Identity Center with temporary credentials), and grant only the permissions each job needs. It also describes keeping a CloudTrail record beyond 90 days, turning on S3 Block Public Access for the account, and setting a budget alert. Each section of this guide, starting with how to protect the root user, has the detail.

Is it safe to use the AWS root user every day?

AWS strongly recommends against it. Its documentation says to use root user credentials only for tasks that require them, because the root user has full access to all services and resources in the account, including billing. For everyday work, AWS describes people signing in through IAM Identity Center or IAM identities instead. AWS also says it’s crucial to add MFA to the root user. See how to protect the root user.

How long does CloudTrail keep logs by default?

AWS says CloudTrail Event history covers the past 90 days of management events in each Region, and is available automatically with no CloudTrail charge to view it. Keeping events for longer requires creating a trail, which delivers events to an S3 bucket, or a CloudTrail Lake event data store, which AWS says incurs charges. See how to keep an activity record with CloudTrail.

Do new S3 buckets block public access by default?

Yes, according to AWS. Its documentation says new buckets, access points and objects don’t allow public access by default. AWS still recommends turning on all four Block Public Access settings for the account and for each bucket, and says these settings override bucket policies, access point policies and object permissions. How to turn on Block Public Access has AWS’s console steps.

Does an AWS budget stop spending when the limit is reached?

Not on its own. AWS describes budgets as alerts that go to an email address, an Amazon SNS topic or both. It notes budget information is updated up to three times a day and there can be a delay before a notification arrives, so a budget alert is an early warning rather than a spending cap. AWS also describes optional budget actions, which its documentation covers separately. See how to create a budget from a template.

What do I do if I think my AWS account has been compromised?

The ACSC takes reports through ReportCyber and runs a 24/7 hotline on 1300 CYBER1 (1300 292 371). CloudTrail records who changed settings or created resources, and GuardDuty’s documentation lists compromised credentials and unauthorised cryptomining among the threats it looks for. If the root user’s MFA device is lost and the account can’t be signed in to, AWS says to contact AWS customer service. See where to get official help.

Where to get official help

• The ACSC’s small business cloud security guides explain priority controls for cloud services.
• If an AWS account may have been compromised, the ACSC takes reports through ReportCyber and runs a 24/7 hotline on 1300 CYBER1 (1300 292 371). Our one-page incident response plan template can help a team prepare.
• AWS’s MFA documentation says to contact AWS customer service if the root user’s MFA device is lost and the account can’t be signed in to.