Cloud applications depend on three fundamental capabilities: computation, persistent data storage, and data management. Compute services execute operating systems, application code, containers, and functions. Storage services retain files, objects, virtual disks, and backups. Database services organize information so that it can be queried, updated, secured, and recovered.

Cloud providers expose these capabilities as managed services. Instead of purchasing servers and installing storage arrays, an organization selects service types, capacity, performance characteristics, availability options, and security controls. The central architectural task is not simply choosing the most powerful service. It is matching workload requirements to an appropriate service while controlling cost, complexity, operational risk, and data-governance obligations.

This chapter uses general cloud concepts. Names and exact features differ among providers, but the design principles apply across major cloud platforms.

Learning Objectives

1. Compute Services

1.1 Virtual machines

A virtual machine (VM) is a software-defined computer that presents virtual CPU, memory, storage, and networking to a guest operating system. A hypervisor separates multiple VMs from the physical host. The cloud customer normally selects an instance family, operating-system image, virtual CPU count, memory, attached disks, network configuration, and billing model.

The principal advantage is control. The disadvantages are administrative responsibility, slower deployment than more abstract services, patching obligations, and possible underutilization.

A useful first estimate for compute capacity is the number of concurrent requests multiplied by the average resource demand per request. This is only an approximation because queueing, burst traffic, cache effects, and parallelism influence actual performance. Capacity should therefore be validated with representative load tests rather than selected solely from a formula.

1.2 Containers

A container packages an application and its dependencies while sharing the host operating-system kernel. Container images are immutable templates used to create running containers. A container orchestrator schedules containers, restarts failed instances, provides service discovery, and supports rolling updates.

Containers generally start faster and use fewer resources than full VMs, but they do not provide the same isolation boundary as a separate physical machine or VM. A production container design should specify image provenance, vulnerability scanning, resource limits, secrets handling, logging, health checks, and a strategy for persistent data.

Containers are especially useful for microservices, repeatable deployment pipelines, and applications that need horizontal scaling. They are less suitable when an application requires a custom kernel, persistent local state, or software incompatible with container packaging.

1.3 Serverless and managed compute

Function-as-a-service executes a discrete function in response to an event, such as an HTTP request, message, file upload, or scheduled trigger. The provider manages servers and usually charges according to invocations, execution duration, memory allocation, or related measures. Serverless functions are effective for short-lived, event-driven work, but execution limits, startup latency, statelessness, and platform-specific interfaces must be considered.

Managed application platforms occupy a middle position between VMs and functions. They abstract operating-system maintenance while supporting long-running web applications, background workers, or APIs. They can reduce administration but may constrain runtime versions, networking, or deployment models.

1.4 Selecting and configuring compute

Compute selection should begin with requirements rather than product names. Important dimensions include:

Requirement	Design question
CPU	Is performance limited by arithmetic, concurrency, or a specialized accelerator?
Memory	Must a large working set remain in memory?
Network	What throughput, latency, and private-connectivity features are required?
Storage	Is local temporary storage sufficient, or is persistent storage required?
Availability	Can the service run across failure domains?
Scaling	Should capacity increase vertically, horizontally, or both?
Operations	Who patches, monitors, backs up, and responds to failures?

Vertical scaling increases the size of an instance. Horizontal scaling adds instances. Horizontal scaling usually improves resilience, but the application must support distributed operation, shared configuration, and often external session state. An autoscaling policy should use meaningful signals such as request latency, queue depth, or utilization, with minimum and maximum capacity and a suitable stabilization period.

A highly available design normally places multiple instances across independent availability zones or failure domains behind a load balancer. The application should be stateless where possible, store durable state externally, and define health checks that detect whether an instance can actually serve requests.

2. Storage Services

2.1 Storage characteristics

Storage decisions involve more than capacity. Important characteristics include durability, availability, latency, throughput, IOPS, access pattern, consistency, geographic replication, encryption, retention, and cost.

Durability is the probability that data will not be lost over a stated period. Availability is the proportion of time a service is accessible. They are related but not identical: a system may retain data safely while temporarily being unavailable.

