10.3: Cloud Resource Types

Cloud platforms offer a variety of resource types to build applications. The main categories include compute, storage, networking, databases, and serverless resources. Each type serves a specific role in the infrastructure, and cloud project managers must choose and configure these appropriately.

• Compute Resources (VMs and Containers): Compute typically refers to the processing power and memory needed to run applications. In cloud, the fundamental compute unit is often a virtual machine (VM) instance (such as an AWS EC2 instance, Azure VM, or Google Compute Engine instance). VMs are software-emulated servers that include virtualized hardware and can run a full operating system; you can think of them as traditional servers in the cloud. An alternative compute option is containers, which package an application with its dependencies into a lightweight, portable unit that shares the host OS kernel. The key difference is that a VM virtualizes an entire machine including the OS, while a container virtualizes only the user-space above the OS level. This makes containers much lighter weight; multiple containers can run on a VM or a physical host, sharing the OS, which enables higher density and faster startup. For example, Docker containers allow developers to deploy microservices efficiently, and Kubernetes (a container orchestration platform) can manage clusters of containers across many hosts, handling scheduling, scaling, and failover. Compute resources are measured in terms of CPU cores, RAM, and sometimes GPU or specialized accelerators. Cloud providers offer various instance types tuned for different needs (general-purpose, compute-optimized, memory-optimized, etc.). Containers and VMs are complementary – VMs provide strong isolation (each has its own OS) but with more overhead, whereas containers offer agility and efficiency but require managing the underlying host OS carefully. Many modern architectures use a combination: for example, running Kubernetes on a set of cloud VM instances to manage containerized workloads. In summary, compute resources are the workhorses executing application code, and architects must decide whether to use VMs, containers, or a mix, based on factors like elasticity, isolation, and operational control. (We discuss serverless compute as a separate category below.)
• Storage Resources: Cloud storage is used to persist data and files, and comes in multiple forms to suit different needs. The primary storage types are block storage, object storage, and file storage. Block storage is analogous to disk drives – it provides raw storage volumes that can be attached to VMs (e.g., Amazon EBS volumes, Azure Managed Disks, Google Persistent Disks) and are typically used for low-latency access by a single instance (like a C: or D: drive in the cloud VM). Object storage is a service for storing files (objects) in a flat address space, accessible via HTTP APIs – examples include Amazon S3, Azure Blob Storage, and Google Cloud Storage. Object storage is highly scalable and ideal for unstructured data, backups, media files, and data lakes; it decouples storage from any single server and provides built-in redundancy across availability zones. File storage offers a shared file system interface (like an NFS or SMB share) that multiple VMs can mount – services like Amazon EFS or Azure Files fall into this category, useful for legacy applications expecting a shared file system. Additionally, cloud providers offer database storage (covered below) and specialized storage tiers (such as archive storage like Amazon S3 Glacier for infrequently accessed data). When designing infrastructure, one must choose storage solutions based on access patterns, performance needs, and durability. For example, a transactional database might require high IOPS block storage, whereas user-uploaded images might reside in object storage. Many cost optimization strategies involve moving data to the appropriate storage tier (e.g., cold data to cheaper, slower storage). Data durability and redundancy are key benefits of cloud storage – providers typically replicate data across facilities; for instance, Amazon S3 is designed for 99.999999999% durability, replicating objects across multiple devices and AZs. In summary, cloud storage services provide virtually limitless capacity and resilience, but selecting the right type (block, object, file) is crucial for cost and performance optimization of cloud projects.
• Networking Resources: Networking in the cloud connects all the components and often mirrors traditional network constructs (but implemented in software). Each cloud account typically has virtual networks (e.g., Amazon VPC, Azure Virtual Network, Google VPC) which are logically isolated sections of the cloud provider's network where you can launch resources. Within these virtual networks, you define subnets (IP ranges), routing tables, and network gateways similar to on-premise networks. Key networking resources include load balancers that distribute traffic, firewalls/security groups that control inbound and outbound access, DNS services for naming, and gateways or VPN connections to link cloud networks with on-prem networks. For example, a cloud load balancer (AWS Elastic Load Balancer, Azure Application Gateway, or GCP Cloud Load Balancing) will distribute incoming requests across multiple instances in different availability zones, improving both performance and fault tolerance. Cloud networking also encompasses content delivery networks (CDN) like CloudFront or Azure CDN to cache content at edge locations, and traffic management services (AWS Route 53 or Azure Traffic Manager) to route users to the nearest or healthiest endpoints. One can implement complex network topologies in the cloud, including private subnets with no direct Internet access for backend systems and public subnets for front-facing services, all connected via routers/NAT gateways. Networking resources are critical for security as well – configuring network ACLs, security group rules, and perhaps micro-segmentation between services ensures only authorized traffic flows between components. A project manager should also be aware of network bandwidth costs; often data egress (data leaving the cloud network to the internet or another region) incurs charges, so network design can impact cost. In essence, cloud networking provides the connective tissue of an application’s infrastructure, and it must be designed to be secure, reliable, and low-latency. Using multiple availability zones and load balancing at the network layer is a common way to achieve high availability for the application layer.
• Database and Data Services: Cloud providers offer a range of database options as part of resource types, which can be seen as a specialized form of compute+storage combined with management. Broadly, there are relational databases (SQL) and NoSQL databases, and within these, there are managed services versus self-managed on VMs. Relational database services like Amazon RDS, Azure SQL Database, or Cloud SQL (for MySQL/PostgreSQL) allow you to run familiar database engines with the cloud provider managing backups, replication, and patching. These are great for structured data requiring ACID transactions (financial systems, inventories, etc.). There are also cloud-native relational databases built for scalability, like Google Spanner or Amazon Aurora, that can span regions or scale-out reads. On the NoSQL side, services like Amazon DynamoDB, Azure Cosmos DB, or Google Cloud Bigtable provide key-value, document, or wide-column stores optimized for massive scale and low-latency access, often at the cost of strict consistency. When designing infrastructure, the choice of database influences the overall architecture significantly – one might use a combination (polyglot persistence), e.g. a relational DB for core business data and a NoSQL cache or session store for high-frequency accesses. Cloud data services also include data warehousing (Amazon Redshift, Google BigQuery, Azure Synapse) for analytics, streaming data systems (Kafka on cloud or Kinesis), and cache services (like Redis or Memcached via Amazon ElastiCache or Azure Cache for Redis) to accelerate data access. Importantly, these database services come with built-in features for high availability and scaling: many managed SQL/NoSQL databases support read replicas across availability zones, automated failover for HA, and some can scale throughput or storage transparently. The cloud project manager must consider data residency (which regions data is stored in), consistency needs, and backup/restore strategies (though managed services simplify a lot of this). In terms of resource management, managed databases are often a preferred choice in cloud projects to reduce operational burden. Each managed database service is a resource that can be provisioned with certain capacity (like vCPUs, storage size, IOPS) and often supports on-demand scaling or tier changes. Selecting the right data store is a critical design decision: it must align with data access patterns and consistency requirements of the application, and the cloud offers many purpose-built options to choose from.
• Serverless Computing: Serverless is a category of compute where the cloud provider manages the server infrastructure and scaling for you, and you simply deploy code or functions. It abstracts servers entirely from the developer’s perspective – hence “serverless” (though servers still exist under the hood). The hallmark of serverless is that it auto-scales with demand and costs are incurred only when code is running (pay-per-execution pricing). The primary example is Functions as a Service (FaaS) – e.g., AWS Lambda, Azure Functions, Google Cloud Functions. With FaaS, developers write small units of code (functions) that are triggered by events (like an HTTP request, a file upload, a message arrival). The cloud platform instantiates and runs the function on demand, scaling out to many parallel executions if needed, and scaling to zero when no requests are present. This model is excellent for irregular workloads or event-driven architectures. Serverless functions have execution time limits (usually a few minutes max per invocation) and are stateless between calls, so they’re not suitable for every scenario (long-running processes or those needing fine-grained control over the environment might still require VMs or containers). Besides FaaS, other serverless resources include serverless databases and messaging services where capacity is auto-managed (for example, DynamoDB can be used in on-demand mode, or Google Firebase as a serverless database). There are also Backend as a Service (BaaS) components like authentication services (AWS Cognito, Firebase Auth) that offload entire backend features. The benefit of serverless in infrastructure design is that it greatly simplifies scalability and operational management – you don’t worry about provisioning the right number of servers or containers; the cloud automatically allocates resources in response to traffic. It also can be very cost-effective at low to medium loads because you pay strictly for usage, with no idle cost (e.g., if a Lambda function is rarely called, it costs nearly nothing). However, serverless introduces considerations like cold starts (slight delays when functions spin up) and often requires redesigning applications into event-driven workflows. In a cloud project, using serverless functions can speed up development and reduce DevOps overhead, but it’s important to evaluate if the application’s performance profile fits the serverless model. Many modern architectures end up using a mix: for instance, a serverless API tier (functions behind an API gateway) with a managed database tier, or event processing pipelines using serverless functions triggered by cloud storage events or queue messages. Serverless is essentially the epitome of cloud elasticity: it leverages the cloud’s fine-grained resource management to scale each function invocation independently and instantly, aligning resource usage exactly with demand.
  

---