AWS Security Consulting: Securing AWS Workloads Beyond the Basics

Every AWS account starts with a root user and an open canvas. The decisions you make in the first few weeks — how you structure IAM, whether you enable logging, how you segment your network — determine whether your environment becomes a fortress or a liability.

Here is the layered security approach we recommend to every client.

Before You Layer: The Security Baseline Audit

Before adding security controls, you need to understand where you stand. Many organizations we work with have been running AWS for 2–3 years and have accumulated technical security debt they are not aware of: IAM policies that started as AdministratorAccess and were never tightened, S3 buckets created during a hackathon that are still public, VPC security groups with 0.0.0.0/0 ingress that were opened for a test and never closed.

Five questions every AWS account should answer before adding controls:

1. Who has administrative access? Run the IAM credential report (aws iam generate-credential-report) and audit which users have AdministratorAccess or equivalent. Remove any access that has not been used in 90+ days.

2. Are any S3 buckets publicly accessible? Run aws s3api list-buckets and check S3 Block Public Access settings at the account and bucket level. A single misconfigured bucket is the most common cause of cloud data breaches.

3. Is CloudTrail enabled and storing logs securely? An organization-wide CloudTrail trail should exist, storing logs in a dedicated account with log file validation enabled and a retention policy of at least 12 months.

4. Have you enabled GuardDuty? GuardDuty operates on a simple principle: enable it everywhere, always. The threat detection it provides is near-zero cost relative to its value. There is no valid reason not to have it enabled in every account and region you use.

5. What does Security Hub show? If you have not run Security Hub’s AWS Foundational Security Best Practices standard against your account, do it now. The resulting score and findings list is your security baseline.

After helping a B2B SaaS CTO with a customer-driven security audit, we ran this exact five-question check. The findings included misconfigured IAM roles with unused administrative permissions, open VPC security group rules allowing broad ingress, and three S3 buckets with public read access from a development project that had been promoted to production. Within two weeks, we remediated those risks and established a security baseline aligned with SOC 2 and ISO 27001 standards — turning a customer liability into a customer confidence signal.

Layer 1: Identity and Access

IAM is the foundation. Most security incidents that we have investigated trace back directly to overly permissive IAM policies — not sophisticated zero-day exploits, but access that should not have existed in the first place.

Enforce Least Privilege

Start with IAM Access Analyzer. It identifies which permissions in your IAM policies have not been used in the last 90 days and generates least-privilege policy recommendations. Run it on your highest-risk roles (application deployment roles, developer roles, CI/CD pipeline roles) first.

Service Control Policies: Guardrails That Cannot Be Overridden

Service Control Policies (SCPs) at the AWS Organizations level are the most powerful security control in multi-account AWS environments. SCPs set maximum permissions — no identity in the account, including root, can perform an action if the SCP denies it.

Two SCPs we deploy to every client environment:

SCP 1: Prevent disabling S3 Block Public Access

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3PublicAccessDisable",
      "Effect": "Deny",
      "Action": [
        "s3:PutAccountPublicAccessBlock",
        "s3:DeleteAccountPublicAccessBlock",
        "s3:PutBucketPublicAccessBlock",
        "s3:DeleteBucketPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/SecurityBreakGlassRole"
        }
      }
    }
  ]
}

This ensures that no developer, application, or automation can accidentally re-enable public S3 access once you have locked it down. Only the break-glass security role can override it.

SCP 2: Enforce MFA for human users

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyWithoutMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        },
        "StringNotEquals": {
          "aws:PrincipalType": "AssumedRole"
        }
      }
    }
  ]
}

This policy denies all actions except MFA enrollment actions when a human user has not authenticated with MFA. It exempts assumed roles (service accounts) so applications are not affected.

Additional IAM Controls

• Require MFA everywhere — Not just the root account. All human users should have MFA enabled, enforced by the SCP above.
• Use IAM roles, not long-lived keys — Applications should assume roles via instance profiles or IRSA (IAM Roles for Service Accounts in EKS), never embed access keys.
• Rotate and audit regularly — IAM Access Analyzer and the credential report should run on a monthly schedule, with alerts for any key older than 90 days.