Here, A_i is the availability of component i and independence is assumed. In real systems, shared dependencies and correlated failures mean that this estimate may be optimistic. For redundant components operating in parallel, the probability that at least one is available is:

This expression assumes failure independence and a design in which any available component can serve the workload.

2.2 Object storage

Object storage stores complete objects, consisting generally of data, metadata, and a key. Objects reside in logical containers such as buckets. Applications access them through APIs rather than mounting them as ordinary operating-system disks.

Object storage is suitable for images, videos, documents, logs, datasets, software packages, backups, and static website assets. It provides high scalability and commonly supports versioning, lifecycle rules, replication, retention policies, event notifications, and server-side encryption.

Object storage is not normally a replacement for a low-latency block disk or a shared POSIX file system. Applications should also avoid assuming that object keys behave exactly like directories. Access control should use least privilege, private-by-default settings, scoped identities, and explicit public-access exceptions only when justified.

2.3 Block storage

Block storage presents virtual volumes to a VM. The operating system formats the volume with a file system, and applications interact with files or raw blocks. Block volumes are appropriate for boot disks, transactional databases, and applications requiring predictable low-latency random access.

Important configuration choices include volume type, capacity, IOPS, throughput, encryption, snapshots, attachment mode, and availability characteristics. A snapshot is generally a point-in-time copy or representation of a volume. It is useful for recovery and cloning but should not be assumed to be a complete application-consistent backup unless the workload is quiesced or an application-aware backup method is used.

2.4 File storage

File storage provides a shared file system with directories, file names, permissions, and often standard network file protocols. It is useful for shared content, home directories, legacy applications, media workflows, and applications that require concurrent file access.

File storage introduces concerns about locking, metadata performance, network latency, identity mapping, and consistency. A file system that is technically mountable by many servers may still perform poorly if thousands of clients repeatedly access the same directory or metadata path.

2.5 Storage classes and lifecycle management

Providers commonly offer storage classes optimized for frequent access, infrequent access, and archival retention. A lifecycle policy can transition objects between classes or delete them after a defined period. A typical policy might keep current content in a frequent-access tier, move it to an infrequent tier after 30 days, and archive it after one year.

Lifecycle design must account for minimum storage durations, retrieval fees, transition charges, legal holds, versioned objects, and business retention requirements. Automatic deletion is powerful and potentially dangerous; production policies should be tested, reviewed, and protected from unauthorized modification.

3. Database Services

3.1 Relational databases

A relational database stores data in tables connected through keys and constraints. SQL supports filtering, joining, aggregation, transactions, and declarative data definition. Relational services are a strong choice for financial records, orders, inventory, identity data, and other workloads requiring structured relationships and transactional integrity.

Normalization reduces unnecessary duplication and update anomalies, although carefully controlled denormalization may improve read performance. Indexes accelerate selected access patterns but consume storage and make writes more expensive. A managed relational database may provide automated patching, backups, replicas, monitoring, and failover, while still requiring schema design, query tuning, access control, and workload testing.

3.2 NoSQL databases

NoSQL is a broad category rather than one single data model. Key-value stores retrieve values using keys. Document databases store semi-structured records. Wide-column systems organize data for high-scale access by partition and sort keys. Graph databases represent entities and relationships as nodes and edges.

NoSQL services are often selected for very high throughput, flexible schemas, globally distributed access, or access patterns that do not require complex relational joins. The schema is frequently designed from the queries backward: identify the operations, choose partition keys, estimate item sizes and rates, and then model data for those operations.

Trade-offs may include denormalization, limited joins, eventual consistency, partition-key hot spots, and more application responsibility for maintaining related data. Some services provide strongly consistent reads, while others provide eventual or tunable consistency. The correct choice depends on business tolerance for stale data and the required latency and availability.

3.3 Database scaling and availability

Read replicas can distribute read traffic, but they may lag behind the primary database and generally do not automatically solve write capacity. Sharding or partitioning distributes data across nodes and can increase scale, but adds routing, rebalancing, and operational complexity.

