IaaS, PaaS, SaaS and Core Cloud Services

Every compliance control you will ever write for a cloud-native company maps to a specific layer of infrastructure. If you don't know which layer you're talking about, you can't write the control, can't verify the evidence, and can't explain the risk to an auditor.

This lesson covers the three cloud service models and the specific cloud services a GRC Engineer encounters daily. By the end, you will be able to look at any compliance requirement and immediately know which cloud service it maps to and who is responsible for it.

Three service models

Cloud computing delivers infrastructure in three tiers. The difference between them is where the management boundary sits — what the cloud provider runs for you versus what you run yourself.

Infrastructure as a Service (IaaS) gives you virtual machines, storage volumes, and network plumbing. You get the equivalent of a rack in a data center, minus the physical hardware. You install the operating system, configure the firewall rules, patch the software, deploy your application. AWS EC2, Google Compute Engine, and Azure Virtual Machines are the canonical examples.

If a SOC 2 auditor asks about OS patching on your EC2 fleet, that's your problem. You chose IaaS. You own the OS.

Platform as a Service (PaaS) takes over everything below your application code. The provider handles the operating system, the runtime, the middleware, the scaling. You deploy code and configure the service. AWS Elastic Beanstalk, Google App Engine, Heroku, and Azure App Service fit here. So do managed databases like RDS and Cloud SQL — you write queries and set access policies, but AWS handles the Postgres patching.

If an auditor asks about database engine patching on your RDS instance, you point them to the AWS SOC 2 report. That's the provider's problem.

Software as a Service (SaaS) is the fully managed application. Salesforce, Okta, Slack, GitHub. You configure users, permissions, and settings. Everything else — the application code, the infrastructure, the scaling, the patching — is the vendor's responsibility.

If an auditor asks about the physical security of the data center hosting your Okta tenant, you hand them Okta's SOC 2 Type II report. That's vendor risk management, not infrastructure management.

Layer               IaaS         PaaS         SaaS
─────────────────   ──────────   ──────────   ──────────
Application         You          You          Provider
Data                You          You          Shared
Runtime             You          Provider     Provider
Middleware          You          Provider     Provider
Operating System    You          Provider     Provider
Virtualization      Provider     Provider     Provider
Servers             Provider     Provider     Provider
Storage             Provider     Provider     Provider
Networking          Provider     Provider     Provider
Physical            Provider     Provider     Provider

───────────────────────────────────────────────────────
"You"     = your team configures, patches, monitors
"Provider"= cloud vendor handles it, covered by their SOC 2
"Shared"  = you control access policies; provider stores it

The pattern is simple: as you move from IaaS to PaaS to SaaS, the provider absorbs more layers, and your management boundary shrinks. But your compliance obligations don't disappear — they shift from "configure and patch this infrastructure" to "configure this service correctly and manage who has access."

That shift matters enormously for GRC. Misconfigured SaaS is still a finding.

Core cloud services a GRC Engineer must know

You don't need to architect a multi-region deployment. You do need to know what these services are, what they log, and what goes wrong when they're misconfigured. Every compliance framework you'll work with maps to these categories.

Compute

Compute services run your application code. They come in two flavors.

Virtual machines — EC2 (AWS), Compute Engine (GCP), Azure Virtual Machines. A full operating system you manage. GRC relevance: you own OS patching, hardening, access controls, antivirus. SOC 2 CC6.1 (logical access) applies directly. An unpatched EC2 instance running a public-facing app is a control failure.

Serverless functions — Lambda (AWS), Cloud Functions (GCP), Azure Functions. You upload code; the provider runs it on demand. No OS to patch, no server to harden. GRC relevance: the attack surface shifts to IAM (what can this function access?) and secrets management (how does it authenticate to other services?). Auditors ask about execution role permissions, not OS hardening.

Storage

Object storage — S3 (AWS), Cloud Storage (GCS), Azure Blob Storage. Flat storage for files, backups, logs, static assets. The single most audited cloud service for good reason. Public S3 buckets have caused more breaches than most attack techniques combined.

GRC relevance: encryption at rest (is it enabled?), encryption in transit (is HTTPS enforced?), access policies (who can read and write?), versioning (can someone delete audit logs?), lifecycle policies (are backups retained per your retention policy?). Every compliance framework has controls that map directly to object storage configuration.

Database

