Hardening an AWS account means closing the default or legacy settings attackers exploit: lock down the root user, replace IAM users and long-lived access keys with single sign-on and MFA, log all activity with CloudTrail, turn on GuardDuty threat detection, block public access to S3 and databases, and keep backups nobody can delete. This checklist sequences that work into day 1, week 1 and month 1 so a startup or SMB can make progress without stalling product delivery.
What AWS hardening is, and why it is your job
AWS hardening is the process of configuring identities, network, storage, logging and backups across your accounts to shrink the attack surface and detect abuse early. Under the shared responsibility model, AWS secures the physical infrastructure and the services themselves; who has access, what is exposed to the internet and how your resources are configured is on you.
The same issues show up in young companies again and again: the account was opened with a founder's personal email, years-old access keys sit on a former contractor's laptop, a database was made public "just for testing," and nobody reads the logs. None of these needs a sophisticated attacker. If you are preparing for SOC 2, most of what follows also becomes audit evidence.
Identity and access: the foundation
- Root user: a group email address (not personal), a long password in a password manager, MFA (ideally a hardware key) and no access keys. AWS now enforces MFA for root by default, but you still need to register it. Use root only for the handful of tasks that require it.
- IAM Identity Center (formerly AWS SSO): people sign in once and get temporary credentials, federated with your identity provider (Okta, Google Workspace, Microsoft Entra ID) and with MFA required. Retire IAM users with console passwords.
- No long-lived access keys: workloads use IAM roles; CI pipelines use OIDC to get short-lived credentials (covered in our DevSecOps CI/CD guide). If a key must exist, rotate it and monitor its use.
- Least privilege: permission sets per job function (developer, operations, read-only, billing) instead of AdministratorAccess for everyone. IAM Access Analyzer flags external access and unused permissions.
Multi-account with AWS Organizations and SCPs
One account for production, staging and experiments is a liability: a mistake in dev can hit prod, and permissions blur. With AWS Organizations, separate at least production, non-production, security/logging and backup accounts. Service Control Policies (SCPs) set guardrails that even an account admin cannot bypass, for example:
- Deny disabling CloudTrail, GuardDuty or AWS Config.
- Restrict usable regions to the ones you actually run in.
- Prevent accounts from leaving the organization.
Organizations also supports centralized root access management for member accounts, letting you remove member root credentials so privileged tasks run only from the management account.
Logging, detection and security posture
- CloudTrail: a multi-region organization trail delivering to a bucket in the logging account, with log file validation and encryption. Without it, you cannot reconstruct what happened after an incident.
- GuardDuty: managed threat detection that analyzes account, network and workload activity (credentials used from unusual locations, crypto-mining, traffic to known malicious infrastructure). Enable it in every account and region.
- AWS Config: resource inventory and configuration history, the basis for compliance rules.
- Security Hub and Security Hub CSPM: in 2025 AWS split the original service, now called Security Hub CSPM (posture management against standards such as AWS Foundational Security Best Practices and the CIS AWS Foundations Benchmark), from the new Security Hub, which correlates findings from GuardDuty, Inspector, Macie and CSPM to prioritize risk. For an SMB, enabling CSPM with the AWS and CIS standards is the fastest way to get a concrete fix list.
Data, network and compute
- S3 Block Public Access at the account (or organization) level. New buckets are private by default, but a policy change can open them; the account-level block prevents that. Serve static sites through CloudFront with private bucket access.
- KMS encryption for EBS (default encryption on), RDS, S3 and backups, with key rotation and key policies that limit who can use them.
- Security groups: no 0.0.0.0/0 rules to admin ports (22, 3389) or database ports. Use AWS Systems Manager Session Manager instead of internet-facing SSH.
- IMDSv2 required on EC2. Since 2024 you can set it as the account default per region; it blunts SSRF-based theft of instance role credentials.
- RDS not publicly accessible, in private subnets, encrypted, with automatic minor version upgrades.
- VPC Flow Logs on production VPCs to investigate suspicious traffic.
Backups that survive an attacker
An attacker with admin rights in your account can delete instances, snapshots and buckets. AWS Backup centralizes protection, and AWS Backup Vault Lock in compliance mode means that once the grace period (at least three days) ends, nobody, not the root user and not AWS, can delete recovery points before their retention expires. Combine it with copies in a separate backup account and test restores regularly. It is the same principle we apply against ransomware in SMBs.
Billing alerts as a security signal
A bill that spikes overnight is often the first sign of stolen credentials being used for crypto-mining. Set up AWS Budgets with email alerts and Cost Anomaly Detection, and route GuardDuty findings and root sign-in alerts to a channel someone actually watches (a group inbox, Slack or Teams). An alert nobody reads is no alert. Decide in advance who responds and how, with an incident response plan.
Prioritized checklist: day 1, week 1, month 1
| When | Task |
|---|---|
| Day 1 | Root MFA, delete root access keys, group email on root |
| Day 1 | Account-level S3 Block Public Access |
| Day 1 | Enable GuardDuty and a multi-region CloudTrail trail |
| Day 1 | AWS Budgets and Cost Anomaly Detection alerts |
| Day 1 | Remove 0.0.0.0/0 on ports 22, 3389 and database ports |
| Week 1 | IAM Identity Center with MFA; delete IAM users and unused keys |
| Week 1 | Security Hub CSPM with AWS Foundational Security Best Practices and CIS; AWS Config |
| Week 1 | IMDSv2 by default; private RDS; EBS default encryption |
| Week 1 | Root usage and GuardDuty alerts to a monitored channel |
| Month 1 | AWS Organizations with separate accounts and protective SCPs |
| Month 1 | AWS Backup with Vault Lock and a restore test |
| Month 1 | OIDC for CI/CD; least-privilege review with Access Analyzer |
| Month 1 | Session Manager instead of SSH; VPC Flow Logs |
To go further, use the Security Pillar of the AWS Well-Architected Framework and the CIS AWS Foundations Benchmark. CIS releases new versions periodically, and Security Hub CSPM evaluates many of its controls automatically. An external review of your accounts against these frameworks is part of our cloud security services.
Frequently asked questions
Is AWS secure by default?
AWS secures the physical infrastructure and its services, and it has improved several defaults, such as private S3 buckets and enforced root MFA. But identity, permissions, network exposure, logging and backups are the customer's responsibility under the shared responsibility model. Most cloud incidents stem from leaked credentials or misconfigured resources, not from flaws in AWS itself.
How much do GuardDuty, Security Hub and CloudTrail cost?
CloudTrail's management event history is included at no charge; additional trails and data events are billed. GuardDuty and Security Hub are priced by the volume of events and resources analyzed, and GuardDuty offers a 30-day free trial that shows your estimated cost. For small accounts the total is usually modest, but check the AWS pricing calculator for your workload.
What is the CIS AWS Foundations Benchmark?
It is a secure configuration guide for AWS accounts published by the Center for Internet Security, with verifiable controls for identity, logging, monitoring, storage and networking. Auditors widely recognize it, and you can assess it automatically with Security Hub CSPM, which supports several benchmark versions.
Does a small startup really need multiple AWS accounts?
Separating production from everything else is strongly recommended. AWS Organizations accounts carry no charge of their own, and isolation limits the blast radius of a mistake or a compromised developer credential. Dedicated logging and backup accounts also protect evidence and recovery points if production is compromised.
How often should we review AWS security?
Review GuardDuty and Security Hub findings continuously, ideally through automated alerts. Do a full review of permissions, accounts and configuration at least quarterly, and an external cloud security assessment or penetration test annually or after major architecture changes. Many SOC 2 programs expect evidence of these periodic reviews.
Conclusion
AWS hardening does not require a dedicated security team; it requires sequencing. Lock down root, move people to Identity Center with MFA, remove long-lived keys, log everything with CloudTrail, enable GuardDuty and Security Hub CSPM, block public exposure and keep immutable backups. The day 1, week 1, month 1 plan gets you there without freezing the roadmap.
MisterProSoft is a nearshore team in UTC-5 that reviews AWS accounts against CIS and Well-Architected, fixes configurations and implements detection and backups alongside your engineers. Explore our cybersecurity services or book a free consultation.