Cloud computing: rent and operate computing resources

Understand how cloud platforms provide computing, storage, and managed services on demand—and the design, reliability, security, and cost decisions that come with them.

What cloud computing means

Cloud computing provides shared computing resources—such as processors, storage, databases, and networking—over a network, typically with on-demand provisioning and usage-based billing. Instead of purchasing and maintaining every physical server, an organization can request capacity from a cloud provider.

The cloud does not remove physical computers; it changes who owns and operates them and how customers access their capabilities. Applications still run on real machines in data centers, and their performance depends on hardware, networks, software, and operational choices.

• On demand: create or release resources through a console, API, or configuration.
• Shared infrastructure: a provider serves many customers with isolation controls.
• Measured use: consumption is tracked and often billed by time, storage, or requests.
• Network access: services are reached through private or public networks.

Cloud adoption can speed up experiments and make global deployment easier, but it does not automatically make a system scalable, secure, inexpensive, or highly available. Those qualities require deliberate design and operation.

Service and deployment models

Cloud service models describe how much of the stack the provider operates and how much the customer manages.

Model	Provider commonly manages	Customer commonly manages
Infrastructure as a Service (IaaS)	Physical facilities and virtualization	Operating system, software, data, and configuration
Platform as a Service (PaaS)	Infrastructure plus much of the runtime platform	Application code, data, and selected settings
Software as a Service (SaaS)	Most of the application stack	Accounts, content, access, and configuration
Serverless / functions	Infrastructure and execution environment scaling	Function code, triggers, permissions, and behavior

The boundaries vary by product. “Serverless” does not mean there are no servers; it means the provider abstracts more of the server provisioning and runtime management. A managed service can reduce operational work while limiting control over versions, configuration, or portability.

Deployment models include public cloud, private cloud, hybrid deployments that combine environments, and multi-cloud use of multiple providers. Each adds operational and networking considerations; using several providers is not automatically more resilient if the same credentials, software, or region remain shared failure points.

Regions, zones, and networking

A cloud region is a geographic area containing provider facilities. Regions are often divided into multiple isolated availability zones. Placing redundant components in separate zones can reduce the effect of some local failures, but zones may still share dependencies and regional outages can affect all of them.

Cloud networking uses virtual networks, subnets, routes, gateways, and firewall-like rules. A service can be private to an application network or exposed to the public Internet. Design network boundaries intentionally: only services that need to communicate should be allowed to do so.

Choose location with users and data in mind

Distance affects latency. A region close to users can reduce response time, while legal requirements or provider capabilities may constrain where data is stored. Replicating data across regions can improve recovery and availability but introduces cost, synchronization delay, and data-governance obligations.

Before choosing a region, consider user locations, service availability, data-residency requirements, disaster recovery, and network dependencies. Document the assumptions and test the actual latency that users experience.

Compute choices

Cloud compute can be provided by virtual machines, containers, managed application platforms, or event-triggered functions. These choices differ in control, startup time, isolation, operational responsibility, scaling behavior, and billing model.

• Virtual machine: a flexible virtual computer where the customer manages an operating system and installed software.
• Container: a packaged application and its dependencies, run using a shared host kernel and container runtime.
• Managed platform: a service that handles more deployment and runtime details.
• Function service: runs small units of code in response to events, often scaling automatically within service limits.

Containers are not the same as virtual machines: a container typically isolates processes while sharing the host kernel. Containers make packaging and deployment more consistent, but they still need secure images, resource limits, networking, monitoring, and updates.

Worked example: launch a small website

A small site might use a managed hosting service for its web application, object storage for uploaded images, and a managed database for account records. A domain name points visitors to an entry service, which routes requests to the application. Access rules keep the database private, and monitoring records response times and errors.

This design avoids manually managing every server, but the team still configures permissions, chooses data backups, patches application dependencies, manages secrets, tests recovery, and watches costs. Managed infrastructure transfers some operational duties; it does not transfer responsibility for the application’s behavior.

Storage and managed databases

Cloud storage is offered in several forms. Object storage stores files or blobs with metadata and is useful for media, backups, and static content. Block storage provides volumes that can be attached to a virtual machine. File storage exposes shared directories. Each form has different performance and access semantics.

Managed databases handle some maintenance such as patching, backups, or failover configuration. The application still needs an appropriate schema, access controls, connection limits, query performance, and data-retention policy. A database's location and network rules affect both security and latency.

Durability claims describe how likely stored data is to survive certain failures under provider assumptions. They do not replace application-level backup planning. Accidental deletion, malicious changes, or a software bug can be faithfully replicated to every copy.

Data transfer is part of the design

