April 4, 2026 · Tim Fraser, Cloud Operations Lead
Setting Up a Security Baseline for Your AWS Account
Whether you just experienced a security incident or you're setting up a new AWS account, the question is the same: what does "secure enough" actually look like?
AWS has hundreds of security controls. Compliance frameworks list thousands of requirements. The practical question is: what are the things that prevent 95% of real-world incidents?
This is that list. Each item is specific, verifiable, and directly prevents a category of breach that actually happens in production.
Identity and access
Enable MFA on every IAM user with console access. The single highest-impact security control. Compromised passwords are a leading cause of breaches, and MFA stops nearly all of them. Virtual MFA (authenticator apps) is sufficient.How to check: IAM → Users → MFA column. Any user with console access and no MFA is a gap.
Delete root account access keys. The root account should never have programmatic access keys. If they exist, remove them.How to check: Sign in as root → Security Credentials → Access Keys.
No shared credentials. Every person should have their own IAM user or SSO identity. Shared accounts make CloudTrail useless because you can't tell who did what. Use IAM roles instead of long-lived access keys. EC2 instances, Lambda functions, and ECS tasks should use roles, not access keys in environment variables. Every access key can leak. Roles can't.How to check: IAM → Credential Report. Access keys older than 90 days are the most likely to be embedded somewhere they shouldn't be.
Logging and visibility
CloudTrail enabled in all regions. CloudTrail records every API call in your account. Without it, you have no audit trail. Create a trail that applies to all regions and logs to S3 with versioning enabled.How to check: CloudTrail → Trails. At least one trail with "All regions" and "Logging" ON.
S3 access logging on sensitive buckets. Server access logs capture object-level requests in more detail than CloudTrail. Enable on buckets containing sensitive data. VPC Flow Logs enabled. Flow Logs capture network traffic metadata. Without them, you have no visibility into what's communicating with what. Enable on production VPCs at minimum.Network security
No security groups allowing SSH (22) or RDP (3389) from 0.0.0.0/0. One of the most common misconfigurations and most exploited. Use Systems Manager Session Manager or restrict to specific IP ranges.How to check: EC2 → Security Groups. Look for inbound rules allowing ports 22 or 3389 from 0.0.0.0/0 or ::/0.
No "all traffic" rules from 0.0.0.0/0. Equivalent to having no firewall. Often created during debugging and left in place. Default security groups should block all traffic. Every VPC has a default security group. It should allow no inbound or outbound traffic, so resources accidentally attached to it are protected.Data protection
EBS volumes encrypted. Enable default EBS encryption per region: EC2 → EBS → Settings → Always encrypt new EBS volumes. Existing unencrypted volumes need replacing via encrypted snapshot and restore. S3 buckets not publicly accessible. Enable S3 Block Public Access at the account level, then whitelist specific buckets that genuinely need to be public.How to check: S3 → look for "Publicly accessible" labels. Also check account-level Block Public Access settings.
RDS instances not publicly accessible. Databases should live in private subnets. The "Publicly Accessible" flag is frequently set to Yes during setup and forgotten.How to check: RDS → Databases → Connectivity section → "Public accessibility" field.
Account-level settings
Enable AWS Config. Config records the configuration state of your resources over time. This lets you answer questions like "when did this security group rule change?" and "what did this IAM policy look like last month?" Set up billing alerts. Unusual spend can indicate compromised resources (crypto mining on EC2 is still common). Set up an AWS Budget with alerts at 80% and 100% of expected monthly spend. Enable GuardDuty. GuardDuty analyses CloudTrail, VPC Flow Logs, and DNS logs for suspicious activity. It's a managed service with no infrastructure to deploy — just turn it on.Verifying your baseline with one question
Going through this list manually takes about an hour, and you need to repeat it regularly because infrastructure changes constantly.
plainfra checks your security baseline with read-only API calls against your live account. Ask "Check my account security baseline" or be specific: "Are any security groups allowing SSH from anywhere?" or "Which IAM users don't have MFA?" Current results, not a scan from last Tuesday.
Weekly health reports flag when your baseline drifts — a new rule opens a port, an IAM user appears without MFA, CloudTrail gets disabled. You fix the gap before it becomes an incident.
Try plainfra free → 50K tokens, 7 days, no charge. Or see the interactive demo →.