A minimum AWS security baseline for startups

1. Lock down the root user

Every AWS account has a root user that can do anything. Give it MFA (a hardware key where you can), delete any root access keys, and stop using it for day-to-day work. AWS’s own security standard checks for exactly these.

2. Separate accounts, with guardrails

Put production in its own account, inside AWS Organizations, and use service control policies for the rules no one should be able to break, such as switching off logging. See an AWS account structure for a growing company.

3. People sign in through IAM Identity Center

Connect IAM Identity Center to your identity provider and require MFA. People get temporary credentials for the account and role they need. Then remove IAM users and their long-lived access keys, which are a common cause of breaches.

4. Pipelines use OIDC, not keys

CI/CD pipelines should assume a role with short-lived credentials instead of storing access keys. See deploying to AWS from GitHub Actions without access keys.

5. Log everything, somewhere safe

Create an organisation-wide CloudTrail trail covering all regions, with log file validation on, delivered to a separate log archive account that workload accounts can’t change.

6. Turn on detection

• Amazon GuardDuty watches for suspicious activity, such as credentials used from unusual places or instances talking to known bad hosts.
• AWS Config records how resources are configured, and how that changes over time.
• AWS Security Hub CSPM, with the AWS Foundational Security Best Practices standard, checks your accounts against a few hundred specific controls and shows what fails.

Manage all three from one delegated administrator account in the security part of your organisation, so new accounts are covered automatically.

7. Protect data and the network

• Turn on S3 Block Public Access and EBS encryption by default.
• Keep databases and workloads in private subnets, and use security groups that allow only what is needed.
• Put AWS WAF in front of public applications and APIs.
• Keep secrets in AWS Secrets Manager or Parameter Store, never in code or environment files.

Then what

Fix the failing Security Hub CSPM controls in order of severity, and review access regularly. Build all of this as code, so a new account gets the same baseline automatically. See AWS security and DevSecOps.

Sources

• AWS: AWS Foundational Security Best Practices standard
• AWS: Best practices for a multi-account environment