5. Compute, Storage and Managed Databases

Introduction and Context

Cloud applications are built from a small number of foundational capabilities: computation, storage, data management, networking, and security. Among these, compute, storage, and databases determine much of an application's performance, resilience, scalability, and operating cost. Choosing an inappropriate service can create persistent architectural problems. For example, a database designed for transactional consistency may be unsuitable for large analytical workloads, while an object store may be inexpensive and durable but inappropriate for a disk requiring low-latency random writes.

The major cloud providers—Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)—offer broadly comparable service categories, although product names, interfaces, pricing models, and feature details differ. AWS provides services such as Elastic Compute Cloud (EC2), Elastic Block Store (EBS), Elastic File System (EFS), Simple Storage Service (S3), Relational Database Service (RDS), DynamoDB, ElastiCache, and Backup. Comparable services include Azure Virtual Machines, Managed Disks, Blob Storage, Azure Files, Azure SQL Database, Cosmos DB, Azure Cache for Redis, and Azure Backup; and GCP Compute Engine, Persistent Disk, Cloud Storage, Filestore, Cloud SQL, Firestore, Memorystore, and Backup for GKE or database-specific backup services.

This chapter develops a decision-oriented understanding of these services. The central question is not simply which service is technically available, but which combination satisfies requirements for latency, throughput, consistency, durability, availability, recoverability, security, operational effort, and cost.

Learning Objectives

By the end of this chapter, learners should be able to:

1. Distinguish virtual machines, containers, serverless compute, and autoscaling architectures.

2. Select object, block, and file storage according to access patterns and durability requirements.

3. Compare relational and NoSQL databases using workload, consistency, scalability, and data-model criteria.

4. Explain caching, replication, backup, recovery point objectives, and recovery time objectives.

5. Design a practical cloud deployment using managed compute, storage, databases, and observability.

6. Evaluate cost, governance, security, and operational risks in architectural decisions.

The Decision Dimensions of Cloud Infrastructure

A sound infrastructure decision begins with workload characteristics rather than product familiarity. Six dimensions are especially important.

Latency is the time taken to respond to a request. Interactive applications may require consistently low latency, whereas archival processing may tolerate minutes or hours. Throughput is the volume of operations or data processed per unit of time. A system may have low latency for individual requests but inadequate throughput during a traffic surge.

Consistency describes when and how different readers observe writes. Strong consistency gives predictable visibility of committed data, while eventual consistency allows replicas to converge after a delay. Eventual consistency can improve availability and scale, but application logic must tolerate temporary differences.

Durability is the probability that stored data will not be lost. Availability is the proportion of time a service is operational and reachable. They are related but not identical: a service can be available while returning stale data, and data can remain durable even when the application is temporarily unavailable.

Scalability concerns the ability to handle increased load. Vertical scaling increases the capacity of one resource; horizontal scaling adds more instances. Elasticity is the ability to add and remove capacity automatically as demand changes.

Finally, an architect must assess cost and operational responsibility. Managed services generally reduce patching and maintenance work, but they may impose usage charges, configuration constraints, and provider dependence. The appropriate design balances technical requirements with business value.

Compute: From Virtual Machines to Elastic Platforms

A virtual machine (VM) is a software-defined computer that receives virtual CPU, memory, networking, and storage. A cloud VM usually runs inside a provider-managed hypervisor, while the customer selects an operating-system image, machine size, network placement, storage volumes, and security rules. VMs offer extensive control and are suitable when an application requires a particular operating system, kernel capability, commercial package, or migration path from a physical data centre.

The principal disadvantages are administrative. Teams are responsible, to varying degrees, for operating-system updates, vulnerability remediation, monitoring, capacity planning, configuration, and instance recovery. A VM is also commonly stateful by default: files placed on its local or attached disk may not be available when the instance is replaced. Production designs should therefore separate application instances from durable state whenever possible.

Instance selection and deployment

Selecting a VM size requires estimating CPU utilization, memory pressure, network traffic, storage I/O, and workload variability. A CPU-intensive compiler may need high compute capacity, while an in-memory analytics service may require large memory. General-purpose instances are useful for mixed workloads, but specialized compute, memory, storage, or accelerated instances may be more economical when a bottleneck is known.

