AWS Security Baselines Every Organization Should Implement

AWS gives you an enormous control surface — and an enormous amount of rope. Most teams we meet are not lacking security services; they are lacking a baseline. Without one, every new account, every new workload and every new engineer starts the security conversation from zero.

This article walks through the AWS security baseline that Cleverina deploys on every engagement. It is opinionated, mapped to the AWS Well-Architected Security pillar and designed to scale from a startup with one account to a regulated enterprise with hundreds.

1. Multi-account from day one

AWS Organizations and Control Tower turn the account boundary into your strongest control. The baseline:

• Separate accounts for production, non-production, security tooling, log archive and shared services.
• Service Control Policies that block disabling of CloudTrail, GuardDuty, Config and Security Hub anywhere in the org.
• A single, write-once log-archive account that other accounts cannot read, let alone delete from.
• Region restrictions on workload OUs so that data residency is enforced by policy, not goodwill.

2. Identity: federation, least privilege, no long-lived keys

Human identities should come from IAM Identity Center (the artist formerly known as SSO) federated to your corporate IdP — typically Entra ID. Workloads should use IAM roles assumed via OIDC (for CI/CD), instance profiles or IRSA for EKS. Long-lived access keys should be the rare exception, rotated automatically and stored in Secrets Manager.

Combine this with permission boundaries on every developer role, IAM Access Analyzer running continuously, and quarterly access reviews. The objective is not 'least privilege one day' — it is least privilege as a default-on posture.

3. Networking that defaults to private

Every workload account gets an opinionated VPC: private subnets only, no IGW unless explicitly required, VPC endpoints for S3, DynamoDB, KMS and Secrets Manager so traffic to AWS APIs never leaves the AWS backbone. Egress is centralized through an inspection account running AWS Network Firewall or a third-party NVA, with allow-listed FQDNs for known SaaS dependencies.

Default security groups are emptied. Inbound 0.0.0.0/0 to anything but a load balancer is blocked by SCP. East-west traffic between accounts goes over Transit Gateway with intentional routing — not VPC peering meshes.

4. Data protection by default

S3 Block Public Access at the account level, KMS customer-managed keys for every data store, bucket and volume, and automatic encryption-in-transit via TLS-only bucket policies and HTTPS-only ALB listeners. Macie scans for PII drift, Backup is configured with cross-account vaults so a compromised production account cannot delete its own backups.

5. Detection and response

Turn on the full detection stack and centralize it:

• CloudTrail organization trail with data events for sensitive S3 buckets.
• AWS Config recording every supported resource with managed and custom rules.
• GuardDuty in every region of every account, including S3, Malware, EKS, RDS and Lambda protection plans where relevant.
• Security Hub aggregating findings from GuardDuty, Inspector, Macie, Access Analyzer and Config.
• Detective for the security team to actually investigate, not just receive, the findings.

Route high-severity findings to a channel where a human will see them within minutes — EventBridge to Slack/Teams, or to your SIEM. Build a small set of well-rehearsed runbooks: compromised IAM credential, exposed S3 bucket, EC2 with crypto-mining telemetry, EKS pod with unexpected egress.

6. Continuous compliance, not point-in-time audits

Security Hub ships with conformance packs for CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS and NIST 800-53. Turn on the ones that match your regulatory context and treat the score as an operating metric — not an annual report.

Pair this with infrastructure-as-code policy-as-code: cfn-guard, Checkov or OPA running in CI/CD so violations are caught before they land in an account. The cheapest finding to fix is the one that never deploys.

7. Operate it

Like every governance baseline, AWS security only works if it has an operating cadence. Monthly Security Hub review with assigned owners, quarterly access reviews and exception decommissioning, annual posture assessment, and a clear ownership model for every finding category. Cleverina's AWS Security & Governance practice helps teams stand this up and then operate it — including the unglamorous parts like exception management and decommissioning legacy workloads.

Where to start

If you have a single AWS account with everything in it, the first move is multi-account: Control Tower or Landing Zone Accelerator, log archive separated, and SCPs blocking the disabling of detection services. Everything else compounds on that foundation.

If you want a second set of eyes on your current AWS posture, our team runs governance-focused AWS reviews end-to-end. Browse our services page or contact us for a scoped engagement.