Download Complete Checklist Here
Let me be straight with you: most AWS environments don't get compromised because of some genius-level hacker running a zero-day exploit. They get compromised because someone left an S3 bucket public, forgot to rotate a credential, or spun up a dev environment with admin access "just temporarily", and that temporarily became two years.
I've seen it. You've probably seen it too.
This checklist isn't a theoretical whitepaper. It's what actually matters when you're securing AWS in 2026. Direct, a little opinionated, and rooted in what works in real environments.
What's Actually New in 2026
AWS has made real progress. Mandatory MFA on root accounts is finally enforced. IAM Identity Center has matured into something you'd genuinely recommend to a client. GuardDuty now correlates signals across Kubernetes runtime behavior, API calls, and audit logs to catch multi-stage attacks. There's GenAI traffic monitoring in Network Firewall if you're running AI workloads and in 2026, a lot of us are.
Good stuff. Real progress.
But the fundamental risks haven't changed. Misconfiguration is still the leading cause of cloud breaches. Overprivileged identities are still everywhere. People are still committing access keys to GitHub. The basics still bite hardest.
Start With Structure — Not Services
Before you touch a security group or encryption setting, decide how your accounts are organized. This single decision affects everything downstream, and yet it's the most commonly skipped step because it feels like infrastructure, not security.
It is absolutely a security concern.
The core idea is blast radius reduction. If something goes wrong, a compromised credential, a misconfigured resource, how much can an attacker reach? If everything lives in one account, the answer is "everything."
Use AWS Organizations to group accounts with a management account, separate production, staging, sandbox, and dedicated accounts for logging and security tooling. Apply Service Control Policies as hard guardrails, rules that prevent any account from disabling CloudTrail or creating public S3 buckets, regardless of who's asking. These are free, powerful, and most teams haven't touched them.
If you're starting fresh, AWS Control Tower gives you a working multi-account structure with secure defaults already wired. Use it. Don't spend three weeks reinventing something AWS already built.
Identity: Where Most Breaches Actually Begin
Long-lived access keys sitting in .aws/credentials, baked into a CI environment variable, or hardcoded in a Lambda function are one of the most common attack vectors in cloud environments today. The old model — create IAM users, hand out keys, hope for the best, is broken.
The modern approach: use IAM Identity Center connected to your identity provider. Humans get short-lived role-based access they assume through a browser or CLI. No long-lived keys. No managing passwords inside AWS. When someone leaves the company, one action in your identity provider revokes access to every AWS account at once.
For applications and services, Lambda functions, ECS tasks, EC2 instances, every piece of code that needs AWS access should assume a role scoped to exactly what it needs. Not a shared role. Not AdministratorAccess because it was faster to set up. The right role, the right permissions, nothing more.
Real least privilege means reviewing what permissions are actually being used and removing what isn't. IAM Access Analyzer can generate policy recommendations from actual CloudTrail activity so you're not guessing. Run it. Act on the findings. Remove unused roles, policies, and access keys on a regular schedule.
And MFA, require it everywhere. For all human identities. Especially administrators. Prefer hardware keys or passkeys over TOTP apps where possible since they resist phishing in ways one-time codes don't.
Network: Default Private, Exception Public
The rule is simple: if something doesn't need to be reachable from the internet, it shouldn't be. Application servers in private subnets. Databases in private subnets. Caches, queues, internal services, all private. The only things in public subnets are load balancers, API gateways, and NAT gateways. Their job is to be the controlled entry point. Everything else sits behind them.
Security groups should be tight. "Allow all from 0.0.0.0/0" is a rule you should see and immediately want to understand. There's rarely a good reason. Security groups are stateful and cheap to be specific with — no performance penalty for precise rules, so no excuse for lazy ones.
For public-facing applications: put them behind Application Load Balancer or API Gateway, attach AWS WAF with managed rule groups for SQL injection, XSS, and known bad actors, and add Shield Advanced if you're a meaningful DDoS target. This stack handles a large proportion of automated attacks without your team lifting a finger.
Data: Encrypt Everything, Then Verify
Encryption isn't just a compliance checkbox. It's what protects you when other controls fail — when someone accesses storage they shouldn't, when a disk is improperly decommissioned, when a backup ends up somewhere unexpected.
Enable default encryption for every service that supports it: S3, EBS, RDS, Aurora, DynamoDB, EFS, all backups. This is often one setting or already on by default. Encode it into your infrastructure templates so every new resource is encrypted without someone needing to remember.
For sensitive workloads, use customer-managed KMS keys so you control rotation, access, and audit logs. Separate key admin from key usage — these are distinct privileges that shouldn't live in the same role.
For S3 specifically: enable Block Public Access at the account level. This prevents any bucket or object in your account from being made publicly accessible, regardless of bucket policy. Any exception to this should require a deliberate, reviewed decision, not an accidental default.
And backups: having them is different from testing them. Know how long a full restore takes. Test it on a schedule. This knowledge is worthless in advance and invaluable at 2 AM.
Detection: Let Managed Services Watch While You Sleep
Enable GuardDuty across all accounts. It analyzes CloudTrail, DNS, VPC Flow Logs, and behavioral signals from EKS environments. Extended Threat Detection for Kubernetes correlates runtime events, audit logs, and API calls to flag multi-stage attacks that would look like noise in isolation. Route findings into whatever incident management tool your team actually uses, a finding that sits in the console unseen is not a finding, it's a log entry.
Enable CloudTrail in every region for every account, and send those logs to a centralized logging account that workload accounts can write to but cannot modify or delete. This matters because a compromised account shouldn't be able to cover its own tracks.
Security Hub pulls findings from GuardDuty, Config, Inspector, and WAF into a single prioritized view. Enable the AWS Foundational Security Best Practices standard. Triage the findings. Assign ownership. This is a continuous process, not a one-time setup.
Amazon Inspector scans EC2, containers, Lambda, and open-source dependencies for vulnerabilities. The key move is integrating it into your CI/CD pipeline so vulnerable images or misconfigured templates never reach production in the first place.
DevSecOps: Catch It Before It Ships
Define infrastructure as code, CloudFormation, CDK, Terraform, whatever fits your team. The point is that code can be reviewed, scanned, and consistently reproduced. A console-configured environment has no audit trail and no reliable way to verify its state.
Scan your infrastructure code in CI pipelines before changes merge. Tools like Checkov or tfsec catch unencrypted resources, overly permissive security groups, and missing logging configuration at the point when they're cheap to fix. A failed scan blocking a pull request is a five-minute code change. The same misconfiguration found in a security audit eighteen months later is a multi-day remediation project.
Scan container images before they deploy. Block images with critical vulnerabilities from reaching production. Enforce it, don't let teams bypass the gate because a release is urgent.
Quick Reference Checklist
Foundation
- AWS Organizations with management, app, logging, and audit accounts
- Service Control Policies blocking dangerous actions organization-wide
- Root accounts locked, offline credentials, MFA enforced, never used for daily work
Identity
- IAM Identity Center replacing IAM users for all humans
- MFA required for every human identity, hardware keys preferred
- Roles scoped per workload with least-privilege policies
- IAM Access Analyzer enabled, findings triaged regularly
Network
- Private subnets for all application and data tiers
- Security groups with specific, minimal rules
- WAF and Shield on all public endpoints
Data
- Default encryption on S3, EBS, RDS, DynamoDB, EFS, and backups
- Customer-managed KMS keys for sensitive data
- S3 Block Public Access at account level
- Tested backup restore procedures
Detection
- CloudTrail in all regions, centralized to a protected logging account
- GuardDuty across all accounts including EKS
- Security Hub with AWS Foundational Security Best Practices standard
- Inspector integrated into CI/CD pipelines
- All findings routed to your incident response workflow
DevSecOps
- All infrastructure as code
- Templates and images scanned in CI before deployment
- Policy gates in pipelines that actually block non-compliant changes
One Last Thing
There's a version of this that becomes a 200-item spreadsheet nobody ever finishes. The version that works is simpler: start with the things that give you the biggest risk reduction for the least effort, GuardDuty, CloudTrail, Security Hub, IAM Identity Center, MFA everywhere, S3 Block Public Access. Get those right. Then work through the rest one workload at a time.
Security in AWS isn't a project with a finish line. It's a practice. The goal isn't to be done — it's to be measurably better than you were six months ago, with fewer gaps and a team that knows what to do when something goes wrong.
For most teams, that's closer than it looks.
How Bithost can help
Many teams understand the checklist on paper but struggle to turn it into a working and affordable security baseline. Bithost, specialises in practical cloud and security engineering for exactly this gap including AWS design, security audits, SIEM, DLP and exposure assessment services. The focus is on building production ready setups that match real world constraints instead of textbook diagrams.
Bithost, backed by ZHOST Consulting, helps startups, SMBs, and government organizations build practical AWS security baselines that fit their real-world constraints, not textbook diagrams.
Reach us at sales@bithost.in or +91 911-336-6525.
Frequently asked questions
The threat landscape has shifted from simple misconfigurations to sophisticated "agency-based" attacks. With the rise of Agentic AI, static security rules can’t keep up with autonomous systems that execute code and call APIs in real-time. At Bithost, we specialize in moving beyond "textbook" setups. We implement advanced behavioral monitoring and guardrails specifically designed to secure the autonomous loops of Agentic AI, ensuring your innovation doesn't become a security liability.
While automated tools like AWS Security Hub are essential for catching basic errors, they often miss the logical flaws in complex, multi-account architectures. Bithost provides a deep-dive engineering audit that looks at your "blast radius" and business logic. We don't just hand you a list of 200 errors; we prioritize remediation based on your actual risk profile—whether you're a lean startup or a large-scale industrial operation—saving you weeks of irrelevant patching.
The most common risk is "Overprivileged Agency"—granting AI agents broad AdministratorAccess to speed up development. This allows an attacker to use a "confused deputy" attack to manipulate your AI into leaking data or deleting infrastructure. Bithost helps teams build Identity-Aware Access Controls and purpose-bound permissions, ensuring your AI agents have exactly the power they need to work, and zero power to cause a breach.
