AWS Security Checklist 2025 — 10 Critical Settings Every Startup Must Configure | Kuboid Blog

AWS Security Checklist 2025 — 10 Critical Settings Every Startup Must Configure

TLDR: If you do nothing else after reading this, do these ten things. They cover the majority of what I find wrong in startup AWS accounts — and most of them take less than 10 minutes each. No new tools to buy. No consultants required. Just configuration changes that are already available in your AWS account, waiting to be enabled.

Before You Start: Run AWS Trusted Advisor

Before working through this list manually, spend two minutes on this first. Navigate to AWS Trusted Advisor in the console and open the Security category. Trusted Advisor automatically checks many of these items and flags what needs attention. On Business and Enterprise support plans it's comprehensive; on the free tier it covers the most critical security checks — MFA on root, IAM key rotation, S3 bucket permissions, and security group exposure.

It won't replace this checklist, but it tells you immediately which items are already in good shape and which aren't. Start there, then work through what it flags.

The 10-Item Checklist

✅ 1. Enable MFA on the Root Account

Time: 5 minutes | Impact: Critical

The root account has unrestricted access to everything in your AWS account — it cannot be constrained by any IAM policy. If it's compromised without MFA, your entire account is gone.

How to do it:

Sign into the AWS Console as root
Click your account name (top right) → Security credentials
Under Multi-factor authentication (MFA) → Assign MFA device
Choose Authenticator app (Google Authenticator, Authy, or 1Password work well)
Scan the QR code and enter two consecutive codes to confirm

Once done, store the root account credentials somewhere secure and don't use them for anything except account-level operations that specifically require root.

✅ 2. Delete Root Account Access Keys

Time: 2 minutes | Impact: Critical

Root access keys grant programmatic API access with unrestricted permissions and no MFA requirement. They should not exist. Ever.

How to do it:

In the AWS Console → click your account name → Security credentials
Under Access keys — if any exist, click Delete on each one
There is no legitimate use case for root access keys. Delete them without exception.

If any systems are currently using root access keys, create a dedicated IAM user or role with the minimum permissions that service actually needs, update the system to use the new credentials, then delete the root keys.

✅ 3. Enable CloudTrail in All Regions

Time: 10 minutes | Impact: High

CloudTrail logs every API call made in your AWS account — who did what, from where, and when. Without it, you have no audit trail after a breach. You cannot answer "what did the attacker access?" if CloudTrail wasn't running.

How to do it:

Navigate to CloudTrail → Trails → Create trail
Name it something clear: management-events-all-regions
Under Trail settings: enable Apply trail to all regions — this is critical, attackers frequently operate in regions you don't normally use
Enable Management events (read and write)
Create a new S3 bucket for log storage with a name like [accountid]-cloudtrail-logs
Enable Log file validation — this detects if log files are tampered with

Cost is minimal — typically under $5/month for most startup accounts.

✅ 4. Enable S3 Block Public Access at Account Level

Time: 2 minutes | Impact: High

This is the single most effective control against accidental public S3 exposure. It overrides any individual bucket policy or ACL that would make a bucket public — a master switch for the entire account.

How to do it:

Navigate to S3 → Block Public Access settings for this account
Click Edit
Enable all four checkboxes:
- Block public access to buckets and objects granted through new ACLs
- Block public access to buckets and objects granted through any ACLs
- Block public access to buckets and objects granted through new public bucket or access point policies
- Block public access to buckets and objects granted through any public bucket or access point policies
Save changes

If any of your applications legitimately need to serve public content via S3 (a static website, public assets), do this at the account level and then create a specific bucket-level exception with a narrowly scoped policy for that specific use case.

✅ 5. Audit IAM Users and Remove Unnecessary Admin Access

Time: 20 minutes | Impact: Critical

AdministratorAccess is the most powerful policy in IAM. It should be attached to the minimum number of users necessary — and "necessary" should be scrutinised carefully.

How to do it:

Navigate to IAM → Users
For each user, click their name → Permissions tab → check attached policies
For any user with AdministratorAccess: ask whether they genuinely need it. Most developers need access to specific services, not the entire account.
Replace broad admin policies with service-specific policies where possible. AWS provides managed policies like AmazonEC2FullAccess, AmazonS3FullAccess, AWSLambda_FullAccess as starting points — then scope further.
Disable any users who are no longer active: select user → Security credentials → Console password → Disable. For former employees, disable immediately, review, then delete.

Download the IAM Credential Report (IAM → Credential Report) for a complete view of all users, their last login, and key ages before you start.

✅ 6. Enable AWS Config for Configuration Drift Detection

Time: 15 minutes | Impact: High

AWS Config continuously monitors your resource configurations and alerts when they drift from your defined baseline. It's the mechanism that catches when a previously secure S3 bucket gets accidentally made public, or when a security group rule is added that opens unexpected access.

How to do it:

