Moving to the cloud is not the same as being secure. What truly makes AWS safe for small and mid-sized businesses is having identity, network, logging, threat detection and backup controls work together.
Cloud Security Is a Process, Not a Setting
AWS puts the same flexibility, scalability and security services that large enterprises rely on within reach of small and mid-sized businesses. But moving to the cloud is not the same as being secure. A misconfigured IAM user, a publicly exposed S3 bucket, an overly permissive Security Group, or disabled CloudTrail logs can all introduce serious risk.
For that reason, AWS security is not a checklist you run once after setup and forget. Identity management, network isolation, logging, threat detection, vulnerability scanning, backup, web application protection and cost control all have to be considered together.
In the 113SEC approach, AWS security starts by getting the core architecture right, then adds layers of visibility, alerting, threat detection, active protection and regular reporting. The following ten controls are a practical starting point for a secure AWS environment.
1. Don't Use the Root Account Daily, and Enforce MFA
The most critical identity in any AWS account is the root account. Root is meant for account closure, billing changes, certain high-level security operations and access recovery, which is exactly why it should not be used for day-to-day work.
The first control is straightforward: set a strong password on the root account, enable MFA, and never create root access keys. Use separate IAM users or roles for daily operations. This keeps access trails clearer and prevents risk from concentrating in a single account.
Control question: Is MFA enabled on the root account, do any root access keys exist, and has root been used unnecessarily in the last 90 days?
2. IAM, Roles and Least Privilege
IAM is the heart of AWS security. It decides who can access which service, on which resource, and at what level. The most important principle here is least privilege, granting only the minimum access required.
Every user and role should receive only the permissions needed to do the job. A technical administrator, a billing user, a sales user who only reads reports, and the roles used by services should all be kept separate. When a service like EC2 needs access to S3 or CloudWatch Logs, assign an IAM Role instead of embedding access keys.
Control question: Is MFA enabled for every IAM user, are permissions broader than necessary, and are there access keys older than 90 days?
3. Isolate VPC, Subnets and Security Groups
Security in AWS is not only about user permissions; the network architecture has to be right too. Public subnets, private subnets, a DMZ, a backup subnet and a management subnet should each be designed for a distinct purpose. That way, even if one service is breached, an attacker cannot move directly across the entire infrastructure.
Avoid the "Allow All" mindset in Security Groups, and restrict SSH and RDP access through VPN or a bastion host wherever possible. Customer agent connections, management access and web traffic should each be governed by separate rules.
Control question: Are any management ports open to 0.0.0.0/0, have unnecessary Security Group rules been cleaned up, and is VPC Flow Logs enabled?
4. Manage S3 Bucket Security Deliberately
S3 is a powerful storage service for log archiving, backups, customer reports and operational files. But misconfigured S3 buckets remain one of the most common cloud security mistakes.
Enable Block Public Access on all buckets, make server-side encryption the default, turn on versioning for critical buckets, and consider Object Lock for logs such as CloudTrail that must stay immutable. For backup or report archives, S3 Lifecycle rules help keep costs down.
Control question: Are there any public buckets, is encryption and versioning active on critical buckets, and is access limited to the IAM roles that actually need it?
5. Enable CloudTrail in Every Region
CloudTrail records the API calls made in your AWS account. The answer to "who did what, and when?" comes from CloudTrail, which makes it foundational for incident response, compliance and auditing.
Enable CloudTrail across all regions, write logs to S3, also forward them to CloudWatch Logs, and turn on log file validation. Events such as root login, IAM changes, Security Group openings, S3 public access and CloudTrail being stopped should additionally raise alarms.
Control question: Is CloudTrail multi-region enabled, are logs protected against tampering, and are alarms defined for critical events?
6. Turn On Threat Detection with GuardDuty
GuardDuty is a managed threat detection service that continuously monitors your AWS environment. It analyzes suspicious behavior across VPC Flow Logs, CloudTrail and DNS logs, surfacing findings such as unauthorized access attempts, port scans, malicious DNS queries, S3 access anomalies and crypto mining.
Its biggest advantage is fast visibility without building any infrastructure. Findings can flow into Security Hub, be sent to teams via SNS, and be wired to automated actions through EventBridge or Lambda.
Control question: Is GuardDuty enabled, is S3 Protection active, and is there a notification or response flow for high-severity findings?
7. Consolidate Findings in Security Hub
As an AWS environment grows, findings scatter across services: GuardDuty detects threats, Inspector finds vulnerabilities, IAM Access Analyzer reveals externally exposed access, and WAF generates traffic events. Security Hub brings these findings into a single central dashboard.
Security Hub also helps track your compliance score against standards like the AWS Foundational Security Best Practices and the CIS AWS Foundations Benchmark. That way, not only technical findings but your overall security posture can be reported at the management level.
Control question: Is Security Hub enabled, are the GuardDuty, Inspector and IAM Access Analyzer integrations connected, and are failed controls reviewed regularly?
8. Make Vulnerabilities Visible with Inspector
Over time, the operating system packages running on EC2 servers and your container images can accumulate vulnerabilities. Inspector provides CVE-based vulnerability scanning for EC2 instances and ECR container images.
Critical and High findings should move into the patch process quickly, with internet-facing vulnerable services prioritized first. When Inspector findings are evaluated alongside agent-based vulnerability detection such as Wazuh, you gain more complete visibility.
Control question: Does Inspector cover all your EC2/ECR resources, is there an SLA for critical and high findings, and are old findings being closed out?
9. Route Web Traffic Through WAF, ALB and a DMZ
Internet-facing services such as web applications and support portals should not be exposed directly to backend servers. Using an Application Load Balancer together with AWS WAF lets you receive traffic in a controlled way.
On WAF you can apply AWS Managed Rules, the SQLi rule set, Known Bad Inputs, rate limiting, and where needed IP allow-lists or geo blocking. Starting in Count mode to observe is a good way to avoid accidentally blocking legitimate traffic. A DMZ subnet structure also separates web services from Active Directory, file servers, backup and internal systems.
Control question: Does external traffic arrive through the ALB, can WAF be bypassed, and is the web server restricted to accept traffic only from the ALB?
10. AWS Backup, Vault Lock and Restore Drills
A secure AWS environment doesn't just try to block attacks; it also plans for recovery when an incident happens. That is why AWS Backup, backup plans, the Backup Vault, KMS encryption, cross-region copies and restore tests matter.
Backups shouldn't only be taken, they should be restorable on a regular basis. Vault Lock prevents backups from being deleted or modified for a defined period, adding protection against ransomware scenarios. For critical systems, a monthly restore drill is recommended.
Control question: Is an AWS Backup plan active, are critical resources included via tag-based plans, has Vault Lock been considered, and was the last restore test successful?
Bonus: Cost Alerts Are Part of Security
Security in the cloud covers not only attack risk but also the risk of uncontrolled resources and cost. A NAT Gateway left open by misconfiguration, unused Elastic IPs, unattached EBS volumes, or logs kept too long can all create unexpected charges.
Add a cost widget to your CloudWatch dashboard, use AWS Budgets, define billing alarms, and clean up unused resources regularly. A secure and sustainable cloud operation also keeps cost visible.
Conclusion: Start with a Checklist, Mature Through Continuous Monitoring
The biggest mistake in AWS security is assuming the services are secure by default. AWS offers strong security services, but they have to be enabled, configured, monitored and reported on correctly.
When you apply root MFA, least-privilege IAM, VPC isolation, S3 security, CloudTrail, GuardDuty, Security Hub, Inspector, WAF and Backup, your AWS environment becomes far more secure and manageable. At 113SEC our goal is not just to build your AWS environments, but to manage them in a way that is visible, traceable and sustainable. To review the security posture of your cloud infrastructure, get in touch with us.