Cloud Security Best Practices: AWS, Azure, and GCP

Cloud platforms have become the default infrastructure for organisations of every size — hosting applications, storing data, running workloads, and providing the services that power modern business. With that migration comes a responsibility that’s fundamentally different from traditional on-premises security: the organisation shares responsibility for security with the platform provider, and the boundary between what the provider secures and what the customer must secure is not always obvious. For a broader walkthrough, our Complete Guide to Online Security and Privacy is a good next read.

Cloud security best practices apply across AWS, Google Cloud Platform (GCP), and Microsoft Azure with platform-specific implementations but consistent underlying principles. Most publicised cloud security incidents are not provider-side failures — they’re customer-side misconfigurations that expose sensitive resources to the internet or provide attackers with the credentials to access them.

The shared responsibility model — who secures what

Cloud providers secure the underlying infrastructure: physical hardware, the network fabric, the hypervisor, and managed services they operate. The customer is responsible for everything built on top: data stored, identities managed, network configurations created, and applications deployed.

The four misconfiguration categories that account for the majority of publicised cloud incidents:

1. Object storage (S3 buckets, Azure Blob, Google Cloud Storage) configured with public read access — exposing sensitive documents, database backups, or application source code to the entire internet
2. Root or administrator accounts without MFA — allowing credential-based takeover that grants full control of all cloud resources
3. Over-privileged IAM roles and service accounts — grant-everything approaches mean a compromise of any component grants broad access
4. Security group firewall rules allowing 0.0.0.0/0 on sensitive ports like SSH (22), RDP (3389), or database ports

All four are addressed by straightforward configuration that requires no additional tools or cost. Cloud Security Posture Management (CSPM) tools — AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center — continuously scan environments against established benchmarks (CIS Benchmarks, NIST CSF) and alert on these misconfigurations. All three major platforms provide native CSPM at low or no additional cost; enabling them is a priority that provides continuous visibility rather than point-in-time audits.

Identity and access management — the most critical security layer

Identity is the primary attack surface in cloud environments. The cloud is accessed through APIs and management consoles that authenticate entirely through credentials and tokens, with no physical network perimeter to cross. Cloud security best practices for IAM are therefore the most important single category of controls.

Root and global administrator accounts: never use these for routine operations. Create individual IAM users or managed identities for every human and service that needs cloud access, each with the minimum permissions required for their specific function. Enable MFA on the root/global admin account and all IAM users with console access.

• AWS: root account → secure with hardware MFA, lock it away for break-glass use only; create an administrator IAM user for everyday administrative tasks with its own MFA
• Azure: global administrator role → assign to a dedicated break-glass account with MFA; use Azure AD Privileged Identity Management (PIM) for just-in-time elevation for administrator tasks
• GCP: organisation admin account → enable 2FA; use Cloud Identity for individual users

Service accounts and programmatic access keys:

• Create a unique service account per application or workload — never share credentials between services
• Grant only the specific permissions the service account needs
• Rotate access keys regularly, or use instance profiles and workload identity federation to avoid long-lived keys entirely
• Audit all service accounts quarterly for unused or over-privileged credentials — unused access keys created for testing and never rotated are among the most common credential compromise vectors in cloud environments

Network and storage — common misconfigurations and fixes

Resource type	Common misconfiguration	Cloud security best practices fix	Where to configure
Object storage (S3, Blob, GCS)	Public read/write access enabled	Block all public access; use signed URLs for controlled sharing	AWS: S3 Block Public Access; Azure: Container public access level = Private; GCP: Uniform bucket-level access
Security groups / NSGs	SSH/RDP open to 0.0.0.0/0	Restrict to specific trusted IP ranges; use VPN or bastion host for admin access	AWS: Security Group inbound rules; Azure: NSG inbound rules; GCP: VPC firewall rules
Databases	Public endpoint with no IP restriction	Private VPC placement; restrict access by security group or private endpoint	AWS: RDS VPC settings; Azure: Private endpoint; GCP: Private IP
Cloud functions / serverless	Unauthenticated invocation allowed	Require authentication; restrict to specific calling identities	AWS: Lambda resource policy; Azure: Function auth level; GCP: Cloud Run authentication
Kubernetes clusters	API server publicly accessible; RBAC not enforced	Private cluster endpoint; RBAC for all service accounts	AWS: EKS private endpoint; Azure: AKS private cluster; GCP: GKE private cluster

The object storage row represents the most common cloud security failure in practice. Publicly-accessible S3 buckets containing database backups, AWS credentials files, and internal application data have been responsible for some of the largest data exposures of the past decade — all from a single misconfigured setting that takes two seconds to correct. The default setting in modern AWS accounts enables S3 Block Public Access at the account level; verify this is enabled and has not been disabled for any bucket.

Data protection and encryption

Encryption at rest and in transit is table stakes for cloud security best practices, and all major cloud platforms provide it. The configuration decisions that matter:

• Encryption at rest: verify that all storage services have encryption enabled with either platform-managed keys (simpler) or customer-managed keys (more control, more complexity). AWS: S3 Default encryption; RDS storage encryption; EBS encryption. Azure: Storage service encryption; Azure SQL Transparent Data Encryption. GCP: Default encryption for all storage.
• Key management: AWS KMS, Azure Key Vault, and GCP Cloud KMS provide customer-managed key options. For highly regulated environments or compliance requirements, customer-managed keys provide an additional layer of control over who can access encrypted data. For most workloads, platform-managed encryption is sufficient.
• Data classification before cloud storage: classify data before deciding which cloud service and access tier is appropriate. Not all data belongs in cloud storage with default settings — PII, financial records, and confidential business data need additional access controls and audit logging beyond the platform defaults.
• Secrets management: application secrets (database connection strings, API keys, credentials) should never be stored in code repositories or environment variables. Use AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager to store and rotate secrets programmatically.