Navigate to AWS Config → Get started
Select Record all resources → enable recording in all regions
Create a new S3 bucket for Config logs
Under Rules → Add rule, search for and enable these managed rules to start:
- s3-bucket-public-read-prohibited
- s3-bucket-public-write-prohibited
- iam-root-access-key-check
- mfa-enabled-for-iam-console-access
- restricted-ssh — flags security groups allowing SSH from 0.0.0.0/0

Each rule runs continuously and sends alerts via SNS when violations are detected.

✅ 7. Review Security Groups — Remove 0.0.0.0/0 on SSH and RDP

Time: 15 minutes | Impact: High

A security group rule that allows inbound SSH (port 22) or RDP (port 3389) from 0.0.0.0/0 means the entire internet can attempt to connect to your instances. Automated scanners find these within minutes and begin brute-force attempts continuously.

How to do it:

Navigate to EC2 → Security Groups
For each security group, click Inbound rules
Look for any rule with port 22 or 3389 and source 0.0.0.0/0 or ::/0
Edit the rule to restrict the source to:
- Your office IP range if connections come from a fixed location
- Your VPN CIDR if you use a corporate VPN
- A bastion host security group if you use a jump server
If no one is actively using SSH/RDP access, remove the rule entirely

The restricted-ssh AWS Config rule from item 6 will flag any new security groups that violate this going forward.

✅ 8. Enable GuardDuty for Threat Detection

Time: 5 minutes | Impact: High

GuardDuty is AWS's managed threat detection service. It analyses CloudTrail logs, VPC Flow Logs, and DNS logs using machine learning to detect anomalous behaviour — credential use from unusual locations, crypto mining patterns, unusual API call sequences, communication with known malicious IPs.

How to do it:

Navigate to GuardDuty → Get started → Enable GuardDuty
That's it for basic setup. GuardDuty begins analysing activity immediately.
Optionally, configure an SNS topic for findings notifications: Settings → Findings export options

Cost for a startup-scale account is typically $1–10 per month. The 30-day free trial covers initial setup. This is one of the highest signal-to-noise security controls available in AWS — it surfaces real incidents, not just configuration warnings.

✅ 9. Rotate All IAM Access Keys Older Than 90 Days

Time: 20 minutes | Impact: High

Long-lived access keys are a liability. A key that's been active for 18 months has had 18 months of opportunities to be leaked, intercepted, or forgotten in a decommissioned system. Rotation limits the exposure window.

How to do it:

Download the IAM Credential Report (IAM → Credential Report → Generate report → Download)
Open in a spreadsheet, filter for rows where access_key_1_last_rotated or access_key_2_last_rotated is older than 90 days and access_key_1_active is TRUE
For each key that needs rotation: IAM → Users → [user] → Security credentials → Create access key
Update the system or application using the old key to use the new one
Once confirmed working: deactivate the old key for 48 hours (as a safety net), then delete it

For keys used by humans rather than services, consider replacing with IAM roles or using AWS SSO (IAM Identity Center) to eliminate long-lived keys entirely.

✅ 10. Enable Encryption at Rest for RDS, S3, and EBS

Time: Varies | Impact: High

Encryption at rest ensures that even if an attacker gains physical access to storage media — unlikely given AWS's physical security, but relevant in breach scenarios — your data is unreadable without the encryption keys.

RDS: Encryption must be enabled at creation time and cannot be added to an existing unencrypted instance. To encrypt an existing RDS instance: create an encrypted snapshot → restore a new instance from the encrypted snapshot → update your connection strings → delete the unencrypted original.

S3: For new buckets, encryption is enabled by default since January 2023. For older buckets: S3 → Bucket → Properties → Default encryption → Edit → Enable SSE-S3 or SSE-KMS.

EBS: New EBS volumes can be encrypted at creation. To enforce encryption on all new volumes going forward: EC2 → Settings → EBS encryption → Enable Always encrypt new EBS volumes.

After the Checklist: What This Doesn't Cover

These ten items address the most common and highest-impact gaps in startup AWS accounts. They don't cover everything: application-layer security, secrets management practices, IAM permission boundaries, VPC architecture, container security, CI/CD pipeline hardening, or compliance-specific requirements.

Think of this as the baseline — the floor, not the ceiling. Once these are in place, the next step is understanding what's above the floor in your specific environment.

A professional cloud security review goes deeper: examining IAM privilege escalation paths, reviewing application-level access to cloud resources, testing for SSRF vulnerabilities that expose the metadata endpoint, and analysing the specific configuration decisions that are unique to your architecture. If you want that level of review after completing this checklist, get in touch.

You can explore what a full cloud review covers on our services page, read more about how we work, or find more guides like this on the Kuboid blog.

Kuboid Secure Layer provides cloud security assessments and penetration testing for startups and growing businesses. Visit www.kuboid.in.

AWS Security Checklist 2025 — 10 Critical Settings Every Startup Must Configure