Managed databases — RDS (AWS), Cloud SQL (GCP), Azure SQL Database. The provider handles engine patching, backups, and failover. You handle access controls, query permissions, and encryption configuration.

GRC relevance: who has database access, is encryption at rest enabled, are backups meeting your stated retention period, are connections encrypted in transit. An RDS instance with a public endpoint and no SSL enforcement is a textbook audit finding.

Identity and Access Management

IAM — AWS IAM, Google Cloud IAM, Azure Entra ID (formerly Azure AD). This is the control plane for who can do what across your entire cloud environment.

GRC relevance: this is the single most important service for compliance. Every framework — SOC 2, ISO 27001, NIST, HIPAA — has multiple controls covering access management. Overprivileged IAM roles, unused service accounts, missing MFA on privileged users — these are the findings auditors look for first. Phase 2 of this bootcamp spends the most time here for exactly this reason.

Networking

Virtual Private Clouds and Security Groups — VPC (AWS and GCP), VNet (Azure), Security Groups, Network ACLs, firewall rules. These define network boundaries: what can talk to what, which ports are open, which traffic is allowed in and out.

GRC relevance: network segmentation is a core control in every framework. An overly permissive security group (0.0.0.0/0 on port 22) is one of the most common cloud audit findings. You need to understand the difference between a security group and a network ACL, and you need to be able to read a Terraform module that configures them.

Logging and Monitoring

Audit logging — CloudTrail (AWS), Cloud Audit Logs (GCP), Azure Activity Log. These record every API call made in your cloud environment. Who created that IAM role? Who modified that S3 bucket policy? Who spun up that EC2 instance at 2 AM?

GRC relevance: logging is the evidence backbone. Without CloudTrail enabled and properly retained, you cannot prove that your controls are operating. Auditors will ask: is logging enabled on all accounts? Are logs stored in an immutable location? Is there a retention policy? Is anyone actually reviewing alerts? A CloudTrail trail that dumps to an S3 bucket with no retention policy and no alerting is technically "enabled" but practically useless.

Cloud service equivalents across providers

Most companies standardize on one cloud provider, but GRC Engineers often encounter multi-cloud environments — especially after acquisitions. Knowing the equivalent service names saves time in audits and vendor assessments.

Category          AWS                  GCP                    Azure
────────────────  ───────────────────  ─────────────────────  ──────────────────────
Compute (VMs)     EC2                  Compute Engine         Virtual Machines
Serverless        Lambda               Cloud Functions        Azure Functions
Object Storage    S3                   Cloud Storage          Blob Storage
Managed DB        RDS                  Cloud SQL              Azure SQL Database
NoSQL DB          DynamoDB             Firestore / Bigtable   Cosmos DB
Identity          IAM                  Cloud IAM              Entra ID (Azure AD)
Networking        VPC                  VPC                    VNet
Firewall rules    Security Groups      Firewall Rules         NSGs
Audit logging     CloudTrail           Cloud Audit Logs       Activity Log
Secrets           Secrets Manager      Secret Manager         Key Vault
Key management    KMS                  Cloud KMS              Key Vault
Container orch.   EKS                  GKE                    AKS

When you read a SOC 2 control narrative that says "all API calls are logged via CloudTrail," and the company also has a GCP project from an acquisition, your first question should be: "Is Cloud Audit Logs enabled and retained in the GCP project too?" Same control, different service name, same risk.

Why GRC Engineers must know this

Here is a real scenario that plays out at every cloud-native company during audit season.

An auditor asks: "How do you ensure that sensitive data at rest is encrypted?" The GRC Analyst says: "Per our Data Protection Policy, all data at rest is encrypted using AES-256." The auditor says: "Show me the evidence."

The GRC Analyst opens AWS, clicks around the console, takes a screenshot of one S3 bucket showing "Default encryption: AES-256." The auditor looks at it and says: "You have 47 S3 buckets and 12 RDS instances. Show me all of them."

The GRC Engineer runs a Steampipe query that checks encryption configuration across every S3 bucket and RDS instance in every AWS account, generates a report in 30 seconds, and hands the auditor a comprehensive compliance snapshot. The audit moves on.

You cannot write that query — or that control narrative, or that Terraform module — if you don't know what S3 is, what RDS is, or how encryption at rest works for each service.

The knowledge in this lesson is the foundation for everything that follows. Phase 2 goes deep on identity. Phase 3 covers cloud IAM in detail. Phase 5 handles data protection. But all of them assume you know what these services are and which provider calls them what.