DEV Community: ABRAR ASLAM

The 5 AWS Security Mistakes I Keep Finding in Small Business Accounts

ABRAR ASLAM — Tue, 20 Oct 2026 11:35:07 +0000

And how to check your own account for each one in about 15 minutes, using only the AWS CLI

Most small businesses on AWS are not hacked through some clever zero-day exploit. They are caught out by settings that took two minutes to get wrong and would take ten minutes to fix.

The numbers say this is not a big-company problem. The UK Government's Cyber Security Breaches Survey 2025/2026 estimates that 43% of UK businesses had a cyber security breach or attack in the previous 12 months, and among those that identified one, 88% said it involved phishing. Stolen passwords and leaked keys are how attackers get in.

And once they are in, they are rarely noticed quickly. IBM's 2025 Cost of a Data Breach findings for the UK put the average time to identify a breach at 148 to 168 days. That is around five months of someone else having access to your systems.

On AWS, the platform itself is rarely the weak point. Under the shared responsibility model, AWS secures the data centres, hardware and services. You are responsible for how your account is configured: who can sign in, what is open to the internet, and whether anyone would notice if something went wrong.

Here are the five mistakes I see most often, why each one matters, and exactly how to check for it.

First, a two-minute scorecard

Answer honestly. Each "no" or "not sure" is a gap.

Does your AWS root user have MFA, and is it never used for day-to-day work?
Are all IAM access keys less than 90 days old, and does every key belong to someone who still works with you?
Are SSH, RDP and database ports closed to the whole internet?
Is S3 Block Public Access turned on for the whole account?
Would you get an alert if someone started using your account at 3am?

If you answered "yes" to all five, you are ahead of most small businesses. If not, read on.

Before you start: every command below is read-only. You need the AWS CLI and credentials with read access (the AWS-managed SecurityAudit policy is enough). Some commands only cover the region your CLI is set to; there is a script at the end that checks every region at once.

1. The root user is unprotected, or still in use

Why it matters. The root user is the email address that created the AWS account. It can do anything, including closing the account or changing billing details, and no IAM policy can restrict it. In small companies it is common to find the root user shared between people, used for everyday work, or protected by nothing more than a password. With phishing behind most breaches, a stolen root password is the worst case.

How to check:

aws iam get-account-summary \
  --query 'SummaryMap.{RootMFA: AccountMFAEnabled, RootAccessKeys: AccountAccessKeysPresent}'

You want RootMFA: 1 and RootAccessKeys: 0.

How to fix. Turn on MFA for the root user, ideally a hardware security key or passkey. Delete any root access keys. Then stop using root altogether: give each person their own sign-in, preferably through IAM Identity Center, and keep the root credentials somewhere safe for emergencies only.

2. Long-lived access keys that never expire

Why it matters. IAM access keys do not expire on their own. A key created three years ago for a deployment script, a developer's laptop or a contractor who has since left still works today. Keys also leak easily: committed to a Git repository, pasted into a chat, or left in an old .env file.

How to check. The IAM credential report lists every user, their keys, and when each key was last rotated and last used:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv

(On older Macs, use base64 -D instead of base64 --decode.)

Open the CSV and look for keys that are active but were last rotated more than 90 days ago, keys that have never been used, and users who have no MFA or who no longer work with you.

How to fix. Delete keys nobody uses and rotate the rest. Better still, remove the need for them. People can sign in through IAM Identity Center with short-lived credentials, workloads on AWS can use IAM roles, and CI/CD pipelines such as GitHub Actions and GitLab can use OIDC federation instead of stored keys.

3. Servers and databases open to the whole internet

Why it matters. A security group rule that allows 0.0.0.0/0 on port 22 (SSH), 3389 (RDP), or a database port such as 3306 or 5432 means anyone on the internet can try to connect. Automated scanners find these within minutes. The rule is usually added "temporarily" to debug something, and never removed.

How to check:

aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
            Name=ip-permission.from-port,Values=22,3389,3306,5432 \
  --query 'SecurityGroups[].[GroupId,GroupName]' --output table

Treat the result as a shortlist and open each group to confirm the rule. Check IPv6 rules (::/0) as well.

How to fix. Remove public access to admin and database ports. Use AWS Systems Manager Session Manager for shell access instead of SSH, which also gives you a log of every session. Keep databases in private subnets, and allow access only from the security groups that need it.

4. S3 buckets that are public by accident

Why it matters. Since April 2023, new S3 buckets block public access by default. But older buckets, and buckets where someone switched the protection off to share a file quickly, can still expose data to anyone with the link: customer exports, database backups, invoices.

How to check. First, see whether public access is blocked for the whole account:

aws s3control get-public-access-block \
  --account-id "$(aws sts get-caller-identity --query Account --output text)"

If that returns an error, or any setting is false, check individual buckets:

aws s3api get-bucket-policy-status --bucket YOUR-BUCKET-NAME

"IsPublic": true means the bucket policy makes it public. IAM Access Analyzer in the console answers the same question for every bucket at once.

