AWS security: a practical guide to where to start

The shared responsibility model, in plain terms

AWS is responsible for the security of the cloud: physical data centers, network infrastructure, hardware. You are responsible for security in the cloud: how you configure access, which ports you leave open, whether you encrypt your data, who has access to what.

In practice, this means the vast majority of AWS security incidents are not AWS failures — they are configurations the customer left open: S3 buckets made public by mistake, unencrypted data, credentials hardcoded into source code, or simply nobody watching what is happening in the account.

Where to start: the areas we review first

Before getting into encryption, monitoring, and compliance, there is a foundation that has to be solid: who can do what inside the account — least privilege, MFA on privileged accounts, and temporary credentials instead of permanent keys. That topic is broad enough to deserve its own full guide: check out 5 AWS IAM mistakes that put small businesses at risk if you have not already. Here we focus on what comes after identity and access are handled.

Data encryption

Encryption is not a months-long project — for most AWS services it is a configuration checkbox enabled before the resource ever receives data. The typical problem is not technical, it is age: resources created years ago, before encryption was the default option, that nobody has revisited since.

• At rest: enable encryption with AWS KMS on S3, RDS, EBS, and any storage holding sensitive data. Set it as the default policy for new accounts and buckets, rather than a manual case-by-case review.
• In transit: enforce TLS on every connection, both between the end user and your application and between your own internal services.
• Key management: use KMS instead of handling encryption keys manually, and separate who can use a key from who can administer it. Rotate keys periodically and audit their use the same way you would audit an IAM permission.

Monitoring and threat detection

Good controls do not help much if nobody notices when something goes wrong. These three services cover different layers and complement each other.

Compliance and governance

• Define a documented security baseline — which controls are mandatory for any new account created, so they do not depend on someone remembering to set them by hand.
• Run periodic reviews, not just once when the engagement starts. An AWS account's configuration keeps changing as the team ships new things; a baseline that is never revisited goes stale fast.
• If you handle personal or health data, these controls are not optional — they are the foundation for complying with data protection regulations in your jurisdiction, whatever they are called locally.

A typical case

A mid-size company that comes to us wanting “a security review” almost always shows the same combination of findings: EBS volumes or S3 buckets created before encryption was the standard and never revisited since, CloudTrail active but with no alerts configured on it, GuardDuty never turned on because “we did not know it existed” despite costing little relative to what it catches, and no documented baseline — every new account inherits whatever someone happened to remember to configure manually. None of these findings are exotic: it is the same three or four patterns, over and over.

What is not realistic to promise

No security configuration, however good, eliminates risk entirely. Any provider promising “total security” or “zero risk of incidents” is selling you something that does not exist. What is realistic is reducing the attack surface, detecting quickly when something happens, and having a clear response plan — which is exactly where it is worth investing the effort.