Logging, monitoring, and detection

Every major cloud platform generates extensive audit logs; the question is whether those logs are being reviewed. Cloud security best practices require:

• Enable cloud audit logging across all services. AWS CloudTrail (API calls), Azure Activity Log and Azure Monitor, GCP Cloud Audit Logs — these record every API call, configuration change, and authentication event. They are the forensic record that answers “what happened and when” during an incident.
• Enable threat detection services. AWS GuardDuty, Microsoft Defender for Cloud, GCP Security Command Center continuously analyse log data for known attack patterns — credential misuse, cryptocurrency mining, communication with known malicious IP addresses. These services require enabling; they are not active by default in most configurations.
• Set up alerting for high-priority events. Integration between detection services and alerting channels (Slack, PagerDuty, email) ensures high-confidence alerts reach a responder within minutes rather than sitting in a console checked weekly. Define what triggers a page vs what appears in a daily digest.

Quarterly hygiene — the resource audit

Cloud environments accumulate resources over time — old instances left running, IAM roles created for a project that ended, storage buckets created for a one-time migration, security groups with overly broad rules from an early prototype. Each represents both unnecessary cost and unnecessary attack surface.

A quarterly resource inventory audit covers:

• All IAM users, roles, and policies — review for current necessity; deactivate or delete unused
• All storage buckets and their access configurations — verify no inadvertent public access
• All open security group / NSG rules — remove any rules broader than needed for current function
• All service account keys — rotate any key older than 90 days; delete keys for deprecated services
• All publicly-accessible endpoints — any service with a public IP that doesn’t explicitly require it should be moved to private networking

The Well-Architected Review tools from AWS, Azure, and GCP include specific security checks as part of their framework assessments and can be run without external consultants for most environments. Our guide on the zero trust security model covers the identity and access architecture that cloud security best practices implement at the organisational level. For the AWS CIS Foundations Benchmark assessment, AWS Security Hub provides automated compliance checking against CIS benchmarks with scored findings and remediation guidance.

Multi-cloud and hybrid environments

Multi-cloud and hybrid environments add complexity that single-cloud deployments don’t have: consistent policy enforcement across different platforms with different native tooling, identity federation between cloud environments and on-premises systems, and unified logging and monitoring across environments with different native log formats.

For multi-cloud environments:

• Cloud-agnostic CSPM tool: Wiz, Orca Security, or Prisma Cloud provide consistent posture management across AWS, Azure, and GCP with a unified control plane — much more practical than managing native CSPM tools per platform
• Central identity provider: Okta, Azure AD, or Google Workspace federating to all cloud platforms rather than managing separate identities per platform
• Central SIEM: routing all cloud logs to a central security information and event management platform (Microsoft Sentinel, Splunk, or open-source alternatives) for unified detection and investigation across all environments

The fundamental cloud security best practices principle across all environments and all platforms is the same: least privilege access, no public exposure of resources that don’t require it, comprehensive audit logging, and continuous monitoring that converts logging from a forensic tool into a real-time detection capability. The specific implementation paths differ between AWS, Azure, and GCP — but the security decisions they implement are identical. Related: Secure File Sharing.

The cloud security best practices quick audit — what to check first

For an organisation with an existing cloud environment that hasn’t been deliberately security-reviewed, this sequence covers the most impactful checks in approximately two hours:

1. MFA on all accounts with console access (15 minutes). AWS IAM console → Users → each user’s Security credentials tab → confirm MFA device assigned. Azure: Entra ID → Users → each user → Authentication methods. GCP: IAM → each user’s account → confirm 2FA enabled via Google Account. Any user without MFA is a credential-based takeover waiting to happen.
2. S3/Blob/GCS bucket access review (20 minutes). AWS: S3 → select each bucket → Permissions tab → confirm “Block public access” is active. Azure: Storage accounts → select each → Networking → confirm “Enabled from selected virtual networks and IP addresses” rather than all networks. GCP: Cloud Storage → select each bucket → Permissions → confirm “allUsers” and “allAuthenticatedUsers” are not listed.
3. Security group / NSG inbound rule review (20 minutes). AWS: EC2 → Security Groups → filter by “Source: 0.0.0.0/0” → review each rule and remove any that allow broad access on sensitive ports. Same process in Azure NSGs and GCP VPC firewall rules.
4. Enable CSPM (10 minutes). AWS: Security Hub → Enable Security Hub → enable CIS AWS Foundations Benchmark standard. Azure: Defender for Cloud → Environment settings → enable. GCP: Security Command Center → Enable.
5. Enable CloudTrail / Activity Log / Cloud Audit Logs (10 minutes). Verify that management events are being logged and that logs are being retained for the appropriate period (90 days minimum; 1 year for many compliance requirements).
6. Enable GuardDuty / Defender for Cloud / Security Command Center threat detection (10 minutes). Each platform’s threat detection service; enable for all regions/subscriptions.
7. Review IAM roles and service account permissions (20 minutes). AWS: IAM → Roles → review trust policies and attached policies. Azure: Subscriptions → Access control (IAM) → Role assignments → review. GCP: IAM → review all service accounts and their roles. Flag any “Administrator” or “Owner” roles assigned to non-break-glass accounts.

This two-hour audit closes the most commonly exploited cloud misconfigurations and establishes the monitoring baseline that makes future anomalies detectable. Most findings from this audit can be remediated in the same session; the CSPM tools will surface any remaining issues and provide prioritised remediation guidance for the longer-term improvement cycle. If this sounds familiar, Email Security Best Practices is worth a look.