A robust VM deployment normally uses an image or machine template containing the operating system and application prerequisites. Configuration should be automated through infrastructure as code and startup scripts rather than performed manually through remote login. Security groups, network security rules, least-privilege identity roles, encrypted volumes, and central logging should be defined as part of the deployment.

Autoscaling and load distribution

An autoscaling group or equivalent managed instance group maintains a fleet of interchangeable instances. It can replace unhealthy instances and increase or decrease capacity according to CPU usage, request rate, queue depth, schedule, or a custom metric. A load balancer distributes requests across healthy instances and commonly performs health checks.

Autoscaling is effective only when the application is designed for horizontal operation. Instances should be stateless or should externalize sessions, uploaded files, and other durable information. A sudden increase in traffic may also be limited by database capacity, connection pools, quotas, or downstream APIs. Scaling the web tier alone does not solve a bottleneck in a shared database.

Autoscaling policies require careful calibration. If the scale-out threshold is too high, users experience overload before new instances become ready. If it is too low, the system may oscillate, creating unnecessary cost. Warm-up time, cooldown periods, minimum capacity, maximum capacity, and graceful termination are operationally significant.

Alternative compute models

Containers package an application and its dependencies in a portable image. They typically start faster and use resources more efficiently than full VMs, but they still require an orchestration or managed container platform. Kubernetes-based services provide powerful scheduling and networking capabilities but introduce substantial operational complexity.

Serverless functions execute code in response to events or requests without requiring the customer to manage servers. They are useful for short-lived, event-driven tasks, API operations, file processing, and automation. Their limitations include execution duration, cold-start latency, runtime constraints, concurrency limits, and more complex debugging. Serverless compute does not eliminate architecture; it shifts attention toward events, permissions, retries, idempotency, and observability.

Storage as an Access-Pattern Decision

Cloud storage is best understood through three abstractions: object, block, and file storage. They differ in how data is addressed, shared, modified, and scaled.

Object storage

Object storage stores an object consisting of data, metadata, and a key in a flat or logically hierarchical namespace. AWS S3, Azure Blob Storage, and Google Cloud Storage are examples. Applications access objects through APIs rather than treating them as ordinary operating-system files.

Object storage is appropriate for images, videos, documents, backups, logs, software packages, data-lake datasets, and static website assets. It offers high durability, large scale, lifecycle policies, versioning, access controls, and storage classes ranging from frequently accessed to archival. Its limitations include API-oriented access, generally higher latency than local or block storage for small synchronous operations, and unsuitable semantics for applications requiring frequent in-place random updates.

Lifecycle rules can move objects to cheaper storage classes or delete them after a retention period. Versioning protects against accidental overwrite and deletion, but it can increase cost if old versions are not managed. Encryption, object-level permissions, retention locks, and access logging support governance and compliance.

Block storage

Block storage presents a raw volume to a VM. The operating system formats the volume with a file system and performs reads and writes to logical blocks. AWS EBS, Azure Managed Disks, and GCP Persistent Disk are examples.

Block storage is suited to VM boot disks, transactional databases, application disks, and workloads requiring low-latency random access. Performance is commonly determined by volume type, capacity, provisioned IOPS, throughput, and burst behaviour. Snapshots are usually incremental and stored through provider-managed mechanisms; they are valuable for backup and cloning but should not be treated as a complete disaster-recovery plan without testing restoration and cross-region requirements.

A block volume is normally attached to one VM or a controlled cluster configuration. It is not automatically a shared file system. Applications should also distinguish between disk capacity and disk performance: increasing capacity may not provide the required IOPS, and a high-performance disk may be wasteful for a low-activity workload.

File storage

File storage exposes a shared hierarchical file system using protocols such as NFS or SMB. AWS EFS, Azure Files, and GCP Filestore serve this purpose. Multiple compute instances can mount the same file system, making it useful for shared application assets, content management, home directories, and legacy applications that expect file semantics.

File storage simplifies sharing but introduces concerns about network latency, locking, permissions, throughput, and concurrent access. It should not automatically replace a database or object store. Large immutable media files, for example, are often more economical in object storage, while shared low-latency file operations may justify a file system.

Storage selection matrix

A practical selection approach is:

