Krypton Defence Solutions
← All security news Guide

Getting started with AWS: a secure first week

Creating an AWS account takes five minutes. Setting it up so it doesn't become a security or billing problem six months later takes an afternoon. Here's what to do in your first week, in order.

1. Create the account with a shared, long-lived email

The email address you sign up with becomes the root user, the one identity that can do absolutely anything, including close the account. Don't use a personal address or one tied to a single employee. Use a company address you'll control for years, such as [email protected], ideally a group or alias that more than one person can access.

2. Lock down the root user straight away

Before you build anything:

  • Turn on MFA for the root user. A hardware key or an authenticator app both work. Store the recovery details somewhere safe and offline.
  • Don't create access keys for root. If any exist, delete them.
  • Stop using root. After the initial setup you should rarely need it. AWS lists the handful of tasks that genuinely require it.

You'll find all of this under IAM → Dashboard → Security recommendations.

3. Set up a budget alert before you spend anything

The most common nasty surprise on AWS isn't a hack. It's a bill. Go to Billing and Cost Management → Budgets and create a monthly cost budget with an email alert at, say, 50%, 80% and 100% of what you expect to spend. Even if you expect to stay inside the free offers, set a small budget so you hear about it the day something unexpected starts running.

While you're in Billing, check who receives billing emails, and make sure it's an inbox someone actually reads.

4. Give people their own logins with IAM Identity Center

Don't share the root login, and avoid creating old-style IAM users with passwords and access keys for people. Instead, enable IAM Identity Center (formerly AWS SSO):

  • Create a user for each person, with MFA required.
  • Give them access through permission sets: an administrator set for one or two people, and narrower ones (read-only, developer) for everyone else.
  • People sign in through a single portal URL and get temporary credentials, for the console and the command line alike. Nothing long-lived ends up on laptops.

If you're the only person using the account for now, set this up anyway and use it for your own day-to-day work. It's much harder to retrofit later.

5. Choose your region, and stick to it

AWS runs in many regions around the world. Pick one close to your users (for UK businesses that's usually London, eu-west-2, or Ireland, eu-west-1) and build there. Running resources scattered across regions makes costs and security harder to keep track of. Some services, like IAM and billing, are global, so don't worry when the console shows "Global" for those.

6. Switch on the security basics

These cost little or nothing for a small account and give you a fighting chance if something goes wrong:

  • CloudTrail: records who did what. AWS keeps 90 days of event history by default; create a trail to an S3 bucket to keep it longer.
  • GuardDuty: AWS's managed threat detection. Enable it in the regions you use.
  • S3 Block Public Access: turn it on at the account level so that no bucket can be made public by accident.
  • IAM Access Analyzer: flags anything shared outside your account.

7. Plan for more than one account

It's tempting to put everything in one account, but most teams end up regretting it. Separate accounts are the strongest boundary AWS offers. A common starting shape is:

  • a management account that handles billing and organisation-wide settings, and runs nothing else,
  • a production account for live workloads,
  • a development or sandbox account where people can experiment safely.

AWS Organizations ties these together with consolidated billing and guardrail policies. AWS Control Tower sets the whole structure up for you with sensible defaults. You don't need it on day one, but if you know you'll grow, starting this way saves a painful migration later.

8. Build with code, not clicks

The console is great for learning, but anything you intend to keep should be defined as infrastructure as code: AWS CDK, CloudFormation or Terraform. It means your setup is reviewable, repeatable and recoverable, and you can see exactly what changed and when. Tag resources with at least an owner and a project, so the bill makes sense later.

9. Clean up as you go

Experiments are cheap until they're forgotten. Make a habit of deleting what you no longer need: test instances, unattached volumes, old snapshots and idle load balancers. Cost Explorer shows you where the money's going, and your budget alerts will tell you when to look.

The short version

  1. Root user: shared email, MFA on, no access keys, never used day to day.
  2. A budget alert before you spend a penny.
  3. IAM Identity Center for every person, with temporary credentials and MFA.
  4. One home region.
  5. CloudTrail, GuardDuty, S3 Block Public Access and Access Analyzer switched on.
  6. Separate accounts as soon as you have something worth protecting.
  7. Infrastructure as code, tagged, and cleaned up regularly.

If you've already started and aren't sure how your account measures up, our fixed-price AWS Security Baseline Review checks all of this and more, and tells you what to fix first. If you're starting from scratch with several accounts in mind, our Multi-account Landing Zone package sets up the right structure from day one.