The 20-Minute Security Check for a Business on AWS

Security professionals rank a setting someone left open as the biggest cloud threat of all. These checks close the common gaps in about twenty minutes, and you don't need to be an engineer to run them, only to have the login.

Why is a self-check worth twenty minutes?

Because the settings that matter most are yours, not Amazon's. Amazon secures its data centres, hardware and network. Everything you set up inside your account is yours: who can log in, what is public, and what gets recorded. AWS calls this split the shared responsibility model. Our post on where your website actually lives explains the split for a website.

Your half is where most trouble starts. In the 2021 Cloud Security Report from Cybersecurity Insiders and (ISC)², a survey of 613 security professionals, 67% named misconfiguration as the top cloud threat. That put it ahead of data theft (59%) and unauthorised access (49%).

Settings also drift. In 2022, Canada's Auditor General found that government departments had set up 12 mandatory cloud safeguards, but only 2 of the 12 were being monitored to make sure they stayed in place. So run this check once now, then again every quarter.

Logins and what faces the internet take about five minutes each, your data and your logs about four each, and the plan two. Have the AWS login handy, or sit down with whoever has it.

1. Who can sign in to your account?

Only the people who need to, each with their own login and two-step sign-in. A stolen login skips every other defence. In the same survey, 46% of security professionals counted accidental exposure of passwords and keys among their top worries.

• The root account has two-step sign-in. The root account is the email address the AWS account was opened with. The IAM dashboard's security recommendations flag it if two-step sign-in is missing.
• Nobody uses root day to day. Keep it for the few tasks that need it, and give people their own logins for everything else.
• Everyone has their own login, with two-step sign-in. No shared "admin" account passed around the office.
• Nobody has more access than their job needs. Full admin rights belong with one or two people, not the whole team.
• Old users and keys are gone. In IAM, download the credential report. It lists every user, when they last signed in, whether they use two-step sign-in, and how old their access keys are. Remove anything nobody has used in 90 days.

2. What can the internet see?

Only what you meant to share. Automated tools scan the whole internet for open doors around the clock, so anything public will be found.

• Storage is private by default. In S3, turn on Block Public Access for the whole account. If one bucket must be public, such as website images, make it a deliberate exception that someone has checked.
• Remote-admin ports are closed to the world. In EC2, open Security Groups and look for inbound rules that allow SSH (port 22) or Remote Desktop (port 3389) from 0.0.0.0/0, which means anywhere. Limit them to your office address, or use AWS Systems Manager Session Manager instead.
• Databases are not public. In RDS, each database's "Publicly accessible" setting should say No.
• Servers require IMDSv2. This newer version of the EC2 metadata service makes it much harder for a hacked app to steal the server's AWS credentials. It is a setting on each server.

Shortcut: AWS Trusted Advisor's free checks flag public buckets and wide-open ports for you.

3. Is your data safe if something gets through?

Only if it is encrypted, backed up and recoverable. These checks decide whether you lose a morning or lose the business.

• Encryption is on. S3 has encrypted new files by default since January 2023. For server disks, turn on "EBS encryption by default" in EC2 settings, in every region you use. Databases in RDS must be encrypted when they are created, so check each one's encryption setting.
• Backups run automatically, and someone has restored one recently. A backup nobody has tried to restore is a guess. Our post on backups you have actually restored shows how to test one in about an hour.
• Important buckets keep old versions. S3 versioning means a deleted or overwritten file can be brought back.
• You know which country your data is in. Pick the region that matches where your customers and your regulators are, such as Mumbai or Hyderabad for an Indian business, and make sure someone owns that decision.

4. Would you know if something went wrong?

Only if something is recording and someone is reading. The first question after any incident is what happened and when, and without records nobody can answer it.

• CloudTrail has a trail recording every region. Without a trail, AWS keeps only 90 days of event history. Store the trail's logs in a bucket that very few people can change.
• GuardDuty is on. It watches for signs of trouble, such as sign-ins from unusual places or servers talking to known bad addresses, and raises a finding.
• Root sign-ins trigger an alert. Ask whoever manages the account to set an email alert for any root sign-in. It should almost never fire.
• Someone reads the findings every week. Security Hub or AWS Config gathers the setting checks in one place. An alert nobody reads protects nothing.

5. Is there a plan for when something does go wrong?

There should be, written down before you need it. You are not checking settings here. You are checking that a plan exists.

• There is a one-page plan saying who decides, who to call and where the backups are. The backups post lists what goes on it.
• An emergency login exists for responders, stored somewhere safe and separate, so a locked-out admin doesn't stop the response.
• You know to save evidence before fixing. The AWS Security Incident Response Guide advises taking disk snapshots before deleting or rebuilding a compromised server.
• Contracts with providers say who handles a breach, and how fast they must tell you. Canada's Auditor General found the security clauses in government cloud contracts unclear and not standardized.

What does the full 30-point check add?

The next layer down. These 21 checks cover the most common gaps. Our free 30-point AWS security check adds firewalls for public apps, encryption-key rotation, separate accounts for separate workloads, and a yearly rehearsal of the plan. It runs in your browser, connects to nothing, and gives you a fix list ordered by risk.

A self-check is not a penetration test. If you hire testers to attack your setup on purpose, they need your written permission and must follow AWS's penetration testing policy.

Running a business website rather than servers? Sites built with Quantum Accord are hosted for you, so there is no server to patch and no port to leave open.