• Choose object storage for durable, API-accessed, largely immutable content and backups.
• Choose block storage for operating-system disks and low-latency random I/O attached to compute.
• Choose file storage when multiple compute nodes require shared hierarchical file access.
• Use a database when the primary need is structured querying, transactions, constraints, or indexed records rather than merely storing bytes.

Managed Relational Databases

Relational databases represent data in tables with defined schemas, relationships, indexes, and constraints. SQL provides a declarative language for querying and modifying data. Relational systems are particularly strong for financial transactions, inventory, orders, identity records, and other workloads requiring atomicity and well-defined relationships.

The ACID properties provide a useful conceptual model. Atomicity ensures that a transaction is completed fully or not at all. Consistency preserves defined integrity rules. Isolation controls the visibility of concurrent transactions. Durability ensures committed data survives failures. Managed services such as Amazon RDS and Aurora, Azure SQL Database, and Cloud SQL automate much of provisioning, patching, backups, monitoring, and high-availability configuration, although the customer remains responsible for schema design, query performance, access control, and application behaviour.

A highly available relational deployment commonly uses a primary database and a synchronous or near-synchronous standby in another availability zone. Read replicas may distribute read traffic, but they often introduce replication lag and do not automatically solve write scaling. Database connection pooling is essential because each connection consumes resources, and autoscaling application instances can otherwise exhaust database connection limits.

Relational databases require disciplined indexing and query analysis. An index can accelerate reads but consumes storage and slows writes. Poorly selective indexes, unbounded queries, table scans, and inefficient joins can overwhelm an otherwise powerful instance. Schema migration should be automated, versioned, and designed to support rolling application deployments.

NoSQL Databases and Polyglot Persistence

NoSQL is not one database model. It includes key-value, document, wide-column, graph, and other systems. NoSQL databases often provide flexible schemas, horizontal partitioning, and high request rates. Examples include DynamoDB, Azure Cosmos DB, Firestore, and Bigtable-like services.

The central design principle is to model data around access patterns. In a relational design, normalization reduces duplication and supports many query relationships. In a distributed NoSQL design, denormalization and data duplication may improve predictable access at scale. The application may need to maintain duplicated values or use asynchronous reconciliation.

A partition key distributes records across storage nodes. A poor key—such as a single highly popular customer or a monotonically increasing value—can create a hot partition. Good key design spreads traffic while still supporting required queries. Developers must understand whether the service offers strong, session, bounded-staleness, or eventual consistency and whether secondary indexes have cost or performance implications.

NoSQL is appropriate when access patterns are known, horizontal scale is central, flexible or rapidly changing schemas are valuable, and the workload can accept the consistency and transaction model offered. It is not automatically superior for every high-volume application. A relational database may remain the better choice where complex joins, constraints, and multi-record transactions dominate.

Polyglot persistence uses more than one data technology, assigning each workload to a suitable system. For example, a commerce platform may use a relational database for orders, object storage for product images, a key-value store for shopping sessions, and a cache for popular catalogue data. This improves fit but increases operational, integration, and governance complexity.

Caching, Backups, and Recovery

A cache stores data closer to the consumer to reduce latency and backend load. Managed Redis or Memcached services are common choices. Caches are usually treated as disposable: if a cache is lost, the application should retrieve data from the authoritative source and repopulate it. Cache-aside is a common pattern in which the application reads from the cache, fetches from the database on a miss, and then writes the result to the cache.

Caching introduces risks. Stale data, cache stampedes, inconsistent invalidation, memory exhaustion, and accidental storage of sensitive information can damage correctness and security. Time-to-live values should reflect business tolerance for staleness. Distributed locks, request coalescing, and proactive refresh can reduce stampedes for highly popular keys.

A backup is a recoverable copy or representation of data; replication is the maintenance of another operational copy. Replication can improve availability but may replicate corruption or accidental deletion. Backups should therefore include retention policies, point-in-time recovery where appropriate, access restrictions, encryption, and periodic restoration tests.

Two planning measures are essential. Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time. Recovery Time Objective (RTO) is the maximum acceptable time to restore service. A system with an RPO of five minutes may require frequent log or snapshot replication, while a system with an RTO of several hours may use a lower-cost backup-and-restore strategy.

