Moving to the cloud does not eliminate security responsibilities. It redistributes them. The shared responsibility model, which every major cloud provider follows, makes the division clear: the cloud provider secures the underlying infrastructure, and the customer secures everything they build on top of it. Most cloud security incidents are not caused by provider failures. They are caused by customer misconfigurations.
This guide covers the essential security practices that apply across AWS, Azure, and Google Cloud Platform (GCP), with specific implementation guidance for each.
Identity and Access Management
Identity is the perimeter in cloud environments. Misconfigured identity and access management (IAM) is the most common root cause of cloud security incidents.
Principle of Least Privilege
Grant only the minimum permissions necessary for each user, service, and application. Avoid using wildcard permissions and overly broad roles. In AWS, use IAM policies with specific resource ARNs and action lists rather than broad "*" permissions. In Azure, assign granular Role-Based Access Control (RBAC) roles at the most specific scope possible. In GCP, use predefined roles rather than primitive roles (Owner, Editor, Viewer), which grant excessively broad access.
Protect Root and Admin Accounts
The root or super-admin account in each cloud platform has unrestricted access and should never be used for daily operations. In AWS, secure the root account with MFA, do not create access keys for it, and use AWS Organizations with Service Control Policies (SCPs) to enforce guardrails across all accounts. In Azure, protect Global Administrator accounts with Privileged Identity Management (PIM), requiring just-in-time activation and approval workflows. In GCP, secure the organization admin account and use Organization Policy constraints to restrict dangerous actions across all projects.
Service Account Security
Service accounts and machine identities are frequently over-permissioned and poorly managed. Avoid creating service account keys when possible. In AWS, use IAM roles for EC2 instances and ECS tasks instead of access keys. In Azure, use managed identities for Azure resources. In GCP, use attached service accounts with Workload Identity Federation for external workloads.
Network Security
Cloud networking provides powerful isolation capabilities, but they must be configured correctly.
Network Segmentation
Organize workloads into separate virtual networks based on function, sensitivity, and trust level. Use security groups and network ACLs to control traffic between segments. In AWS, use VPCs with private subnets for backend resources and public subnets only for load balancers and bastion hosts. In Azure, use Virtual Networks with Network Security Groups and Azure Firewall for centralized traffic inspection. In GCP, use VPC networks with firewall rules and consider Shared VPCs for multi-project environments.
Minimize Public Exposure
Audit your environment regularly for unintended public exposure. Storage buckets, databases, management consoles, and debug interfaces should never be directly accessible from the internet unless explicitly required. Use cloud-native tools to identify publicly accessible resources: AWS Config rules, Azure Security Center, and GCP Security Command Center all provide this capability.
Encrypt Traffic
Enforce encryption for all data in transit. Use TLS 1.2 or higher for all connections. Implement VPN or private connectivity options like AWS PrivateLink, Azure Private Endpoints, or GCP Private Service Connect for traffic between cloud services and on-premises environments.
Data Protection
Protecting data in the cloud requires a combination of encryption, access controls, and classification.
Encryption at Rest
Encrypt all data at rest using cloud-managed keys at minimum. For sensitive data, use customer-managed keys (CMKs) that give your organization control over the key lifecycle. In AWS, use KMS with CMKs and configure default encryption for S3 buckets, EBS volumes, and RDS instances. In Azure, use Azure Key Vault with customer-managed keys for Azure Storage, managed disks, and SQL databases. In GCP, use Cloud KMS with customer-managed encryption keys (CMEK) for Cloud Storage, Persistent Disks, and BigQuery.
Data Classification and DLP
Classify data by sensitivity level and apply appropriate controls. Use data loss prevention (DLP) tools to discover, classify, and protect sensitive data across your cloud environment. AWS Macie scans S3 for sensitive data. Azure Purview provides data governance and classification. GCP Cloud DLP identifies and protects sensitive data across Google Cloud services.
Backup and Recovery
Cloud data can be lost to accidental deletion, misconfiguration, or attack just as on-premises data can. Implement automated backups with tested restoration procedures. Enable versioning on storage buckets to protect against accidental overwrites and deletions. Use cross-region replication for critical data to protect against regional outages.
Logging and Monitoring
Comprehensive logging is essential for detecting threats, investigating incidents, and meeting compliance requirements.
Enable Audit Logging
Enable and centralize audit logs across all cloud services and accounts. In AWS, enable CloudTrail in all regions and all accounts, with logs delivered to a centralized, immutable S3 bucket. In Azure, enable Azure Activity Logs and Diagnostic Logs, forwarding them to a central Log Analytics workspace. In GCP, ensure Cloud Audit Logs are enabled for all services and export them to a centralized logging project.
Security Monitoring
Deploy cloud-native security monitoring services alongside any third-party tools. AWS GuardDuty provides intelligent threat detection across AWS accounts and workloads. Azure Defender (now Microsoft Defender for Cloud) provides threat protection across Azure resources. GCP Security Command Center provides security and risk management across Google Cloud.
Alerting and Response
Configure alerts for high-priority security events including root account usage, changes to IAM policies, modifications to security group rules, access to sensitive data stores, and creation of new user accounts or API keys. Integrate alerts with your incident response workflows to ensure timely investigation and action.
Infrastructure as Code Security
Modern cloud environments are defined in code through tools like Terraform, CloudFormation, ARM templates, and Pulumi. Securing this code is essential because misconfigurations in infrastructure as code templates propagate every time the code is deployed.
- Static analysis: Scan infrastructure code templates with tools like Checkov, tfsec, or cfn-lint before deployment to catch misconfigurations early
- Policy as code: Implement automated policy checks using Open Policy Agent (OPA), AWS Config Rules, Azure Policy, or GCP Organization Policies to prevent non-compliant resources from being created
- Version control: Store all infrastructure code in version control with mandatory code review for changes. Treat infrastructure changes with the same rigor as application code changes
- Secrets management: Never store credentials, API keys, or other secrets in infrastructure code. Use cloud-native secrets management services like AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager
Shared Responsibility in Practice
The shared responsibility model is frequently misunderstood. The cloud provider ensures the physical security of data centers, the availability of compute and storage services, and the security of the hypervisor and underlying infrastructure. Everything else, including IAM configuration, network security groups, data encryption, operating system patches on virtual machines, and application security, is the customer's responsibility.
Organizations that understand and operationalize this division, rather than assuming the cloud provider handles security, are the ones that avoid the misconfigurations behind the majority of cloud security incidents.