Layer 2: Detection and Monitoring

You cannot respond to threats you cannot see. The detection stack we recommend has three components.

Amazon GuardDuty: Continuous Threat Detection

GuardDuty continuously analyzes VPC Flow Logs, DNS query logs, and CloudTrail management events to detect:

• Reconnaissance: Unusual API calls, port scanning, credential discovery attempts
• Compromised credentials: Console logins from unusual geolocations, API calls from known malicious IPs, cross-account enumeration
• Cryptomining: GPU instance launches outside normal patterns, high-cost compute usage
• Data exfiltration: Unusual S3 GetObject patterns, large data transfers to external IPs

AWS introduced GuardDuty Extended Threat Detection in December 2024 — a significant capability upgrade that correlates individual findings into attack sequence signals. This is now a core feature of GuardDuty, expanded through 2025 to cover EC2, ECS, and additional AWS service contexts. Instead of seeing 15 separate low-severity findings (each individually ignorable), you see a single high-severity “attacker credential compromise” sequence that surfaces the full kill chain: initial access → privilege escalation → lateral movement → data access. This dramatically reduces the cognitive load on security teams reviewing findings.

Tuning GuardDuty findings: False positives are a common GuardDuty frustration. The most effective approach is suppression rules: for example, suppress “UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B” for known admin accounts that regularly log in from multiple locations, while leaving the same finding type active for service accounts that should never log in via console.

AWS Security Hub: Central Dashboard and Automated Remediation

Security Hub aggregates findings from GuardDuty, Inspector (vulnerability scanning), Macie (S3 data classification), and 50+ third-party security tools into a single dashboard with normalized severity scores.

The higher-value capability, which most organizations underuse, is automated remediation. Security Hub can trigger EventBridge rules when specific findings appear, which invoke Lambda functions to automatically remediate low-risk, high-volume findings:

# Example: Auto-remediate S3 bucket public access finding
# Requires Python 3.10+ (Python 3.9 reached EOL October 2025)
import boto3

def handler(event, context):
    finding = event['detail']['findings'][0]
    bucket_name = finding['Resources'][0]['Details']['AwsS3Bucket']['BucketName']

    s3 = boto3.client('s3')
    s3.put_public_access_block(
        Bucket=bucket_name,
        PublicAccessBlockConfiguration={
            'BlockPublicAcls': True,
            'IgnorePublicAcls': True,
            'BlockPublicPolicy': True,
            'RestrictPublicBuckets': True
        }
    )

    return {'statusCode': 200, 'body': f'Remediated public access on {bucket_name}'}

This pattern handles an entire class of Security Hub findings automatically, without human intervention, within seconds of detection — while generating an audit log of every remediation action.

CloudTrail: The Immutable Audit Record

Enable an organization-wide CloudTrail trail in your management account. Store logs in a dedicated security account’s S3 bucket that your application accounts cannot modify or delete. Enable log file validation (SHA-256 digest files) to detect any tampering.

For advanced threat hunting, send CloudTrail logs to CloudWatch Logs and create metric filters that alert on specific API patterns: CreateUser, AttachUserPolicy, PutBucketPolicy, DisableGuardDuty. These API calls are almost never part of normal operations and warrant immediate review.

Layer 3: Network Security

• Security Groups as allowlists — Default deny. Only open the ports you need, to the sources you trust. Use security group IDs as source references, not CIDR ranges, wherever possible.
• AWS WAF — Protect web-facing applications from SQL injection, XSS, and bot traffic. Use managed rule groups (AWS Managed Rules Common Rule Set, Amazon IP Reputation List) as a baseline, then add custom rate-based rules for your specific endpoints.
• VPC design — Private subnets for workloads, public subnets only for load balancers. Use VPC endpoints (Interface Endpoints and Gateway Endpoints) to keep AWS API traffic off the public internet entirely.
• Network Firewall — For environments that need deep packet inspection, domain-based filtering (block calls to known C2 domains), or stateful protocol analysis, AWS Network Firewall adds a managed IDS/IPS layer at the VPC perimeter.