A backup strategy should address regional failure, ransomware, credential compromise, operator error, and legal retention requirements. The principle commonly called the 3-2-1 approach recommends multiple copies, different media or storage mechanisms, and at least one geographically separate copy. Provider durability claims do not remove the need for application-level recovery testing.

A Practical Architecture Decision Framework

A useful process begins by documenting the workload:

1. Identify data types, request patterns, read/write ratios, peak load, latency targets, and growth.

2. Classify data according to confidentiality, retention, legal requirements, and recovery importance.

3. Determine consistency, transaction, availability, RPO, and RTO requirements.

4. Select the simplest compute model that meets control and performance needs.

5. Select storage by access pattern rather than by default preference.

6. Choose a database model based on queries, transactions, partitioning, and operational skills.

7. Add caching only after identifying a measurable latency or load problem.

8. Model cost, including compute, storage, requests, data transfer, backups, replicas, and support.

9. Test failure, scaling, restoration, and security assumptions before production release.

This process prevents premature commitment to a specific vendor service. It also encourages a layered architecture: stateless application compute, durable data services, asynchronous messaging where useful, and independent observability.

Illustrative Case Study: Scaling a Regional Food-Delivery Platform

Background

The fictional company QuickPlate operates a food-delivery application in one region. Customers browse restaurants, place orders, pay electronically, and track delivery. Demand is moderate during the day but rises sharply during lunch and dinner. The original application runs on two VMs, stores uploaded restaurant images on local disks, and uses a single self-managed relational database.

Situation and problem

During peak periods, the web servers become overloaded, restaurant images are lost when a VM fails, and the database experiences slow queries. Management requires higher availability, an RPO of fifteen minutes, and an RTO of one hour without doubling infrastructure cost during off-peak periods.

Analysis

The application tier is mostly stateless except for session data and temporary uploads. Orders, payments, and restaurant availability require transactional consistency. Images are durable but rarely modified after upload. Frequently viewed restaurant menus create repeated database reads. The architecture therefore contains different workload types that should not be forced into one storage technology.

Approach

The team deploys the application in a managed instance group behind a load balancer. A minimum number of instances supports ordinary traffic, while autoscaling responds to request rate and CPU utilization. Sessions are moved to a managed key-value cache or signed client-side tokens, and uploaded images are placed in object storage rather than local VM disks.

The self-managed database is migrated to a managed relational database with multi-zone high availability, automated backups, point-in-time recovery, encryption, and a read replica for reporting or read-heavy operations. Indexes are reviewed using query plans, and connection pooling limits the impact of application scaling. A cache stores popular, non-sensitive menu data with a short time-to-live.

Backup copies are retained according to business and legal requirements, with a second-region copy for disaster recovery. The team conducts a restoration exercise and documents the exact steps, permissions, DNS changes, and application configuration required during failover. Monitoring measures request latency, error rate, database connections, replica lag, cache hit ratio, storage growth, and autoscaling activity.

Outcome

The revised design separates stateless compute from durable state, supports peak traffic through horizontal scaling, and reduces repeated database reads. Object storage prevents loss of uploaded images during VM replacement. Managed database operations reduce patching effort, while tested backups address the stated recovery objectives. Costs remain controlled by scaling compute elastically and placing older media in a lower-cost storage class.

Learning points

The case demonstrates that availability is an architectural property rather than a single product feature. Autoscaling cannot compensate for an unscalable database, replicas are not substitutes for backups, and a cache must not become the only authoritative copy of data. Most importantly, different forms of data should be assigned to services according to their access and recovery requirements.

Risks, Governance, and Professional Practice

Common mistakes include selecting instances by habit, storing persistent files on ephemeral disks, exposing databases to the public internet, assuming a multi-zone deployment protects against every disaster, and enabling autoscaling without quotas or cost controls. Another frequent error is treating provider-managed as responsibility-free. Managed services reduce infrastructure administration but do not eliminate identity management, data classification, secure configuration, application vulnerabilities, or recovery testing.

Access should follow least privilege. Database credentials should be stored in a secrets manager and rotated. Encryption should be enabled in transit and at rest, with key ownership and rotation documented. Network segmentation should restrict database access to approved application components. Audit logs should record administrative and data-access events where required.

