AWS security audit: 12 critical checks to identify misconfigurations before they become incidents

The scenario is a familiar one. The AWS account is a few years old, several developers and contractors have had access, keys were created for a script, a bucket was opened to share a few files. Nothing is broken, so nobody looks, until a customer's security questionnaire arrives or a contractor leaves: what is actually exposed?

An AWS security audit compares an account's actual configuration against a set of explicit checks (identities, data exposure, networking, secrets, logging, backups, detection, patching, account structure, incident response), documents every gap with evidence, then ranks the gaps by severity so the fixes can be organised. It is a snapshot at a given date: it reduces uncertainty, it does not guarantee that no incident will happen.

Below: the twelve checks, how to prioritise findings, a preparation checklist and the deliverables to expect from an engagement.

What an AWS security audit covers

AWS secures the infrastructure that runs its services. The customer remains responsible for what it configures: identities, access, networking, encryption, data and, depending on the service, the operating system and its patches. Most avoidable incidents originate in that second part.

AWS describes this split in its shared responsibility model: security "of" the cloud is AWS's job, security "in" the cloud is the customer's, and the boundary shifts from one service to another: on EC2, the guest operating system and its patches are yours.

A misconfiguration is a setting that grants more access, more exposure or less visibility than the business actually decided. It often produces no visible error: the application works, the risk stays latent.

Not every finding is of the same kind. A useful audit separates them:

A configuration audit is not a penetration test, an application code review or a compliance certification.

The 12 checks of an AWS security audit

For each check: what to verify, why it matters, a possible gap, its consequences and the first actions. The gaps described are examples, not statistics.

1. IAM identities and permissions

AWS Identity and Access Management (IAM) defines who can do what, on which resources: every other safeguard depends on it.

• What to verify: existing users, groups and roles; policies that grant the "*" wildcard on actions or resources; identities with full administrator access; unused identities.
• Why it matters: AWS recommends granting only the permissions required to perform a task and regularly removing what is no longer used.
• Possible gap: administrator access given "temporarily" to a contractor and never revoked.
• Consequence: one compromised identity opens up the entire account, not just the scope it needed.
• First actions: use last accessed information to remove unused identities and permissions, then gradually narrow overly broad policies, starting with production.

2. The root user, privileged accounts and multi-factor authentication

• What to verify: recent use of the root user, any root access keys, MFA on the root user and on every privileged identity, and how people sign in.
• Why it matters: the root user has permissions that cannot be restricted by an IAM policy. AWS publishes dedicated guidance on protecting it and recommends federated sign-in with temporary credentials for people, for example through IAM Identity Center.
• Possible gap: a root user used day to day, protected by a single password shared between co-founders.
• Consequence: loss of control over the whole account, billing included.
• First actions: enable MFA on the root user and on privileged access, preferring phishing-resistant methods such as security keys and passkeys; keep the root user for the few tasks that require it.

3. Access keys and long-term credentials

• What to verify: active access keys, their age, their last use, and where they are stored (laptops, scripts, continuous integration tools).
• Why it matters: an access key does not expire on its own. AWS recommends temporary credentials wherever possible and, when keys are unavoidable, updating and removing them based on their last-used data.
• Possible gap: a key created for a deployment years ago, still active, sitting in the history of a code repository.
• Consequence: whoever holds the key acts with its permissions, without MFA, from anywhere.
• First actions: deactivate unused keys, replace pipeline keys with assumed roles (OpenID Connect federation), then search your repositories for exposed keys.

4. Public exposure of S3 buckets and data

• What to verify: S3 Block Public Access settings at account and bucket level, bucket policies, access control lists and cross-account shares.
• Why it matters: new buckets are not public by default, but a policy or ACL can open them. AWS recommends turning on all four Block Public Access settings for the account, after checking that your applications work without public access.
• Possible gap: a bucket opened to host a few public files that also holds database exports.
• Consequence: data readable by anyone who knows or guesses the bucket name.
• First actions: turn on account-level blocking, isolate the few genuinely public assets in a dedicated bucket, and check public and cross-account access with IAM Access Analyzer.

5. Networking, security groups and inbound access

