AWS Security Baseline Guide

In December 2024, a massive credential theft operation linked to ShinyHunters and Nemesis gangs exploited misconfigured public websites to steal over 1,526 AWS customer credentials in a single month—plus source code, database credentials, and API keys. One victim accrued $30,000 in AI API charges in three hours after their keys were stolen. Another startup discovered their S3 bucket had been publicly exposing job seeker PII for months. These incidents share a pattern: basic AWS security controls were missing or misconfigured.

Why a Baseline Matters

Early-stage startups often defer security until "we have time." By then, a breach or failed due diligence can kill a deal or a company. An AWS security baseline doesn't require enterprise budgets—it requires intent. Here's what to implement first.

1. IAM Least Privilege

The problem: Broad roles that "just work." A compromised service or developer account can access far more than intended.

The fix:

- Create roles per service or function. Grant only the permissions each needs.

- Use policy conditions (e.g., MFA required for sensitive actions, IP restrictions).

- Avoid `*` in resource ARNs. Scope to specific buckets, tables, or queues.

- Prefer IAM roles over long-lived access keys. Use SSO with MFA for human access.

- Review permissions quarterly. Remove unused roles and policies.

2. Secrets Management

The problem: Hardcoded API keys, database passwords in .env files committed to Git. Credentials leak within minutes of exposure.

The fix:

- Use AWS Secrets Manager or Parameter Store. Never commit credentials.

- Rotate secrets regularly. Automate rotation where possible.

- Use IAM roles for AWS service-to-service auth (Lambda, ECS, EC2). No keys in code.

- Scan repos for leaked secrets. Use git-secrets or TruffleHog in CI.

3. Encryption Everywhere

The problem: Unencrypted RDS, DynamoDB, or S3. Data breaches and compliance failures.

The fix:

- Enable encryption at rest for RDS, DynamoDB, S3, EBS. Use AWS KMS.

- TLS for all data in transit. Enforce HTTPS. No plaintext APIs.

- S3: Enable default encryption. Use bucket policies to deny unencrypted uploads.

4. S3 and Public Access

The problem: Misconfigured bucket policies. Public read or write. Customer data exposed.

The fix:

- Block public access by default on all S3 buckets.

- Explicitly allow only what's needed. Avoid `Principal: "*"` with broad actions.

- Audit bucket policies regularly. Use AWS Config or open-source tools.

- Enable access logging. Monitor for unexpected access patterns.

5. Network Isolation

The problem: Default VPC, security groups with 0.0.0.0/0, no segmentation.

The fix:

- Use custom VPCs. Segment by environment (dev, staging, prod).

- Restrict security groups to least privilege. No 0.0.0.0/0 unless absolutely required (e.g., public load balancer on 80/443 only).

- Private subnets for databases and internal services. NAT for outbound only.

- Consider VPC endpoints for AWS services to avoid internet traversal.

6. Audit Logging

The problem: CloudTrail disabled or not monitored. When something goes wrong, there's no trail.

The fix:

- Enable CloudTrail for all regions. Log to a separate account or S3 with retention.

- Set up alerts for suspicious activity: console logins from new IPs, IAM changes, S3 bucket policy changes.

- Retain logs for at least 90 days. Longer for compliance (e.g., 1 year for SOC2).

7. Cost and Billing Alerts

The problem: AWS bills spiral without warning. Forgotten resources, runaway Lambda, stolen keys running up AI API costs.

The fix:

- Set billing alerts at 50%, 80%, 100% of budget.

- Use Cost Explorer. Tag resources by project, environment, owner.

- Enable AWS Budgets with forecasted alerts. Review spend weekly.

Getting Started

Prioritize: IAM, secrets, encryption, S3. Add logging and cost controls. A consultant who specializes in startup cloud security can accelerate the process and catch gaps before they become incidents. The baseline isn't optional—it's the foundation everything else builds on.