Governance includes tagging resources for ownership and cost allocation, applying retention and deletion policies, restricting approved regions, and defining infrastructure through reviewed code. Organizations should consider data residency, privacy obligations, contractual requirements, and sector-specific regulation before selecting a region or replication design. Automated policy tools can identify public storage buckets, unencrypted disks, excessive permissions, and resources without backups.

Artificial intelligence can assist with capacity forecasting, anomaly detection, query recommendations, and operational correlation. These tools should support rather than replace engineering judgment. Automated recommendations require validation because cost optimization may conflict with availability, and anomaly systems may misinterpret legitimate seasonal traffic.

Current Developments

Cloud platforms increasingly provide managed distributed databases, serverless container execution, storage tiering, confidential computing, and automated database optimization. Database services are also separating storage and compute, allowing more independent scaling. Edge computing places selected processing and cached content closer to users, reducing latency for geographically distributed applications.

The growth of data-intensive applications has increased interest in lakehouse architectures, in which object storage provides a durable analytical foundation while structured query engines provide warehouse-like access. At the same time, platform engineering teams are creating internal service templates that standardize secure VM groups, database provisioning, backups, and observability.

These developments do not remove fundamental design questions. Data locality, consistency, failure behaviour, cost visibility, and operational ownership remain central even when provisioning is highly automated.

Best Practices

1. Design application instances to be replaceable and keep durable state in appropriate managed services.

2. Choose object, block, or file storage according to access semantics and performance needs.

3. Select databases from workload and query patterns, not from popularity.

4. Separate high availability, durability, backup, and disaster recovery in design discussions.

5. Use infrastructure as code, automated migrations, tagging, and policy controls.

6. Monitor business-level indicators as well as CPU, memory, storage, and network metrics.

7. Test scaling, failover, backup restoration, and security controls regularly.

8. Use caching selectively, define staleness tolerance, and protect against cache stampedes.

9. Estimate total cost, including data transfer, replicas, requests, backups, and idle capacity.

10. Document ownership, recovery procedures, dependencies, and service limits.

Chapter Summary

Compute services provide the execution environment for applications, ranging from controllable virtual machines to containers and event-driven serverless functions. Production compute should generally be replaceable, horizontally scalable, load-balanced, and automated. Object, block, and file storage solve different problems: objects provide durable API-based storage, blocks provide attached low-latency volumes, and files provide shared hierarchical access.

Managed relational databases support structured schemas, transactions, and strong integrity requirements, while NoSQL systems support selected access patterns, flexible models, and horizontal scale. Caches reduce latency but are normally non-authoritative. Replication improves availability, whereas backups address recovery from corruption, deletion, and disaster. RPO and RTO translate business recovery expectations into technical design.

Effective cloud architecture combines these services according to workload characteristics, consistency, durability, availability, performance, security, governance, and cost. The best design is not the one with the most services, but the simplest design that meets its stated requirements and has been tested under failure.

Key Terms

Virtual machine: A software-defined computer providing virtualized CPU, memory, networking, and storage.

Autoscaling: Automatic adjustment of compute capacity in response to workload or policy.

Load balancer: A service that distributes network requests among healthy targets.

Object storage: API-based storage of data objects identified by keys and accompanied by metadata.

Block storage: Persistent storage presented as addressable blocks to a host operating system.

File storage: Shared hierarchical storage accessed through file-system protocols.

Durability: The likelihood that stored data remains intact over time.

Availability: The proportion of time a service is operational and accessible.

Relational database: A database based on tables, relationships, schemas, and SQL operations.

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

NoSQL database: A non-relational database model designed for particular scalability and access requirements.

Partition key: An attribute used to distribute records across partitions in a distributed database.

Read replica: A replicated database instance primarily serving read operations.

Cache: A fast temporary data store used to reduce latency and backend workload.

Replication: Maintaining one or more operational copies of data.

Backup: A recoverable copy or representation of data retained for restoration.

RPO: The maximum acceptable period of data loss measured in time.

RTO: The maximum acceptable time required to restore service.

Infrastructure as code: Declarative or programmed management of infrastructure through version-controlled files.

Polyglot persistence: Use of multiple data technologies, each selected for a particular workload.

Review Questions

Short Answer Questions

1. Distinguish durability from availability.

2. What is the purpose of an autoscaling group?

3. State one suitable use for object storage and one for block storage.