How to fix. Turn on Block Public Access at the account level, unless you have a specific reason not to. If you need to serve public files, such as website images, put them behind CloudFront with a private bucket.

5. No logging or alerting, so nobody would notice

Why it matters. This one is easy to miss because nothing looks broken. Without an audit trail and threat detection, an attacker using a leaked key, or someone deleting a database by mistake, can go unnoticed for months. Remember the IBM figure: around five months, on average, before a UK breach is even identified.

How to check:

# Is there a trail, is it logging, and does it cover every region?
aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail]' --output table
aws cloudtrail get-trail-status --name YOUR-TRAIL-NAME --query IsLogging

# Is GuardDuty turned on in this region? (An empty list means no.)
aws guardduty list-detectors

How to fix. Create a multi-region CloudTrail trail that writes to a dedicated S3 bucket, and turn on GuardDuty in every region you use. GuardDuty has a 30-day free trial, and the console shows an estimate of the monthly cost before the trial ends. Most importantly, send its findings to an email address someone actually reads.

Bonus: check every region in one go

Attackers like regions you never use, because nobody looks there. This loop checks GuardDuty and open SSH or RDP ports in every region enabled for your account:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "== $region"
  echo -n "  GuardDuty detectors: "
  aws guardduty list-detectors --region "$region" --query 'DetectorIds' --output text
  echo -n "  Groups open on SSH/RDP: "
  aws ec2 describe-security-groups --region "$region" \
    --filters Name=ip-permission.cidr,Values=0.0.0.0/0 Name=ip-permission.from-port,Values=22,3389 \
    --query 'SecurityGroups[].GroupId' --output text
done

An empty GuardDuty line means it is off in that region. Any group IDs on the second line are worth a closer look.

Your 15-minute plan

You do not need to fix everything this afternoon. In order of impact:

Minutes 0–5: turn on MFA for the root user and delete any root access keys.
Minutes 5–10: generate the credential report and deactivate keys that are unused or belong to people who have left.
Minutes 10–15: turn on S3 Block Public Access for the account.

Then, this week: close public admin and database ports, and switch on CloudTrail and GuardDuty everywhere. Those two steps cover the most common way into a business, which is stolen credentials, and make sure you would actually notice if something happened.

Checking all of this automatically

The commands above work, but running them across every region, and remembering to repeat them every few months, is the hard part.

At KloudCare we built a free, read-only AWS assessment that checks all five of these, plus wasted spend and backup gaps, in about 10 minutes. It runs inside your own AWS account from a CloudFormation template you can read in full. It cannot change anything, and the report is saved to your own private S3 bucket. Nothing is sent to us unless you choose to share it.

👉 kloudcare.co.uk/assessment.html

Whichever way you check, treat each finding as something to confirm before changing. That open port might be the one your payment provider depends on, so talk to whoever owns it first.

KloudCare is a London-based AWS consultancy helping small and medium-sized businesses keep their AWS accounts cost-efficient, secure and recoverable. Find out more at kloudcare.co.uk.

Sources

UK Government, Cyber Security Breaches Survey 2025/2026: https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026/cyber-security-breaches-survey-20252026
IBM UK, Cost of a Data Breach Report 2025: https://uk.newsroom.ibm.com/2025-cost-of-data-breach-UK
AWS, Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/
AWS, Amazon S3 Block Public Access default for new buckets (April 2023): https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3-automatically-enable-block-public-access-disable-access-control-lists-buckets-april-2023/

Where Your AWS Money Is Really Going: 7 Places Cloud Waste Hides

ABRAR ASLAM — Tue, 13 Oct 2026 11:53:32 +0000

And how to find it in your own account in about 10 minutes, without giving anyone access

Most AWS bills tell a familiar story. They start small, grow with every new project, and at some point someone in finance asks why the cloud costs more this quarter than last. Nobody is quite sure.

You are not alone. In Flexera's 2026 State of the Cloud Report, organisations estimated that 29% of their cloud spend is wasted, up from 27% the year before and the first rise in five years. 85% said managing cloud spend is their top cloud challenge.

The waste is rarely one dramatic mistake. It is dozens of small things that nobody owns, nobody gets an alert for, and nobody has time to look at. Here are the seven places I find it most often, and how to check for each one.

1. Disks left behind after servers are deleted

When you terminate an EC2 instance, its EBS volumes are not always deleted with it. Volumes created separately, or attached with "delete on termination" switched off, stay behind in the available state, attached to nothing and billed every month.

How to check: in the EC2 console, open Volumes and filter by state available. Each one is a candidate for removal. Take a snapshot first if the data might matter.

2. Load balancers and IP addresses that serve nothing

Load balancers have an hourly charge whether or not they handle traffic. It is common to find one that was created for a test, a migration or a service that no longer exists, still running with no registered targets.

Elastic IP addresses that are not attached to anything also cost money, and since AWS began charging for every public IPv4 address, idle addresses add up across accounts and regions.

