6.5: Mapping Cloud Building Blocks to Architecture Layers

Compute

• Data storage is another fundamental building block, present in multiple layers. At the physical layer, we have disks and storage arrays in data centers. In IaaS, these manifest as block storage volumes (like Amazon EBS or Azure Disks attached to VMs) and object storage services (like Amazon S3, Azure Blob Storage) which are actually a bit higher-level but commonly offered in IaaS portfolio. Object storage can also be seen as a separate service layer (it abstracts the file system and offers a simple API for storing/retrieving objects). In PaaS, storage might appear as managed data services – for example, a managed database, a caching service, or a file storage service. These are built on the provider’s underlying storage infrastructure but exposed at a higher abstraction (e.g., you get a database endpoint rather than a raw disk). In SaaS, storage is again hidden: the SaaS app stores data on your behalf (for instance, a CRM stores customer records internally, maybe on a DBaaS or its own storage implementation). The user just sees the end result (documents in Dropbox, emails in Gmail, etc.). Mapping: storage building blocks exist as IaaS services (volumes, object stores), PaaS services (databases, data lakes, queue storage), and underpin SaaS offerings. When architecting, one should choose the appropriate storage abstraction – e.g., use a raw block volume if you need a traditional filesystem with a VM, use object storage for unstructured data and easy scalability, or use a fully managed DB if you want the platform to handle data management.

Networking

• Compute resources (the CPUs and memory that run applications) are the core of the infrastructure layer. In IaaS, compute is delivered as virtual machines or bare metal servers that the customer can launch. For example, Amazon EC2 instances or Azure VMs represent compute at the IaaS layer. In PaaS, compute is abstracted to application runtimes or containers; you might not see a “server” at all, but behind the scenes your code is executed on compute instances managed by the provider. FaaS is an extreme case of abstracted compute – you just see function execution, not even a long-lived instance. At the SaaS layer, compute is completely hidden – the SaaS provider runs their application on infrastructure, but the end user isn’t aware of the compute resources at all (aside from perhaps noticing performance). Mapping: Compute spans from physical servers (physical layer) -> VMs/containers (infrastructure/virtual layer) -> managed runtime instances (platform layer) -> invisible execution of app logic (service/application layer). When designing a cloud system, one decides whether to use low-level compute (e.g., spin up VMs and manage them) or higher-level compute (deploy containers to a service, or use serverless functions) depending on requirements.

  Storage



• Networking connects all layers and is crucial in cloud architecture. In IaaS, networking is exposed through Virtual Private Clouds (VPCs) or virtual networks that customers configure with subnets, routing tables, and often software firewalls or security groups. This corresponds to the network layer of the stack. The cloud provider manages the physical networking (cables, switches – physical layer) and the data link layer, but gives the user the ability to design logical networks (network layer) and control access at transport layer (e.g., security groups allow TCP/UDP port filtering). In PaaS, networking is often simplified: you might not manage subnets, but you still deal with endpoints, DNS, and perhaps virtual network integration if needed. Many PaaS offerings let your app communicate over a default network, and if you need, you can connect PaaS components to your own virtual network. Containers and microservices introduce the concept of service meshes and virtual networks at the application layer as well – but those are built atop the underlying network. In SaaS, networking is almost entirely transparent to the user (aside from perhaps configuring which users can access the service). The OSI model still applies deeply here – cloud providers operate up to Layer 3 (network) by providing IP routing for VPCs, often give load balancing at Layer 4 (transport) or Layer 7 (application) for distributing traffic, and may offer WAFs (web application firewalls) at Layer 7 for SaaS/PaaS apps. We will discuss the OSI alignment in more detail in the next section. In short, networking services map to the infrastructure layer (VPCs, VPN connections, load balancers), and partly to platform (e.g., a PaaS might give you an HTTP endpoint with TLS (transport layer security) termination – that’s a Layer 7 service). Designing a cloud architecture means planning the network: setting up virtual networks for IaaS deployments, using proper load balancers (some cloud load balancers are IaaS-like where you configure them, others are embedded in PaaS), and ensuring connectivity between components (e.g., allowing a PaaS app to reach a DBaaS in a secure way).

  Security and Identity

• Security is a cross-cutting concern that spans all layers. Certain security features map to specific layers: for example, network security groups or firewall rules operate at the IaaS networking layer (controlling traffic at the IP/port level). Identity and Access Management (IAM) operates at the control layer of the cloud, letting you specify which identities (users, roles, services) can access which resources and at what level. Cloud providers typically centralize IAM as a service that affects all layers (for instance, AWS IAM can control access to an EC2 VM (IaaS), to a Lambda function (FaaS), or to a SaaS app’s API). At the platform layer, security includes things like application security groups, API keys, encryption services, and secure credential storage (e.g., AWS Secrets Manager or Azure Key Vault). At the SaaS layer, security features include user authentication, tenant isolation, and data encryption at rest and in transit, all managed by the provider. Mapping: Basic infrastructure security (physical security of data centers, host OS hardening) is done by provider at physical/infra layers; cloud users manage configuration security such as setting firewalls, using encryption (often via provider tools), and managing identities and roles. A well-architected cloud system uses security services at every layer: from network ACLs (IaaS) to identity federation and role-based access (management layer), to application-layer security like WAFs and OAuth for SaaS. For example, in IaaS you might use security groups to only allow web traffic to your web servers, in PaaS you might rely on the platform’s security sandbox to isolate apps and use the cloud’s secret management to store credentials, and in SaaS you might configure SSO (single sign-on) and data loss prevention policies in the app’s settings.

  Data Services and Analytics