• What to verify: inbound rules open to 0.0.0.0/0 (the whole internet), especially on administration ports (SSH 22, RDP 3389) and database ports; publicly accessible databases; resources deployed in the default VPC without a deliberate decision.
• Why it matters: a security group is a firewall whose configuration is explicitly the customer's responsibility.
• Possible gap: an SSH port open to the entire internet "for troubleshooting", or a database exposed publicly for an analytics tool.
• Consequence: a direct attack surface, where any flaw in the exposed service can be exploited.
• First actions: restrict sources, move databases into private subnets, and replace direct SSH access with AWS Systems Manager Session Manager where possible.

6. Secrets and encryption keys

• What to verify: where database passwords, API tokens and private keys live (code, plain-text environment variables, instance user data, a secrets manager); who can read them; who can use KMS keys to decrypt.
• Why it matters: a secret readable by too many identities cancels out other safeguards. A service such as AWS Secrets Manager centralises access and supports automatic secret rotation.
• Possible gap: the production database password written in plain text in a version-controlled configuration file.
• Consequence: direct access to the data, often invisible in AWS logs because it goes through the database itself.
• First actions: inventory your secrets, move them into a secrets manager, restrict read access to the applications that need them, then rotate any secret that has been exposed.

7. Audit logging and CloudTrail

• What to verify: a CloudTrail trail covering all Regions, read and write management events, log file integrity validation, and how the log bucket is protected and how long logs are kept.
• Why it matters: without logs, there is no way to know who did what after an incident. AWS recommends a multi-Region trail with log file integrity validation, which lets you demonstrate that a log file has not been changed or deleted.
• Possible gap: a trail limited to a single Region, stored in a bucket that account administrators can empty.
• Consequence: activity in an unused Region goes unnoticed; an attacker with elevated rights can erase their tracks.
• First actions: enable a multi-Region trail, protect the destination bucket, ideally in a separate account, and set a retention period consistent with your obligations.

8. Backups and restore capability

• What to verify: what is backed up and what is not, frequency, retention, where copies are stored and, above all, when a restore was last tested.
• Why it matters: a backup that has never been restored is an assumption. AWS Backup offers scheduled restore testing, which also measures how long a restore takes.
• Possible gap: backups stored in the same account as production, deletable by the same identities.
• Consequence: after a compromise or an accidental deletion, the copies disappear along with the original data.
• First actions: define, for each application, the acceptable data loss and the acceptable downtime (RPO and RTO, defined in our migration guide), copy critical backups to another account, then run an actual restore.

9. Monitoring, alerting and anomaly detection

• What to verify: whether a threat detection service and continuous configuration checks are enabled, and where alerts actually go.
• Why it matters: Amazon GuardDuty analyses CloudTrail events, VPC flow logs and DNS logs, among other sources, to flag compromised credentials or cryptomining. AWS Security Hub CSPM assesses your configuration against standards such as AWS Foundational Security Best Practices.
• Possible gap: services switched on whose alerts land in an inbox nobody reads.
• Consequence: the incident is discovered by a customer or through the bill. A sudden cost spike can itself be a security signal: it is one of the indicators covered in our method for reducing an AWS bill.
• First actions: enable detection in every Region you use, route serious alerts to a named person, and define what that person should do when they receive one.

10. Updates, patching and vulnerability management

• What to verify: the age of operating systems and container images, database engine versions, and how patches are applied.
• Why it matters: on EC2, the guest operating system and its patches are the customer's responsibility. Amazon Inspector scans EC2 instances, container images in Amazon ECR and Lambda functions for software vulnerabilities and unintended network exposure.
• Possible gap: a hand-built instance, never updated, running an internet-facing service.
• Consequence: exploitation of a publicly known vulnerability.
• First actions: inventory systems and versions, enable vulnerability scanning, schedule patching (AWS Systems Manager Patch Manager for instances) and rebuild container images regularly.

11. Environment segmentation and separation of duties