Moving large data sets into, out of, or between cloud services can take time and incur cost. Egress charges may apply to data leaving a provider's network. Keep computation near frequently used data when practical, and include export and migration plans for important systems.

Scaling and elasticity

Vertical scaling gives a resource more CPU or memory; horizontal scaling adds more instances. Elasticity is the ability to adjust capacity as demand changes. Autoscaling policies can add or remove instances based on measured load, but they need sensible thresholds and limits.

Scaling the web tier alone may not help if a single database is the bottleneck. A shared session store, network quota, or third-party API can also limit throughput. Measure the full request path and identify the bottleneck before scaling one component.

Autoscaling has delays: new instances take time to start, and a sudden traffic spike may arrive before capacity is ready. Set minimum capacity when cold starts are unacceptable, use queues for bursty work, and test load behavior before a major launch.

Capacity planning

Estimate normal and peak demand, then load-test representative requests. Include CPU, memory, storage throughput, network capacity, and database connection counts. Leave headroom for failure and growth, but review whether idle capacity is worth its recurring cost.

Reliability and operations

A cloud service can fail because of application defects, configuration mistakes, provider incidents, expired credentials, quotas, or network interruptions. Reliability means meeting user needs despite expected failure, not assuming components never fail.

1. Define user-visible service objectives and critical workflows.
2. Identify dependencies and failure domains.
3. Use health checks, timeouts, retries with limits, and graceful degradation.
4. Monitor availability, latency, errors, and resource saturation.
5. Back up important data and practice restoration.
6. Document incident response and test changes before broad rollout.

Cloud status dashboards describe provider incidents, but local configuration and application faults remain possible. Keep application logs and metrics that help distinguish provider problems from code, permissions, and capacity issues.

Infrastructure as code describes resources in version-controlled configuration. It can make environments repeatable and changes reviewable, but a mistaken configuration can be repeated just as easily. Review plans, restrict deployment permissions, and use separate environments for testing.

Security and shared responsibility

Cloud security follows a shared responsibility model. Providers secure facilities and underlying services; customers secure identities, data, application code, and configuration according to the product. The exact division depends on the service model and contract.

• Use multi-factor authentication and least-privilege roles.
• Keep storage private unless public access is explicitly required.
• Store secrets in an access-controlled secret manager, not source code.
• Encrypt sensitive data in transit and at rest with managed, reviewed controls.
• Log security-relevant changes and protect log access.
• Patch virtual machines, containers, application code, and dependencies you operate.

A public cloud account is still an organizational account that needs ownership, recovery contacts, billing controls, and auditability. Separate production access from ordinary development and use temporary, scoped credentials where supported.

Cost, portability, and lock-in

Cloud cost can include compute time, storage, requests, network transfer, managed-service tiers, support, and idle resources. Usage-based pricing lowers the barrier to starting, but a service left running continuously can cost more than expected. Set budgets and alerts, tag resources by project, and review actual usage.

Cost optimization should preserve reliability and security. Deleting backups or reducing redundancy without understanding the recovery requirement may save money while creating unacceptable risk. Measure the workload and compare total operating cost, not only the price of one resource.

Vendor lock-in is the cost or difficulty of moving to another platform. Provider-specific managed services can save substantial time, but may use unique APIs or data formats. Portability is one factor among many; abstracting every service in advance can add complexity. Document data export paths and assess migration risk for systems that must remain movable.

Compact glossary

Region

A geographic area containing cloud-provider infrastructure.

Availability zone

An isolated location within a region intended to reduce some shared-failure risks.

Elasticity

Adjusting capacity in response to changing demand.

Container

A packaged process environment that generally shares its host's kernel.

Infrastructure as code

Version-controlled configuration that describes infrastructure resources.

Egress

Data transferred out of a cloud provider or service boundary.

References and further reading

1. National Institute of Standards and Technology. The NIST Definition of Cloud Computing, SP 800-145. Publication.
2. Amazon Web Services. AWS Well-Architected Framework. Design guidance.
3. Google Cloud. Google Cloud Architecture Framework. Architecture guidance.
4. Microsoft Learn. Azure Well-Architected Framework. Design principles.

Try it yourself

1. Choose an IaaS, PaaS, or SaaS approach for a small photo-sharing site and explain what the team must operate.
2. Draw a simple multi-zone design and identify one failure it does not protect against.
3. List five cloud cost sources beyond compute instances.
4. Explain why replication does not replace backups.
5. Write a least-privilege rule for an application that only needs to read a specific storage bucket.

Remember: cloud platforms supply flexible infrastructure, but good outcomes still depend on thoughtful architecture, operations, security, and cost management.