• Beyond basic data storage, cloud providers offer higher-level data services such as managed databases (relational and NoSQL), data warehouses, big data processing frameworks, AI/ML services, and analytics tools. These typically reside in the platform layer (PaaS) as specialized services. For instance, Database as a Service (DBaaS) we discussed is a platform data service. Similarly, cloud data warehouses like Amazon Redshift or Snowflake (which runs on cloud) are essentially BPaaS/PaaS for analytics – they manage all infrastructure and let you run SQL analytics at scale. Stream processing services (e.g., Amazon Kinesis, Azure Event Hubs, Google Pub/Sub for ingestion; AWS Glue or Dataflow for ETL) are also platform services that tie into infrastructure (they use compute and storage under the hood but expose a simplified interface). Even machine learning model training and hosting can be delivered as a service (like Azure Machine Learning, AWS SageMaker) – those abstract the heavy-lifting of GPU clusters and provide an environment for data scientists (platform layer). Mapping: These data and analytics services leverage compute, storage, and network at lower layers but present an integrated solution at the platform or even as BPaaS (if it’s an entire data pipeline managed as a service). When building an application, one might choose to use these instead of building from scratch on VMs. For example, rather than deploy Hadoop on IaaS, you might use a cloud’s managed Hadoop/Spark service or serverless analytics service. The result is faster implementation of data pipelines and leveraging cloud’s scaling. Real-world example: Netflix uses a wealth of cloud data services – they ingest streaming events with services like Kinesis (which shards and processes events in parallel) and store data in S3 data warehouses and analytics platforms, including using tools like Amazon RDS, Hive, Druid, and even external solutions like Snowflake for different data at rest. By using these, Netflix can handle billions of events per day and run analytics without managing the underlying clusters directly.

  Developer Tools, DevOps Services, Observability and Monitoring

• Cloud providers also supply a range of tools to support development and operations: source code repositories, continuous integration/continuous delivery (CI/CD) pipelines, testing services, monitoring, and deployment management. These tools often sit in the service orchestration or management layer of the cloud reference model, cutting across IaaS/PaaS. For example, AWS CodePipeline/CodeBuild, Azure DevOps Services, or Google Cloud Build are CI/CD services (PaaS for build/deployment). They integrate with other layers (for instance, deploying to an IaaS VM or a PaaS app). Infrastructure as Code (IaC) tools like AWS CloudFormation or Terraform (provided as a service or used by the user) also operate at the control/orchestration layer, enabling automated provisioning of resources in the layers below. When mapping layers: developer tools are not exactly a separate layer in the runtime stack of an application, but rather cross-layer services that facilitate working with the cloud. They leverage underlying layers (e.g., a deployment service ultimately creates IaaS resources or deploys to PaaS). Observability and management tools (discussed next) similarly span layers.
• Observability refers to the tools and services for monitoring cloud resources and applications (collecting metrics, logs, traces) and responding to issues. In a traditional sense, these might be considered part of a management layer that oversees all others. Cloud providers offer integrated monitoring services (like Amazon CloudWatch, Azure Monitor, Google Cloud Operations) that can track infrastructure metrics (CPU, memory of VMs), application logs and performance (for apps running on PaaS or containers), and even end-user experience (for SaaS apps via synthetic monitoring). These services often use agents or APIs at the infrastructure and OS layers to gather data, but consolidate information at a higher layer where analytics and alerting occur. For instance, you might use CloudWatch to set an alarm if an EC2 instance’s CPU stays above 80% (infrastructure metric), or if an error appears in application logs (application layer insight). Observability services thus bridge the layers, ensuring that each layer’s performance can be measured and that the system as a whole can be managed. In an architecture, one should design with observability in mind – ensure that each component (whether IaaS VM, PaaS app, or third-party SaaS integration) is sending metrics/logs to a central service. Many organizations adopt additional third-party monitoring tools (like Datadog, New Relic) which function in a similar cross-layer manner.

In summary, each cloud building block can be placed in the context of the layered architecture:

• The physical layer is mostly invisible to users but crucial for providing physical compute, storage, and network resources.
• The infrastructure/virtual layer is where compute (VMs, containers), storage volumes, and virtual networks manifest for the cloud consumer – typically as IaaS services.
• The platform layer adds managed services on top: runtime environments, managed databases, integration services, and other middleware that developers consume.
• The service (application) layer includes the end-user facing functionality (SaaS applications or the business processes delivered).
• Management and security functions span across these layers, ensuring the system operates correctly and securely.

By mapping components to layers, architects can ensure that each concern is addressed at the appropriate level. For example, if you need data encryption at rest – at the infrastructure layer you might use encrypted storage volumes, at the platform layer you might enable database encryption or use a Key Management Service, and at the application layer you might enforce encryption of user-uploaded files in a SaaS. Layer mapping also helps identify gaps; e.g., if you are using mostly SaaS products, you know that your focus shifts to integration and identity management (since the lower layers are handled by SaaS vendors). If you are building on IaaS, you know you must implement more of the management and security at the infrastructure and OS level.

Understanding this mapping is fundamental to designing cloud architecture – it enables leveraging the right cloud services and controls at each layer for a robust, secure, and efficient system.