Your practical guide to locking down AWS, Azure, and GCP before someone else locks you out.
Let’s be honest: cloud security feels overwhelming. You’ve got three major providers, each with their own terminology, endless configuration options, and that nagging feeling that you’re probably missing something important.
The good news? Most cloud breaches aren’t sophisticated attacks. They’re the result of preventable misconfigurations—S3 buckets left public, over-permissive IAM roles, security groups wider than they need to be. Fix these fundamentals, and you’ve closed the door on 90% of the real-world threats you’ll face.
This guide walks through the security essentials across AWS, Azure, and GCP. I’ll focus on what actually matters, with concrete steps you can implement today.
The Shared Responsibility Model: Know What You Actually Own
Before we dive in, let’s be clear about what you’re responsible for.
Cloud providers operate on a shared responsibility model. They secure the infrastructure—the physical data centers, the networking hardware, the hypervisor layer. You secure everything you deploy on top of that: your data, your applications, your access controls, your encryption configuration.
This isn’t just theory. When an S3 bucket gets left public and customer data leaks, that’s on you, not AWS. When an Azure Storage account exposes sensitive files, Microsoft isn’t coming to save you. Understanding this boundary is step one.
Your responsibilities:
– Identity and access management (IAM)
– Network configuration and security groups
– Data encryption at rest and in transit
– Application security and patching
– Monitoring, logging, and incident response
The provider’s responsibilities end where your configuration begins. Let’s make that configuration bulletproof.
IAM Hardening: Your First Line of Defense
If there’s one area to focus your security energy, it’s Identity and Access Management (IAM). Compromised credentials are the #1 attack vector in cloud environments. Here’s how to harden your identity layer across all three providers.
Universal IAM Principles
Implement the principle of least privilege. Every role, every user, every service account should have only the permissions it needs—nothing more. Too many organizations default to broad permissions because “it’s easier.” Easier now means compromised later.
Review your permissions regularly. A quarterly audit isn’t excessive. Look for:
– Roles with administrative privileges that don’t need them
– Service accounts with unused permissions
– Users who’ve left the company but still have active credentials
– API keys that haven’t been rotated in 90+ days
Forbid root-level access for daily work. Your root account (AWS), global admin (Azure), or super admin (GCP) should only exist for catastrophic recovery scenarios. Daily operations should use IAM users with appropriate scopes. If your daily driver can accidentally delete the production database, you’ve done it wrong.
Enforce multi-factor authentication (MFA) everywhere. Not just for admins. Not just for “sensitive” accounts. Everywhere. No exceptions. Single-factor authentication for cloud access is negligence at this point.
AWS IAM Specifics
Use IAM roles for EC2 instances, not access keys. Hard-coded access keys on instances are a vulnerability waiting to happen. Instead, attach IAM roles to EC2 instances. The instance automatically receives temporary credentials through the metadata service.
Rotate access keys regularly. Set a policy requiring key rotation every 90 days. AWS IAM supports automatic detection of unused keys—find them and delete them.
Implement IAM Access Analyzer. This free AWS tool automatically analyzes your policies and identifies resources shared with external entities. It catches unintended access patterns you might miss manually.
Azure IAM Specifics
Leverage Azure RBAC with custom roles. Azure’s built-in roles (Owner, Contributor, Reader) are too coarse for real security. Create custom roles that specify exact permissions needed for each job function.
Use Managed Identities for Azure resources. Like AWS IAM roles, managed identities eliminate the need for credentials in your code. Azure automatically handles the credential rotation. Use system-assigned managed identities for single-resource scenarios, user-assigned when multiple resources share the same identity.
Implement Privileged Identity Management (PIM). PIM provides just-in-time privileged access. Instead of permanent admin rights, users request elevated access for a specific duration. Everything gets logged. This dramatically reduces your attack surface.
GCP IAM Specifics
Use organizational policies to enforce guardrails. GCP’s organization policy constraints let you enforce restrictions across your entire organization. Block service account key creation. Restrict public IP access. Enforce specific resource locations.
Leverage service accounts correctly. GCP service accounts are more flexible than AWS IAM roles, but with complexity comes risk. Use the principle of least privilege rigorously. Never use default service accounts—create dedicated accounts per application.
Implement VPC Service Controls. This creates a security perimeter around your Google Cloud resources. Even if someone has the right permissions, they can’t access your data from outside your defined perimeter.
Storage Security: Lock Down Your Data
Storage misconfigurations are responsible for some of the largest data breaches in history. A single public S3 bucket can expose millions of records in seconds.
AWS S3 Security Essentials
Block public access at the bucket level. AWS provides account-level and bucket-level public access blocks. Enable all four settings:
– Block public access to buckets and objects granted through new ACLs
– Block public access to buckets and objects granted through any ACLs
– Block public access to buckets and objects granted through new public bucket policies
– Block public access to buckets and objects granted through any public bucket policies
Apply this at the account level so new buckets inherit the protection by default.
Enable default encryption. Every S3 bucket should have default encryption enabled using either SSE-S3 (Amazon-managed keys) or SSE-KMS (customer-managed keys for additional control and auditability). There’s no performance penalty for encryption at rest.
Enable versioning and MFA delete for critical buckets. Versioning protects against accidental deletions and overwrites. MFA delete adds an extra layer requiring authentication for delete operations.
Use bucket policies, not ACLs. ACLs are the old way of managing access and are more prone to misconfiguration. Bucket policies give you centralized, auditable control.
Azure Storage Security
Use Azure Private Link for storage accounts. Private Link creates a private endpoint in your virtual network, ensuring traffic between your resources and storage never traverses the public internet.
Configure firewall rules. Restrict storage account access to specific virtual networks, IP addresses, or both. Deny access from all networks by default, then explicitly allow what you need.
Enable soft delete and versioning. Soft delete retains deleted data for a specified retention period, giving you a recovery window. Blob versioning maintains previous versions automatically.
Implement lifecycle management policies. Automatically move older data to cooler storage tiers or delete it entirely. This reduces exposure and costs.
GCP Cloud Storage Security
Use uniform bucket-level access. Disable Access Control Lists (ACLs) entirely and manage all access through IAM. This eliminates the confusion of managing both bucket-level and object-level permissions.
Enable uniform bucket-level IAM and disable public access. GCP makes it explicit: choose between fine-grained ACLs (more complex) or uniform bucket-level access (cleaner, more secure). Go with uniform.
Enable Object Versioning. Like AWS, this protects against accidental deletions. Enable it on buckets with critical data.
Use Customer-Managed Encryption Keys (CMEK) for sensitive workloads. This gives you control over key rotation and lifecycle, with Cloud KMS managing the actual key material.
Network Segmentation: Build Internal Barriers
Even if your perimeter is solid, attackers who gain a foothold shouldn’t be able to move freely through your environment. Network segmentation is your internal defense.
Security Groups and Network ACLs
Think of security groups as stateful firewalls—they allow traffic in both directions once a connection is established. Network ACLs are stateless, evaluating each packet independently.
Practical rules:
– Deny all inbound by default, allow only what’s explicitly needed
– For web servers: allow 80/443 from anywhere, SSH only from specific IPs (or better, only through a bastion host)
– For database servers: no inbound from the internet, only from application servers
– Log all denied traffic for visibility into potential attacks
AWS VPC Best Practices
Deploy resources across multiple Availability Zones (AZs). This provides both resilience and natural segmentation. If an AZ is compromised, others remain isolated.
Use VPC endpoints for AWS services. Instead of routing traffic through the public internet to reach S3 or DynamoDB, use VPC endpoints. Traffic stays within your VPC.
Implement a hub-and-spoke network architecture. Centralize shared services (firewalls, inspection appliances) in a hub VPC. Connect workload VPCs as spokes. This simplifies management and ensures consistent security controls.
Azure Virtual Network Segmentation
Use network security groups (NSGs) on subnets, not just VMs. This provides defense in depth—a compromised VM can’t circumvent subnet-level controls.
Implement Azure Private Link and Private Endpoints. Private Endpoints bring Azure services into your virtual network, eliminating public internet exposure.
Leverage Azure Firewall for central control. Deploy Azure Firewall in a hub virtual network. All spoke network traffic routes through it for inspection and filtering.
GCP VPC Network Segmentation
Use VPC Service Controls for data theft protection. VPC Service Controls create perimeters around your Google Cloud resources. Even authorized users can’t exfiltrate data outside the perimeter.
Leverage Shared VPC for organization-wide control. Shared VPC lets you centralize network administration while delegating resource creation to project owners.
Implement firewall hierarchies. GCP firewalls work in hierarchical order—organization policies, then folder policies, then network policies. Use organization policies to enforce baseline restrictions that can’t be overridden.
Common Misconfigurations That Will Get You Breached
Let’s talk about the specific mistakes that show up in breach reports again and again.
1. Public Storage Buckets
This one’s so common it’s almost cliché. Public S3 buckets, public Azure Storage containers, public GCP buckets—they’re discovered by automated scanners within hours of creation.
The fix: Enable public access blocks by default. Implement automated scanning (AWS Config, Azure Policy, GCP Security Command Center) to alert on any public exposure.
2. Overly Permissive Security Groups
CIDR 0.0.0.0/0 allows all traffic from anywhere. It exists in your environment. I guarantee it.
The fix: Regular automated audits. Alert on:
– Any security group allowing SSH (22) or RDP (3389) from 0.0.0.0/0
– Security groups with all ports open
– Security groups allowing database ports (3306, 5432, 1433, etc.) from the internet
3. Hard-Coded Credentials in Code
Developers still commit access keys, API tokens, and passwords to GitHub. Automated scanning tools constantly monitor public repositories and notify attackers about every exposed credential.
The fix:
– Implement pre-commit hooks that scan for credentials
– Use environment variables or secrets managers (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)
– Enable secret scanning in your CI/CD pipeline
– Rotate credentials immediately if you suspect exposure
4. Unused and Orphaned Resources
Old instances with security group rules still attached. Forgotten databases with weak passwords. Service accounts no one remembers creating.
The fix: Implement resource tagging with owner, environment, and expiration date. Run monthly audits for untagged resources and resources past their expiration. If you don’t know who owns it and what it’s for, it’s a risk.
5. Disabled or Ignored Logs
Security logs that no one reviews are security theater. You’ll know something happened—but only after the fact, when you’re doing forensic analysis.
The fix: Route all security logs to a central SIEM. Set up alerts for critical events—failed login attempts, privilege escalations, configuration changes.
Monitoring: You Can’t Secure What You Can’t See
Security isn’t a configuration, it’s an ongoing practice. Monitoring tells you when things are going wrong.
Centralize Your Logs
All three providers offer centralized logging. Use them:
- AWS: CloudTrail for API activity, CloudWatch Logs for application and resource logs, VPC Flow Logs for network traffic
- Azure: Azure Monitor, Azure Activity Log, and Azure Sentinel for SIEM capabilities
- GCP: Cloud Audit Logs for API activity, Cloud Logging for application logs, VPC Flow Logs for network visibility
Route these logs to a central destination—ideally a dedicated log account/project that’s separate from your production environment.
Set Up Real-Time Alerts
Configure alerts for high-priority events:
– IAM policy changes
– Failed authentication attempts (multiple failures from the same source)
– Creation of new users or access keys
– Security group changes
– Public bucket or storage account access
– Root account usage (should never happen in normal operations)
Continuous Compliance Monitoring
Use native tools to continuously check your environment against security benchmarks:
- AWS: AWS Security Hub, AWS Config with managed rules
- Azure: Azure Security Center (now Microsoft Defender for Cloud), Azure Policy
- GCP: Security Command Center
These tools continuously compare your configuration against industry standards like CIS Benchmarks and alert on drift.
Enable Intrusion Detection
For larger environments, consider deploying intrusion detection within your network. AWS provides GuardDuty, Azure offers Microsoft Defender for Cloud, GCP has Security Command Center Premium. These services use threat intelligence and machine learning to detect anomalous activity you might miss.
Your Cloud Security Checklist
Let’s make this practical. Here’s what to implement first:
Priority 1: Immediate Wins (Do Today)
– [ ] Enable MFA on all root/admin accounts
– [ ] Block public access on all storage buckets
– [ ] Audit IAM for over-permissive roles
– [ ] Check for security groups allowing SSH/RDP from anywhere
Priority 2: Essential Hardening (Do This Week)
– [ ] Implement least-privilege IAM roles for all workloads
– [ ] Enable default encryption on all storage
– [ ] Set up centralized logging (CloudTrail, Azure Monitor, Cloud Audit Logs)
– [ ] Configure security alerts for critical events
– [ ] Remove unused credentials and service accounts
Priority 3: Defense in Depth (Do This Month)
– [ ] Deploy VPC endpoints/private links to eliminate public internet traffic
– [ ] Implement network segmentation across environments
– [ ] Enable continuous compliance monitoring
– [ ] Create automated scanning for public resource exposure
– [ ] Document incident response procedures
Priority 4: Ongoing Practices
– [ ] Quarterly IAM reviews and permission audits
– [ ] Monthly credential rotation
– [ ] Annual penetration testing
– [ ] Regular security awareness training for your team
The Bottom Line
Cloud security doesn’t have to be overwhelming. Most breaches result from the same handful of misconfigurations: public data exposure, excessive permissions, and poor network segmentation. Fix these fundamentals, maintain continuous monitoring, and practice good hygiene.
The cloud gives you powerful security tools. Use them.
Have questions about securing your specific environment? The best approach depends on your architecture, your applications, and your risk tolerance. But these fundamentals apply everywhere.