4. What do the RPO and RTO measures describe?

5. Why can a read replica fail to solve a write-scaling problem?

Long Answer Questions

1. Explain how compute, storage, and database choices should be aligned with workload characteristics.

2. Compare object, block, and file storage in terms of access model, performance, and typical applications.

3. Discuss the strengths and limitations of managed relational databases and NoSQL databases.

4. Explain how caching, replication, and backup differ and how they work together in a resilient design.

5. Describe a complete process for designing an autoscaling web application with a managed database.

Analytical / Application Questions

1. A document-processing system receives large files, performs asynchronous transformations, and stores results for seven years. Recommend compute and storage services and justify the choices.

2. An online retailer experiences high read traffic, occasional hot products, and strict transactional requirements for payment and order creation. Propose a database and caching strategy, including consistency safeguards.

3. A company requires an RPO of five minutes and an RTO of thirty minutes for a regional application. Evaluate the technical and governance measures needed to meet these objectives and identify likely cost trade-offs.

22. Multiple Choice Questions with Answers

Question 1

A web application must scale horizontally, and users may be routed to any healthy instance. Which design best supports this requirement?

A. Store user sessions and uploads only on each instance's local disk

B. Use stateless instances and externalize sessions and durable files

C. Disable health checks so all instances receive traffic

D. Use one very large VM instead of multiple instances

Correct Answer: B. Use stateless instances and externalize sessions and durable files

Question 2

Which storage type is most appropriate for large, durable, mostly immutable video files accessed through APIs?

A. Object storage

B. Block storage

C. Local VM memory

D. A database transaction log

Correct Answer: A. Object storage

Question 3

Why might increasing a block volume's capacity fail to solve an application's performance problem?

A. Capacity and IOPS or throughput are separate performance dimensions

B. Block storage cannot be encrypted

C. Larger volumes cannot be attached to VMs

D. Capacity increases always reduce durability

Correct Answer: A. Capacity and IOPS or throughput are separate performance dimensions

Question 4

Which workload most strongly favours a relational database?

A. A graph of temporary social recommendations with eventual consistency

B. A transactional order system requiring integrity across multiple related records

C. Archival storage of unstructured media

D. A cache of popular catalogue responses

Correct Answer: B. A transactional order system requiring integrity across multiple related records

Question 5

A NoSQL database is suffering from a hot partition. What is the most likely architectural cause?

A. The partition key distributes requests evenly

B. The database uses encryption at rest

C. A small number of partition-key values receives disproportionate traffic

D. The application uses object storage for images

Correct Answer: C. A small number of partition-key values receives disproportionate traffic

Question 6

Which statement best distinguishes replication from backup?

A. Replication always provides protection from accidental deletion

B. A backup is an operational copy used only for live traffic

C. Replication supports operational availability, while backups support restoration after loss or corruption

D. Replication and backup are identical terms

Correct Answer: C. Replication supports operational availability, while backups support restoration after loss or corruption

Question 7

An application can tolerate data that is five minutes old but must recover within one hour. Which pair expresses these requirements?

A. RPO of one hour and RTO of five minutes

B. RPO of five minutes and RTO of one hour

C. RPO and RTO both of five minutes

D. RPO and RTO both of one hour

Correct Answer: B. RPO of five minutes and RTO of one hour

Question 8

What is a significant risk of adding a cache without defining invalidation behaviour?

A. The authoritative database becomes automatically more durable

B. Users may receive stale data after the source has changed

C. The cache guarantees transactional isolation

D. Database backups become unnecessary

Correct Answer: B. Users may receive stale data after the source has changed

Question 9

Which practice best reduces the risk of database connection exhaustion during application autoscaling?

A. Create an unlimited database connection per request

B. Use connection pooling and control the connection budget per instance

C. Disable application health checks

D. Store database credentials in source code

Correct Answer: B. Use connection pooling and control the connection budget per instance

Question 10

A team wants to meet disaster-recovery objectives but has only configured a multi-zone database standby. What is still essential?

A. Remove all backups because the standby is sufficient

B. Test restoration and address regional failure, deletion, and corruption scenarios

C. Move all application files to VM local disks

D. Disable encryption to simplify failover

Correct Answer: B. Test restoration and address regional failure, deletion, and corruption scenarios