For organizations with 10+ AWS accounts, AWS Firewall Manager centralizes WAF rules and security group policies across all accounts. One change in Firewall Manager propagates to every account automatically — eliminating the drift that occurs when individual account teams manage their own WAF rules independently.

Layer 4: Data Protection

• Encryption at rest — Use AWS KMS with customer-managed keys (CMKs) for your most sensitive data. Enable default encryption on S3 (SSE-S3 or SSE-KMS), EBS, and RDS. For regulated data (PHI, PCI), CMKs provide key rotation, key policy controls, and CloudTrail-logged key usage.
• Encryption in transit — Enforce TLS everywhere. Use ACM for certificate management. Deploy TLS termination at the load balancer and re-encrypt to your backend services with private certificates.
• Amazon Macie — Automatically discovers and classifies sensitive data in S3: PII, financial account numbers, credentials, PHI. Macie findings surface in Security Hub, creating a unified view of data security risks.

Layer 4 Addition: AWS Backup with Vault Lock for Ransomware Resilience

Ransomware attacks against cloud environments increasingly target backup systems first. If your attacker can delete your backups before encrypting your data, you have no recovery path.

AWS Backup Vault Lock enables WORM (Write Once, Read Many) protection on backup vaults. Once configured, no user — including root — can delete backups before the minimum retention period expires. Combined with cross-account backup copies (primary backups in workload account, copies in a dedicated backup account), this provides ransomware-resilient recovery.

We test recovery procedures for all Vault Lock-protected backup sets quarterly. An untested backup is not a backup — it is a hypothesis.

Getting Your Security Baseline Right

The layered approach described here — identity, detection, network, data — mirrors the AWS Well-Architected Framework’s Security pillar and maps directly to the control requirements of SOC 2, ISO 27001, HIPAA, and PCI DSS.

You do not need to implement all four layers at once. Start with Layer 1 (IAM) and Layer 2 (GuardDuty + Security Hub) — they deliver the highest risk reduction per dollar of effort. Then layer in network hardening and data protection as your program matures.

Security by Service: Deep Dives on AWS Security Controls

The four-layer approach above applies across all AWS services. For teams implementing specific security controls, we have detailed guides for each:

Identity & Access (Layer 1):

• IAM Best Practices: Least-Privilege Access Control — Service Control Policies, IAM Access Analyzer, principal-based policies
• AWS Secrets Manager vs. Parameter Store: When to Use Which — Credential rotation and secrets management for applications and databases

Detection & Monitoring (Layer 2):

• AWS GuardDuty Threat Detection in Production — Threat detection findings, Malware Protection, Network Monitor setup
• How to Set Up AWS Security Hub for Compliance Monitoring — Centralizing findings across accounts, compliance frameworks, custom insights

Network & Perimeter (Layer 3):

• How to Configure AWS WAF for API Protection: Beyond the Basics — Rate-based rules, bot control, IP reputation lists
• AWS VPC Networking Best Practices for Production — Security groups, NACLs, VPC endpoints, PrivateLink

Data Protection (Layer 4):

• S3 Security Best Practices: Preventing Data Exposure — Block Public Access, encryption, bucket policies, Macie
• AWS Backup Strategies for Automated Data Protection — Vault Lock, ransomware resilience, cross-account backups

Compliance & Governance:

• How to Implement HIPAA-Compliant Architecture on AWS — HIPAA-eligible services, encryption, audit trails
• PCI DSS Compliance on AWS: Architecture Guide for Fintech — Network segmentation, encryption, access control for payment systems

Getting Your Security Baseline Right

If you are unsure where your environment stands, our AWS Security Consulting team can conduct an assessment that benchmarks your configuration against AWS Well-Architected Framework security best practices and industry standards like SOC 2 and ISO 27001.

Book a Free Security Assessment →