Choosing a cloud provider is rarely a pure security decision, but security defaults shape how much work your team must do to reach a secure baseline. A platform with strong defaults reduces the chance that a developer's first deployment is accidentally public, unencrypted, or unlogged. A platform with weak defaults puts the burden entirely on the customer to harden every resource from day one.
We regularly assess environments across all three major providers, and we see the same patterns: each platform makes different assumptions about what should be secure by default and what should be the customer's responsibility. This article compares AWS, Azure, and GCP across five critical default-security dimensions. The goal is not to crown a winner but to help you understand where each platform requires the most attention.
Default Encryption at Rest and in Transit
GCP leads in encryption defaults. Nearly every GCP storage and database service encrypts data at rest by default using Google-managed keys, and has done so since the platform's early days. There is no option to create an unencrypted Cloud Storage bucket or BigQuery dataset. In-transit encryption between Google data centers is also automatic via ALTS (Application Layer Transport Security).
AWS has largely caught up. S3 now encrypts all new objects with SSE-S3 by default (as of January 2023), EBS volumes created after a certain date are encrypted by default when the account-level setting is enabled, and RDS instances support encryption at creation. However, the account-level EBS encryption default must be explicitly enabled per region, and some services still allow unencrypted configurations if the administrator does not enforce encryption policies.
Azure encrypts storage accounts, managed disks, and SQL databases at rest by default using platform-managed keys. Azure Storage enforces HTTPS-only traffic by default on new storage accounts. However, certain legacy services and configurations may still permit unencrypted data, and the Azure ecosystem is large enough that exceptions exist. Across all three providers, customer-managed keys (CMKs) for regulatory compliance are an opt-in step that requires additional configuration regardless of the platform.
Default Network Rules and Exposure
This is where the platforms diverge most sharply. AWS security groups are stateful and default-deny on inbound traffic: a new security group allows no inbound connections until you explicitly add rules. However, outbound traffic is allowed to all destinations by default, and the default VPC creates public subnets with internet gateways attached. Resources launched into the default VPC can receive public IPs automatically.
Azure Network Security Groups (NSGs) include default rules that allow inbound traffic from the virtual network and the Azure load balancer, and allow all outbound traffic. Azure does not attach NSGs to new subnets or NICs by default, meaning a resource can be deployed with no network filtering at all unless the administrator creates and attaches an NSG. This permissive-by-default model has caught many teams off guard.
GCP's default network includes firewall rules that allow ICMP, internal traffic, SSH (port 22), and RDP (port 3389) from any source. This is arguably the most permissive default of the three providers. However, GCP's VPC firewall rules apply at the network level and are easy to audit centrally. The recommended practice for all three platforms is to delete the default VPC/network entirely and build custom networks with explicit, restrictive rules from the start.
IAM Model and Default Permissions
AWS IAM is explicit-deny by default: new IAM users and roles have no permissions until policies are attached. This is the most secure default posture among the three. However, the AWS IAM model is also the most complex, with identity-based policies, resource-based policies, permission boundaries, SCPs, and session policies all interacting. This complexity frequently leads to misconfigurations where teams grant overly broad policies like AdministratorAccess to avoid debugging permission errors.
Azure uses Azure Active Directory (now Entra ID) for identity management, with RBAC for resource authorization. New users in Entra ID receive no Azure resource permissions by default, which is secure, but the Entra ID directory permissions model is separate and more permissive: by default, all users can read directory objects, register applications, and create security groups. GCP IAM is conceptually cleaner with its resource hierarchy (organization, folder, project) and inheritance model, but default service accounts in GCP projects historically received the Editor role, granting broad permissions to any workload that used the default service account. Google has since changed this for new projects, but legacy projects retain the permissive default.
The practical takeaway is that all three platforms require deliberate IAM design. None provides a secure-by-default IAM posture that works without configuration. The teams that get IAM right invest in least-privilege policies, use automated access reviews, and enforce MFA universally, regardless of which provider they use.
Built-in Threat Detection and Logging Defaults
AWS CloudTrail logs management events by default in every account (the free 90-day Event History), but a full CloudTrail trail that captures data events and stores logs durably must be configured manually. GuardDuty, AWS's threat detection service, is not enabled by default and costs extra. VPC Flow Logs are off by default.
Azure provides Activity Log data for 90 days by default, but longer retention requires configuring Diagnostic Settings. Microsoft Defender for Cloud (formerly Azure Security Center) has a free tier with basic recommendations but advanced threat detection (Defender plans) must be enabled per resource type at additional cost. NSG Flow Logs require manual configuration.
GCP enables Admin Activity audit logs by default at no charge and retains them for 400 days, the strongest logging default of the three. Data Access audit logs must be enabled manually for most services. Security Command Center (SCC) has a free standard tier with asset inventory and misconfiguration findings, and a premium tier for threat detection. VPC Flow Logs are off by default. The verdict across all three: no platform provides comprehensive threat detection out of the box. Every organization needs to explicitly enable and pay for advanced security monitoring regardless of the provider.