How to check: look for load balancers whose target groups are empty, and Elastic IPs with no association.

3. Servers far bigger than their workload

This is usually the largest single source of waste. An instance chosen "to be safe" at launch, or sized for a peak that never came, quietly runs at a few percent CPU for months.

How to check: in CloudWatch, look at average and maximum CPU over at least 14 days. An instance averaging under 10% with peaks under 40% is a strong candidate to downsize, stop or schedule. Remember that CPU does not show memory pressure, so check that too before resizing.

Older instance generations are worth a look as well. Datadog's State of Cloud Costs report found that 83% of organisations spend an average of 17% of their EC2 budget on previous-generation instances, which usually cost more for less performance.

4. Databases nobody connects to

RDS instances are easy to forget: a staging database from last year, a copy made for a one-off report, a database for a service that was retired. If it has had zero connections for two weeks, it is a strong candidate to snapshot and remove.

How to check: the CloudWatch metric DatabaseConnections, with the maximum over 14 days.

5. Containers asking for far more than they use

Containers make it easy to over-provision without noticing. Datadog found that 83% of container costs were associated with idle resources, split between clusters with too much spare capacity and workloads requesting more CPU and memory than they need.

How to check: compare your ECS services' or Kubernetes pods' CPU and memory utilisation against what they request. Services that average under 20% CPU and 30% memory are usually oversized.

6. NAT Gateways with almost no traffic

A NAT Gateway has a fixed hourly cost before any data is processed. A gateway that moves only a few gigabytes a month can cost far more than the traffic justifies, especially when there is one per Availability Zone in a quiet environment.

How to check: the BytesOutToDestination and BytesInFromDestination metrics. If the monthly total is tiny, consider consolidating gateways, using VPC endpoints for AWS services, or removing them from non-production environments.

7. Storage that never gets cleaned up

S3 buckets without lifecycle rules keep every object forever in the most expensive storage class, including incomplete multipart uploads you cannot even see in the console. Logs, exports and backups are the usual culprits.

How to check: look for buckets with no lifecycle rules, then agree retention with the owner and add rules to expire old data or move it to cheaper storage classes.

Why waste keeps coming back

Finding waste once is not the hard part. Keeping it gone is. In Harness's 2025 FinOps in Focus report, 48% of organisations said they do not track idle resources, and 86% of developers said it takes at least a week to spot idle, orphaned or unused resources and act on them.

Three habits make the biggest difference:

Tag everything with at least an Owner and an Environment, so every resource has someone to ask.
Set AWS Budgets and anomaly alerts, so a jump in spend is noticed in days, not at the end of the quarter.
Review regularly. A monthly look at the same checks catches new waste before it becomes normal.

And while you are looking: security and backups

In my experience, accounts with forgotten resources often have forgotten risks too: security groups open to the internet on SSH or database ports, users without MFA, unencrypted volumes, and backups that were assumed to exist but do not.

The stakes are real. The UK Government's Cyber Security Breaches Survey 2025/26 found that 43% of UK businesses had a breach or attack in the previous 12 months. And Sophos found that when attackers compromised the backups, median ransomware recovery costs were eight times higher.

So when you check for waste, check the basics of security and recovery at the same time.

Checking all of this in about 10 minutes

You can work through the list above by hand. It takes a while across every region, but it is worth doing.

If you would rather automate it, my team at KloudCare built a free, read-only AWS assessment that runs all of these checks, and more, in about 10 minutes:

It runs inside your own AWS account from a CloudFormation template you can read in full.
It is read-only. It cannot change, stop or delete anything, and it never reads your files, databases or secrets.
The report is saved to your own private S3 bucket. Nothing is sent to us unless you choose to share it.
Every finding shows its evidence and observation period, the recommended action, the risk of making the change, and an estimated monthly saving based on on-demand prices for your region.
Delete the stack and everything is removed.

You can run it here: kloudcare.co.uk/assessment.html

Treat every saving as a candidate, not an instruction. Confirm with the owner, take a snapshot where data matters, and test changes outside production first. An apparently idle resource can still have a purpose, such as disaster recovery.

KloudCare is a UK AWS consultancy helping small and medium-sized businesses keep their AWS accounts cost-efficient, secure and recoverable. Find out more at kloudcare.co.uk.

Sources

Flexera, 2026 State of the Cloud Report: https://www.flexera.com/about-us/press-center/flexera-finds-cloud-value-is-rising-while-ai-waste-grows
Datadog, State of Cloud Costs: https://www.datadoghq.com/state-of-cloud-costs/
Harness, FinOps in Focus 2025: https://harness.io/press-and-news/finops-in-focus-report-2025
UK Government, Cyber Security Breaches Survey 2025/2026: https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026/cyber-security-breaches-survey-20252026
Sophos, The Impact of Compromised Backups on Ransomware Outcomes (2024): https://assets.sophos.com/X24WTUEQ/at/539j6fwcmx6wk6whnhxc47/sophos-the-impact-of-compromised-backups-on-ransomware-outcomes-wp.pdf