RPO describes the maximum acceptable amount of data loss measured in time. RTO describes the maximum acceptable time to restore service. Neither is automatically guaranteed by having a backup; restoration must be tested.

3.4 Caching and in-memory data services

A cache stores frequently used data closer to the application. It can reduce database load and latency, but cached data may become stale and cache failures must be handled safely. Common patterns include:

A time-to-live (TTL) specifies how long an item remains eligible in the cache. TTL is not a universal solution to consistency; an explicit invalidation strategy may be necessary after updates. Cache keys should be designed to avoid collisions, and sensitive data should not be cached without appropriate encryption and access controls.

4. Backup, Recovery, and Data Protection

A backup is a recoverable copy of data maintained separately from the primary failure domain. Replication improves availability but is not necessarily a backup: accidental deletion or corruption may replicate immediately. Effective protection commonly combines point-in-time recovery, periodic full or incremental backups, cross-zone or cross-region copies, and immutable or offline retention for critical data.

A practical backup policy specifies scope, frequency, retention, encryption, geographic placement, access permissions, restoration priority, and test frequency. The 3-2-1 principle is a useful operational guideline: maintain at least three copies, on at least two types of media or storage locations, with at least one copy isolated from ordinary operational compromise. It is a guideline rather than a substitute for a workload-specific risk assessment.

Recovery testing should measure actual restoration time, validate application consistency, verify permissions and secrets, and document dependencies. A backup that cannot be restored is not a dependable recovery control.

5. Security, Governance, and Cost

Data should be classified according to sensitivity and regulatory obligations. Personally identifiable information, health data, payment information, and confidential intellectual property may require stricter access, retention, location, and audit controls. Encryption should be applied in transit and at rest, with managed keys or customer-controlled keys selected according to risk and governance requirements.

Identity and access management should use roles, short-lived credentials, least privilege, separation of duties, and multi-factor authentication for administrative access. Logs should record administrative actions, data-access events where appropriate, configuration changes, backup operations, and restoration activity. Logging itself may contain sensitive information and must be protected and retained according to policy.

Cloud cost is influenced by compute time, storage capacity, requests, data transfer, provisioned performance, backup copies, and managed-service features. Cost optimization should not sacrifice required availability or recovery objectives. Useful practices include rightsizing, autoscaling, storage lifecycle policies, deletion of unused resources, committed-use discounts for stable workloads, and budgets with alerts.

6. Applied Case: Online Retail Platform

Background

The following is an illustrative case. A small online retailer is moving its web application to the cloud. It sells products, accepts payments through a third-party provider, stores product images, and needs reliable order records during seasonal traffic peaks.

Problem

The existing application runs on one server with a local database and local image directory. A disk failure could interrupt sales and lose uploaded images. Seasonal demand is difficult to handle, and developers have no repeatable recovery procedure.

Analysis

Orders require transactional integrity because inventory and payment status must not be updated inconsistently. Product images are large, accessed through URLs, and do not need relational joins. Web servers can be made stateless, but sessions and asynchronous tasks must not depend on local disk. Recovery objectives are an RPO of 15 minutes and an RTO of one hour for the order system.

Approach and solution

The retailer adopts a managed relational database with multi-zone high availability, automated point-in-time recovery, and daily cross-region backup copies. The order schema uses primary keys, foreign keys, unique constraints, and indexes for customer, order status, and creation time. Read replicas are considered later if reporting traffic affects the primary workload.

The web tier runs in multiple availability zones behind a load balancer. Containers package the application, and an autoscaling policy adds instances when request latency and utilization exceed tested thresholds. Sessions are stored in a managed in-memory service or represented with securely signed tokens, rather than being stored on a particular web server.

Product images are placed in private object storage. The application issues time-limited access URLs, while a content delivery service caches public product content. Object versioning protects against accidental overwrites. Lifecycle rules move old product assets and historical exports to lower-cost tiers, subject to retention requirements.

A message queue separates order submission from tasks such as email notifications and invoice generation. This prevents slow secondary work from blocking the customer request. Monitoring covers error rate, latency, queue depth, database connections, storage growth, backup success, and cache performance.

Outcome