• What to verify: whether production shares an account with development and testing; who can deploy, who can approve, who can delete logs or backups.
• Why it matters: the AWS account is the clearest isolation boundary. With AWS Organizations, service control policies (SCPs) set guardrails that apply to every identity in an account.
• Possible gap: a developer with the same rights in production as in testing, for lack of separation.
• Consequence: a mistake or compromise in a secondary environment reaches production directly.
• First actions: at minimum, isolate production in a dedicated account, use a guardrail to prevent logging from being disabled, and separate the person who changes from the person who approves for sensitive operations. The exact scope depends on team size: it is an architecture choice to document.

12. Incident response, recovery and documentation

• What to verify: a written procedure, security contacts filled in on the account, break-glass access, architecture documentation, and the date of the last exercise.
• Why it matters: the AWS Security Incident Response Guide emphasises preparation: procedures, access to tools and logs, simulated exercises.
• Possible gap: nobody knows who can isolate a compromised instance, or how, on a Friday evening.
• Consequence: improvised decisions, destroyed evidence, longer recovery.
• First actions: write a short procedure for likely scenarios (exposed key, open bucket, compromised instance), name the people responsible, test it.

How to prioritise findings

An audit often produces more findings than a team can fix at once. Priority comes down to four criteria: exposure, impact, ease of exploitation and the risk of the fix itself.

This grid is a working method, not a standard: severity depends on the data involved. Each fix also carries its own risk: closing a port can break an application that relied on it.

Checklist: preparing an AWS security audit

• The list of AWS accounts, Regions in use and their owners is established.
• The root user is protected by MFA and has no active access key.
• People sign in through federation or through named identities with MFA.
• Active access keys are listed, with their age and last use.
• Identities and permissions unused for several months are identified.
• S3 Block Public Access is enabled at account level, or every exception is justified.
• No administration port and no database is open to the whole internet.
• Secrets live in a secrets manager, not in code or version-controlled files.
• A multi-Region CloudTrail trail with integrity validation is active and protected.
• Critical backups exist outside the production account and a restore has been tested.
• Threat detection is enabled and its alerts reach a named person.
• Systems, images and database engines are inventoried with their versions.
• Production is isolated from development and test environments.
• An incident response procedure exists and states who makes decisions.

What a professional AWS audit should deliver

A professional audit is judged by what it hands over: a written scope, a baseline of the current setup, evidenced findings, a prioritisation and a remediation plan your team can actually execute.

Be wary of a report that declares an environment "secure": an audit describes a scope at a date. What changes afterwards, or what sat outside the scope, is not covered; security is maintained through continuous checks.

Frequently asked questions

What is an AWS security audit?

It is a review of one or more AWS accounts against explicit checks: identities and permissions, data exposure, networking, secrets, logging, backups, detection, patching, account structure and incident response. Every gap is documented, evidenced and ranked by severity.

Does an AWS security audit guarantee there will be no incident?

No. It reduces uncertainty about a given scope at a given date. Later changes, application flaws, human error and anything outside the scope are not covered. Its purpose is to decide what to fix first.

What access does an auditor need?

Read-only access is enough for a configuration audit. A dedicated, time-limited role is preferable to handing over access keys; AWS managed policies such as SecurityAudit or ReadOnlyAccess are often used as a starting point.

How often should you run an AWS security audit?

There is no universal frequency. An audit makes sense after a major change, when a contractor leaves, before a fundraising round, a sale or a migration, or when nobody can describe what the account contains. Between audits, automated checks take over.

Is AWS Security Hub CSPM enough to audit an account?

It is a good starting point that automates many checks. It does not know your context (sensitive data, legitimate access, deliberate exceptions): its results still need to be interpreted and prioritised.

Conclusion: measure, prioritise, then fix

Securing an AWS account rests on a few questions asked methodically: who has access, what is exposed, what can you see when something happens, can you restore, do you know how to respond. An audit answers them for a given scope and turns the answers into an action plan.

CERVOX Services carries out read-only AWS account audits as scoped engagements: you receive an inventory of the analysed resources, the main points of attention, a structured analysis, recommendations, a debrief and the documentation. Fixes can then be handled through an engagement to implement the action plan or an alerts and backups engagement, which includes an actual restore. You receive a written estimate within 24 business hours after a first 20-minute conversation: describe your situation in a few lines and we will tell you whether we can help, and how. If you are launching an application, see also our production deployment checklist.