Cloud Security Best Practices for AWS, GCP, and Azure in 2026

Cloud misconfigurations are the #1 cause of data breaches in 2026. Not sophisticated zero-day exploits — just S3 buckets left public, overly permissive IAM roles, and security groups that allow the world in.

According to Gartner, through 2027, 99% of cloud security failures will be the customer's fault. Not the cloud provider's. Yours.

Here's how to not be that company.

The Shared Responsibility Model

Before diving into specific controls, understand the fundamental contract: your cloud provider secures the infrastructure of the cloud. You secure everything in the cloud.

The cloud provider handles:

• Physical data center security
• Hypervisor and host OS security
• Network infrastructure
• Global infrastructure availability

You handle:

• IAM policies and user access
• Network configuration (security groups, NACLs)
• Data encryption (at rest and in transit)
• Application security
• Operating system patching (EC2, GCE, VMs)
• Logging and monitoring

Identity and Access Management (IAM)

IAM misconfigurations are in the top findings we detect across customer scans. Here's how to get it right:

Principle of Least Privilege

Every user, service, and application should have exactly the permissions they need — and nothing more.

// BAD: Overly permissive policy
{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
}

// GOOD: Scoped to specific actions and resources
{
    "Effect": "Allow",
    "Action": [
        "s3:GetObject",
        "s3:PutObject"
    ],
    "Resource": "arn:aws:s3:::my-app-uploads/*"
}

MFA Everywhere

Enable MFA on every human account, especially:

• AWS root account (use a hardware key, not SMS)
• AWS IAM users with console access
• GCP admin accounts
• Azure Active Directory admins
• CI/CD service accounts (where supported)

Cross-Cloud IAM Best Practices

Network Security

Segment Your Network

Don't run everything in one flat network. Use VPCs/VNets with proper subnet segmentation:

Production VPC
├── Public Subnet (load balancers only)
├── Private Subnet - App Tier (application servers)
├── Private Subnet - Data Tier (databases)
└── Management Subnet (bastion hosts, monitoring)

Lock Down Security Groups / Firewall Rules

# NEVER do this:
# Allow all traffic from 0.0.0.0/0
# "We'll fix it later" is a breach waiting to happen

# Instead, be specific:
# Allow HTTPS from anywhere
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxx \
  --protocol tcp --port 443 \
  --cidr 0.0.0.0/0

# Allow SSH from VPN only
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxx \
  --protocol tcp --port 22 \
  --cidr 10.0.0.0/8

Private Endpoints

Keep traffic between your services inside the cloud provider's network. Don't route through the public internet.

• AWS: VPC Endpoints (Gateway for S3/DynamoDB, Interface for everything else)
• GCP: Private Service Connect
• Azure: Private Link

Encryption

At Rest

Always use customer-managed keys (CMKs) for sensitive data. Default encryption is fine for most data, but compliance frameworks like HIPAA and PCI DSS often require you to manage your own encryption keys.

In Transit

• Enforce TLS 1.2+ on all connections
• Use internal TLS between microservices (mutual TLS / mTLS is even better)
• Enable SSL enforcement on managed databases

# AWS RDS: Enforce SSL connections
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --ca-certificate-identifier rds-ca-rsa4096-g1

# PostgreSQL: Require SSL
# In pg_hba.conf:
# hostssl all all 0.0.0.0/0 scram-sha-256

Logging and Monitoring

You can't protect what you can't see. Enable comprehensive logging across all environments.

What to Log

Critical Alerts You Need

Set up alerts for these events — they indicate potential compromise:

1. Root/owner account login — Should almost never happen
2. IAM policy changes — New admin permissions granted
3. Security group changes — Ports opened to 0.0.0.0/0
4. S3 bucket policy changes — Bucket made public
5. CloudTrail/audit log disabled — Someone covering tracks
6. Unusual API calls — First-time actions from known accounts
7. Failed authentication spikes — Brute force attempts
8. Large data transfers — Potential exfiltration

Centralize Your Logs

Ship all logs to a centralized, immutable location:

• AWS: CloudTrail → S3 (with Object Lock) + CloudWatch
• GCP: Cloud Audit Logs → BigQuery or Cloud Storage (with retention lock)
• Azure: Diagnostic Settings → Log Analytics + Immutable Storage

Retain logs for at least 1 year (SOC 2 and ISO 27001 require this). HIPAA requires 6 years for audit logs related to ePHI.

Container and Kubernetes Security

If you're running containers (and in 2026, you probably are):

Image Security

• Scan images for vulnerabilities before deployment
• Use minimal base images (distroless, Alpine)
• Never run containers as root
• Pin image versions — never use :latest in production

Kubernetes Hardening

# Pod security: Non-root, read-only filesystem, no privilege escalation
apiVersion: v1
kind: Pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Secrets Management

Never store secrets in:

• Environment variables in Dockerfiles
• Git repositories (even private ones)
• ConfigMaps

Instead, use:

• AWS Secrets Manager or SSM Parameter Store
• GCP Secret Manager
• Azure Key Vault
• HashiCorp Vault

Compliance Mapping

These cloud security controls map directly to compliance requirements:

With Proveably, we automatically scan your cloud environment and map every misconfiguration to the compliance frameworks you're targeting — whether that's SOC 2, ISO 27001, HIPAA, or all three.

Quick-Start Security Checklist

Use this checklist for a baseline cloud security posture:

• MFA enabled on all human accounts
• Root/owner account secured and not used day-to-day
• IAM policies follow least privilege
• No long-lived access keys (or rotated every 90 days)
• VPC/VNet with proper subnet segmentation
• Security groups deny all inbound by default
• No public SSH (port 22) access
• No public database access
• Encryption enabled on all storage and databases
• TLS 1.2+ enforced on all endpoints
• CloudTrail / Audit Logs enabled in all regions
• VPC Flow Logs enabled
• Alerting on critical security events
• Container images scanned before deployment
• Secrets stored in a secrets manager (not env vars or code)

Don't trust your cloud configuration to manual checks. Run a free Proveably scan and get an instant assessment of your AWS, GCP, or Azure security posture — mapped to the compliance frameworks your customers are asking for.