AWS Security Best Practices: A Checklist for Startups
In short
- AWS publishes its own checklist for this: the AWS Startup Security Baseline (SSB), with 17 account controls and 15 workload controls. As of November 2026 it was last updated in July 2026.
- Most of the risk in a young AWS account sits in a few places: the root user, long-lived access keys, public S3 buckets, missing logs and secrets in code.
- You can cover the account-level basics in a few focused days, mostly with free or low-cost AWS features, and then tighten workloads as you grow.
This checklist is for founders, the first DevOps or backend engineer, and anyone who opened an AWS account for a startup and now "owns security" by default. You'll get a prioritized list of what to set up first, why each item matters, a few copy-ready commands, and a table you can use to track progress. It follows AWS's own guidance, so you're not relying on our opinion alone.
Start with AWS's own baseline
AWS Prescriptive Guidance includes the AWS Startup Security Baseline (SSB), a set of controls for early-stage startups that want a strong security foundation without much operational overhead. It's designed for a single AWS account and written so you can adapt it when you move to multiple accounts later. It is aligned with the security pillar of the AWS Well-Architected Framework and the AWS shared responsibility model: AWS secures the cloud itself, and you secure what you put in it, including identities, data, network rules and code.
The SSB splits its controls into two groups:
- Account controls (ACCT.01–ACCT.17): keep the AWS account itself safe, covering sign-in, permissions, logging, threat detection and spending.
- Workload controls (WKLD.01–WKLD.15): protect what runs in the account, covering credentials for applications, secrets, encryption, networks and deployment.
AWS republished the SSB with significant updates in April 2026 and added four controls in June 2026 (GuardDuty, Security Hub, Cost Anomaly Detection and Region restriction). The checklist below follows that order of priority, grouped into things a small team can do in a few days.
Day 1: lock down who can sign in
Identity is where most AWS incidents start, so it comes first.
- Set account contacts to group emails (ACCT.01). Use distribution lists for the billing, operations and security alternate contacts, not one person's inbox. AWS sends security notices there; they shouldn't disappear when someone goes on leave.
- Stop using the root user (ACCT.02). The root user can do everything, including closing the account. Use it only for the few tasks that require it. AWS's root user guidance adds: use a strong unique password, register MFA, never create root access keys, and use a group email address for the root login.
- Require MFA (ACCT.05). Since June 2025, AWS requires MFA for root users in all account types. Do the same for every human: prefer phishing-resistant options such as passkeys or security keys. Each user can register up to eight MFA devices, so register a backup.
- Give every person their own login (ACCT.03). AWS recommends federation with an identity provider through IAM Identity Center, so people get temporary credentials instead of IAM users with passwords and keys. IAM users are the fallback, not the default.
- Use short-lived credentials on the command line (ACCT.13). Since November 2025, the
aws logincommand (AWS CLI 2.32.0 or later) lets developers use their console sign-in to get temporary, automatically rotated credentials for the CLI and SDKs. That removes the most common reason people create long-lived access keys on laptops. - Grant least privilege (ACCT.04). Attach permissions to roles, start with AWS managed policies if you must, and narrow them over time. IAM Access Analyzer can generate a policy from the actions a role actually used.
Day 2: turn on logs and detection
If something goes wrong, you need a record of who did what, and something that tells you about it.
- CloudTrail to a protected S3 bucket (ACCT.07). CloudTrail's event history only covers the last 90 days. Create a multi-Region trail that delivers logs to an S3 bucket only a few people can change. The SSB notes that one copy of ongoing management events is free; you pay for S3 storage.
- Amazon GuardDuty (ACCT.14). Managed threat detection for things like compromised credentials and unusual API activity. The SSB recommends enabling it in all supported Regions; there is a 30-day free trial per Region so you can see the cost before committing.
- IAM Access Analyzer (ACCT.11). Enable it in each Region you use. It flags resources shared publicly or with other accounts, and it validates IAM policies against more than 100 checks.
- AWS Security Hub (ACCT.15). The SSB uses it with the AWS Foundational Security Best Practices standard to check your configuration continuously; it requires AWS Config in the same Region, which is billed separately. AWS now documents these posture checks as Security Hub CSPM, and the newer Security Hub (generally available since December 2025) correlates findings from CSPM, GuardDuty, Inspector and Macie.
- Trusted Advisor (ACCT.12). Review high-risk items regularly. Note that Basic Support only includes some checks.
Logs nobody reads don't help. Route GuardDuty and Security Hub findings to an email list or chat channel your team actually watches, and add an alert for root user sign-ins.
Day 3: close the obvious doors
- Block public S3 access at the account level (ACCT.08). Since April 2023, new buckets have Block Public Access on and ACLs disabled by default, but that didn't change older buckets. If you don't host public files directly from S3, turn it on for the whole account.
- Delete unused default VPCs, subnets and security groups (ACCT.09). Every Region comes with a default VPC; unused ones are places where resources can be launched by mistake.
- Restrict API calls to the Regions you use (ACCT.17). A deny policy on
aws:RequestedRegionstops someone, or a stolen credential, from quietly running resources in a Region you never look at. - Set budgets and anomaly alerts (ACCT.10, ACCT.16). A sudden bill is often the first sign of a compromised account (for example, crypto mining). AWS Budgets can alert on forecast overruns, and Cost Anomaly Detection is free.
A few commands to get started
These AWS CLI commands cover some account-level items. Run them with an admin role, in each Region where it applies, and replace the placeholder account ID and names with your own.
# Block public access for every S3 bucket in the account (ACCT.08)
aws s3control put-public-access-block \
--account-id 111122223333 \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
# Turn on GuardDuty in the current Region (ACCT.14)
aws guardduty create-detector --enable
# Create an account-level IAM Access Analyzer in the current Region (ACCT.11)
aws accessanalyzer create-analyzer --analyzer-name account-analyzer --type ACCOUNT
# Multi-Region CloudTrail trail (ACCT.07).
# The bucket must already exist with a bucket policy that allows CloudTrail to write.
aws cloudtrail create-trail --name main-trail \
--s3-bucket-name example-cloudtrail-logs --is-multi-region-trail
aws cloudtrail start-logging --name main-trailFor Region restriction, the SSB provides a deny policy you attach to roles and users (or use as a permissions boundary). Here is a shortened version; global services are excluded so IAM, billing and CloudFront keep working. Copy the full NotAction list from the SSB before using it.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideAllowedRegions",
"Effect": "Deny",
"NotAction": [
"iam:*", "sts:*", "cloudfront:*", "route53:*",
"support:*", "budgets:*", "ce:*", "organizations:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["ap-southeast-3", "us-east-1"]
}
}
}
]
}Then: secure the workloads
Once the account is in order, work through the workload controls as you build:
- Roles, not keys, for applications (WKLD.01, WKLD.02). EC2, Lambda, ECS and EKS can all receive temporary role credentials automatically. Use resource-based policies to limit where credentials can be used.
- Keep secrets out of code (WKLD.03–WKLD.05). Store them in AWS Secrets Manager or Systems Manager Parameter Store. Scan repositories with open-source tools such as Gitleaks, detect-secrets, git-secrets or TruffleHog, and rotate anything that has leaked.
- No open SSH or RDP (WKLD.06). Use Systems Manager Session Manager instead of bastion hosts or instances in public subnets.
- Encrypt and log data (WKLD.07–WKLD.09). Encrypt EBS volumes and RDS databases, and log S3 data events for buckets with sensitive data.
- Keep private things private (WKLD.10–WKLD.14). Put databases and internal services in private subnets, keep security groups tight, use VPC endpoints, require HTTPS, and put edge protection (for example AWS WAF or CloudFront) in front of public endpoints.
- Infrastructure as code (WKLD.15). Define security settings in templates (CloudFormation, CDK or Terraform) and deploy them through CI/CD so they're reviewed and repeatable.
The checklist
| When | Item | SSB control |
|---|---|---|
| Day 1 | Group emails for alternate contacts and root login | ACCT.01, ACCT.02 |
| Day 1 | MFA on root and every human; no root access keys | ACCT.02, ACCT.05 |
| Day 1 | IAM Identity Center logins; aws login for the CLI | ACCT.03, ACCT.13 |
| Day 1 | Least-privilege roles | ACCT.04 |
| Day 2 | Multi-Region CloudTrail to a protected bucket | ACCT.07 |
| Day 2 | GuardDuty, Access Analyzer, Security Hub, Trusted Advisor review | ACCT.11, ACCT.12, ACCT.14, ACCT.15 |
| Day 3 | Account-level S3 Block Public Access | ACCT.08 |
| Day 3 | Remove unused default VPCs; restrict Regions | ACCT.09, ACCT.17 |
| Day 3 | Budgets and Cost Anomaly Detection | ACCT.10, ACCT.16 |
| Ongoing | Roles for apps, secrets manager, secret scanning | WKLD.01–WKLD.05 |
| Ongoing | Session Manager, encryption, private subnets, HTTPS | WKLD.06–WKLD.14 |
| Ongoing | Security settings in infrastructure as code | WKLD.15 |
A note for Indonesian startups
If you serve users in Indonesia, AWS's Asia Pacific (Jakarta) Region (ap-southeast-3) has been open since December 2021. It's an opt-in Region, so it must be enabled before use, and you should include it in your Region restriction policy. Wherever your data lives, the Personal Data Protection Law (UU PDP, Law No. 27 of 2022) applies to personal data you process; logging, access control and encryption from this checklist help you show that you protect it.
Next steps
- This week: finish Day 1. Identity controls give the biggest risk reduction for the least effort.
- This month: complete Days 2 and 3, and make sure someone receives and reads the alerts.
- This quarter: work through the workload controls and move your setup into infrastructure as code. When you grow beyond one account, look at AWS Organizations and centralized root access management.
If you're building AI features on AWS, read our guide to the OWASP Top 10 for LLM Applications as well, or see our security services.
Want a second pair of eyes on your AWS account? Email Binjesoft and we can walk through this checklist with you and help prioritize the gaps. See our services for how we work.
Sources: AWS Startup Security Baseline (SSB) · AWS SSB (PDF, with document history) · AWS: Security best practices in IAM · AWS: Root user best practices · AWS: MFA enforced for root users across all account types (June 2025) · AWS: Console credentials for CLI and SDK (aws login) · AWS News Blog: Security Hub generally available · AWS: S3 Block Public Access default for new buckets · AWS News Blog: Asia Pacific (Jakarta) Region