The design separates transactional data from unstructured media, allows web capacity to scale horizontally, and reduces dependence on a single server. The retailer conducts quarterly restoration tests and records measured RTO and RPO performance. The architecture still requires careful database migration, secret management, cost monitoring, and testing during peak traffic.

Learning points

The case demonstrates that service selection follows data characteristics and business requirements. Object storage is not chosen merely because it is inexpensive; it matches the access pattern. A relational database is retained because orders require transactions and relationships. Compute becomes replaceable because durable state is externalized. Finally, backup, monitoring, and restoration testing are architectural requirements rather than optional operational details.

7. Best Practices and Common Limitations

Use managed services when their operational benefits outweigh portability or feature constraints. Document the reason for each service choice and identify exit costs. Start with a minimal architecture, but do not omit security boundaries, backups, observability, or failure testing.

Avoid storing durable data on ephemeral container filesystems. Do not expose storage buckets or databases directly to the public internet unless there is a compelling, controlled requirement. Do not treat a replica as a backup, or assume that encryption alone satisfies privacy obligations. Avoid selecting a database before understanding access patterns. Finally, do not rely on autoscaling without testing startup time, quotas, downstream limits, and graceful degradation.

Contemporary cloud designs increasingly combine virtual machines, containers, serverless functions, managed databases, event streams, and AI-assisted operations. AI tools can help summarize logs, detect anomalies, or generate infrastructure drafts, but generated configurations require human review. An incorrect access policy, destructive lifecycle rule, or misleading operational recommendation can create significant security and availability risks.

Chapter Summary

Compute services range from highly controlled virtual machines to containers, managed application platforms, and event-driven functions. Selection depends on operating-system control, deployment speed, scaling behavior, operational responsibility, and workload characteristics. High availability requires redundancy across independent failure domains and externalization of durable state.

Object storage is optimized for scalable API-based storage of complete objects. Block storage provides virtual disks for operating systems and low-latency applications. File storage provides shared directories and file semantics. Storage classes and lifecycle policies can reduce cost but must respect retrieval, retention, and deletion risks.

Relational databases support structured relationships and ACID transactions. NoSQL services support alternative data models and high-scale access patterns, often requiring deliberate partition-key and consistency design. Caches reduce latency and database load but introduce staleness and invalidation concerns. Backups, replication, RPO, RTO, encryption, identity management, monitoring, and restoration testing complete a responsible service architecture.

Key Terms

Virtual machine: A software-defined computer running on virtualized physical resources.

Container: An isolated application environment sharing the host operating-system kernel.

Autoscaling: Automatically adjusting compute capacity in response to workload conditions.

File storage: Shared storage organized using files, directories, and file-system semantics.

Durability: The likelihood that stored data will not be lost over a specified period.

Relational database: A database organized into related tables and accessed commonly with SQL.

NoSQL: A group of non-relational data models including key-value, document, wide-column, and graph systems.

ACID: Atomicity, consistency, isolation, and durability properties of transactions.

Time-to-live: The period for which cached or stored data remains eligible before expiration.

Least privilege: Granting only the access necessary to perform an approved task.

Review Questions

Short Answer Questions

Long Answer Questions

Analytical / Application Questions

Multiple Choice Questions with Answers

Question 1

Which storage service is most appropriate for large videos and backup archives accessed through APIs?

Question 2

Correct Answer: B. They generally start faster and package applications consistently

Question 3

Which database characteristic is most important for maintaining an order transaction across related tables?

Question 4

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 5

Correct Answer: C. It can distribute read traffic but may experience replication lag

Question 6

A. The application retrieves data from the backing store and populates the cache

Correct Answer: A. The application retrieves data from the backing store and populates the cache

Question 7

Which service is most suitable when several servers require shared directories and file semantics?

Question 8

Correct Answer: B. To prove that the backup is actually usable within recovery objectives

Question 9

Correct Answer: C. Granting an application only the actions and resources it requires

Question 10

Correct Answer: A. Transition or delete stored data according to defined rules

Chapter 4 Compute, Storage, and Database Services

Compute, Storage, and Database Services

Introduction