Cloud infrastructure security covers the compute, network, identity, storage, and control-plane layers that customers configure beneath their applications, with the boundary set by the shared responsibility model. Four controls dominate risk: workload identity, network exposure, image and patch state, and control-plane logging, and every major provider ships permissive defaults for each — AWS security groups allow all outbound traffic, Azure network security groups allow all internal traffic, and Google Cloud's default Compute Engine service account can hold the Editor role. Five infrastructure-specific threats are outlined: default-driven exposure, unreviewed machine identity permissions, metadata service abuse (IMDSv2 hop limits, Azure/GCP metadata headers), stale golden images, and shadow resources created outside infrastructure as code. Best practices include inventorying workload identity, closing egress, enforcing IMDSv2, treating images as the unit of patching, applying organization-wide guardrails, mandating infrastructure as code, and enabling audit logging. A comparison table maps these controls across AWS, Azure, and Google Cloud, and the piece closes with an FAQ and a pitch for Orca's Unified Data Model and agentless SideScanning platform.
Table of contents
What is cloud infrastructure security?Why cloud infrastructure security mattersKey components of cloud infrastructure securityCommon threats and vulnerabilities in cloud environmentsCloud infrastructure security best practicesCloud infrastructure security for multi-cloud and hybrid environmentsThe role of zero trust in securing cloud infrastructureCloud infrastructure security posture assessmentHow Orca Secures Cloud Infrastructure Across Every ProviderFrequently Asked Questions about Cloud Infrastructure SecurityQuestions this post answers
What are the default outbound rules for a new AWS security group?
A newly created AWS security group has no inbound rules and one outbound rule that allows all outbound traffic, per AWS documentation. This means outbound access is open by default even though inbound is locked down, making egress control something teams must configure themselves rather than something AWS restricts automatically. Teams hardening AWS network defaults can track cloud security guidance like this on daily.dev.
Does Google Cloud's default Compute Engine service account get admin-level permissions automatically?
Yes, in older configurations the default Compute Engine service account can receive the Editor role on the project, though newer organizations disable that automatic grant by default. This means a compromised workload using the default identity could inherit broad project-wide permissions unless the organization has explicitly turned off the automatic grant. Engineers auditing GCP identity defaults can follow cloud IAM developments on daily.dev.
How do AWS, Azure, and Google Cloud differ in protecting their instance metadata service from SSRF attacks?
AWS accepts either IMDSv1 or IMDSv2 by default unless the AMI sets ImdsSupport to v2.0, while Azure requires a Metadata: true header and Google Cloud requires a Metadata-Flavor: Google header on every request. IMDSv2 on AWS adds session tokens and a default response hop limit of 1, which specifically blocks a compromised container from reaching the endpoint through a proxy. Developers securing workloads against SSRF can compare provider metadata defaults on daily.dev.