Cloud Platforms, Networking, and Environment Operations

Introduction

Cloud computing has changed DevOps from a practice concerned mainly with build servers and deployment scripts into a discipline responsible for the complete operational life cycle of software. A modern DevOps engineer must select suitable cloud services, design secure networks, manage identities, automate environments, control costs, and prepare for failure. Cloud platforms provide elastic resources, but they do not remove architectural responsibility. Poorly designed cloud systems can be insecure, expensive, difficult to operate, or vulnerable to extended outages.

This chapter examines public, private, hybrid, and multi-cloud models and then develops the operational foundations required for cloud-based applications: compute, storage, identity and access management, networking, DNS, load balancing, environment separation, backup, disaster recovery, and cost governance.

Learning Objectives

After studying this chapter, you should be able to:

1. Compare public, private, hybrid, and multi-cloud deployment models.
2. Select appropriate compute and storage services for application requirements.
3. Explain identity, networking, DNS, and load-balancing designs.
4. Design development, testing, staging, and production environments.
5. Distinguish backup, high availability, business continuity, and disaster recovery.
6. Apply RTO, RPO, capacity, and cost reasoning to cloud decisions.
7. Evaluate governance, security, sustainability, and operational risks.

1. Cloud Service and Deployment Models

Cloud computing is the on-demand provision of configurable computing resources, commonly delivered over a network and measured according to use. Three service models are especially important:

The shared-responsibility model is fundamental. A provider may secure the physical data centre, while the customer remains responsible for identity permissions, application vulnerabilities, data classification, and correct network configuration. The exact boundary varies by service; a managed database generally transfers more operational responsibility than a virtual machine, but it does not eliminate customer accountability.

Deployment models

Public cloud uses infrastructure operated by a cloud provider and shared among customers through logical isolation. It offers rapid provisioning, broad geographic reach, and elastic capacity. Concerns include provider dependence, data-residency requirements, variable billing, and configuration errors.

Private cloud dedicates infrastructure to one organization, either on its premises or hosted by a third party. It can support strict control and legacy workloads, but requires substantial investment in hardware, operations, capacity planning, and specialist skills.

Hybrid cloud combines private and public environments connected by controlled networking and identity mechanisms. It may support gradual migration, regulatory separation, or burst capacity. However, integration, latency, inconsistent tooling, and complex security boundaries make hybrid systems difficult to operate.

Multi-cloud uses services from two or more public providers. It can reduce dependence on one provider or exploit specialized services, but portability is often overstated. Different identity systems, networking models, APIs, pricing structures, and monitoring tools increase operational complexity.

A sound selection evaluates security, compliance, latency, availability, skills, portability, total cost, and the organization’s ability to operate the resulting architecture. “Cloud” is not automatically cheaper or more reliable than a well-managed data centre.

2. Compute and Storage Foundations

Compute choices

Cloud compute commonly appears in four forms:

• Virtual machines (VMs): flexible servers on which the customer manages the operating system. They suit legacy software, custom kernels, and applications requiring strong host control.
• Containers: isolated processes packaged with their dependencies. They improve consistency and portability, although the host, image supply chain, orchestration, and runtime still require management.
• Managed container platforms: services that schedule containers, perform health checks, and support scaling without requiring the team to operate every cluster component.
• Functions or serverless compute: event-driven execution in which the provider manages servers. Functions are useful for short-lived, asynchronous tasks, but may involve startup latency, execution limits, and platform-specific APIs.

Compute selection should consider workload duration, statefulness, startup time, scaling pattern, operating-system requirements, observability, and operational skills. Stateless services are particularly suitable for horizontal scaling: adding more instances rather than continuously enlarging one instance.

Storage choices

Object storage stores data as objects in buckets or containers. It is highly suitable for images, backups, logs, data lakes, and static web assets. It normally provides an API rather than a traditional mounted file system.

Block storage presents volumes to a VM. It supports operating-system disks and databases requiring low-latency random access, but performance, durability, and backup policies must be considered separately.

File storage provides shared hierarchical files and is useful when applications require common file semantics. It can introduce throughput, locking, and scaling constraints.

Storage design must address durability, availability, encryption, retention, lifecycle transitions, deletion protection, access logging, and recovery testing. Replication is not automatically backup: accidental deletion or corruption can be replicated to every copy.

3. Identity, Access, and Secrets

Identity and Access Management (IAM) determines who or what may perform which action on which resource. A useful policy model is:

Principal → action → resource → condition

For example, a deployment identity may be allowed to update a particular application service only from an approved pipeline. The principle of least privilege grants the minimum permissions needed for a defined task and duration.

Human users should normally authenticate through centralized identity, multifactor authentication, and role-based access. Workloads should use managed identities or short-lived credentials rather than embedded passwords. Administrative access should be separated from ordinary access, logged, reviewed, and preferably protected by just-in-time elevation.

Secrets such as database passwords, API keys, and certificates should be held in a managed secrets service or encrypted vault. They should not be committed to source control, placed in container images, or printed in logs. Rotation must be automated where possible, and applications should tolerate credential replacement.

IAM errors are among the most common causes of cloud incidents. Broad permissions, public storage, unused accounts, and unclear ownership are governance failures as well as technical failures. Policy-as-code and automated security checks can detect many violations before deployment.

4. Cloud Networking

A cloud network is a logical structure containing address ranges, subnets, routes, gateways, security controls, and service endpoints. A typical design separates public-facing components from private application and data components.

Figure: A layered network that limits direct access to application and data resources.

Addressing and routing

An IP address identifies a network interface within an address space. CIDR notation expresses a network prefix and prefix length, such as 192.168.10.0/24. Under IPv4, the number of addresses in a CIDR block is:

Here, N is the total number of IPv4 addresses and p is the prefix length, with 0 ≤ p ≤ 32. For a /24 network, N = 2^(32−24) = 256 addresses. Cloud platforms reserve some addresses for infrastructure, so usable addresses may be fewer. CIDR calculations should therefore be treated as address-space calculations, not guaranteed instance capacity.

Subnets should be planned for growth and failure-domain distribution. Routes determine where packets go; security groups or equivalent stateful controls regulate traffic at the resource interface, while network ACLs or firewalls may provide subnet-level filtering. A secure design uses deny-by-default inbound rules, narrowly defined source ranges, and explicit egress control where required.

Private resources can reach approved external services through a managed egress gateway or proxy without accepting unsolicited inbound connections. Private endpoints can keep traffic to cloud services on provider networks and reduce exposure to the public Internet.

DNS and service discovery

The Domain Name System maps names to records such as A, AAAA, CNAME, MX, and TXT. A record maps a name to an IPv4 address; AAAA maps it to IPv6. DNS supports human-friendly addressing, traffic steering, failover, and service discovery.

The time-to-live (TTL) tells resolvers how long a record may be cached. A lower TTL can accelerate changes but increases DNS query traffic; a higher TTL reduces queries but slows propagation of changes. DNS is not an instant switch, and caches, application behavior, and provider-specific mechanisms affect change time.

Internal DNS should use private zones and stable service names. Applications should not hard-code ephemeral instance addresses. Health-aware DNS can assist failover, but it should not replace application-level resilience or load-balancer health checks.

Load balancing

A load balancer distributes requests among healthy targets. Layer 4 balancing operates using transport-level information such as TCP, while Layer 7 balancing can inspect HTTP properties such as host names, paths, and headers. Common functions include TLS termination, health checks, path routing, connection draining, and rate limiting.

A health check must test meaningful service readiness, not merely whether a process is running. Sessions should ideally be stateless; if session state is necessary, it should be stored in a shared data service rather than tied permanently to one instance. Load balancing improves availability only when the targets, dependencies, zones, and deployment process are also resilient.

5. Environment Operations and Infrastructure as Code

A responsible delivery system separates environments according to risk and purpose:

• Development: rapid experimentation and local integration.
• Test or integration: automated validation of components and interfaces.
• Staging: production-like validation, performance testing, and release rehearsal.
• Production: controlled service delivery with formal monitoring and change procedures.

The strongest isolation usually uses separate accounts, subscriptions, or projects, not merely different names in one shared account. Production access should be more restricted, and production data should not be copied into lower environments without masking, minimization, and approval.

Infrastructure as Code (IaC) describes networks, identities, compute, policies, and services in version-controlled files. A typical workflow is plan, review, validate, apply, and verify. State must be protected because it may contain resource identifiers or sensitive information. Changes should be repeatable, peer-reviewed, auditable, and reversible.

Configuration drift occurs when deployed resources differ from their declared configuration. Drift detection, immutable images, automated reconciliation, and prohibition of unmanaged manual changes reduce this risk. Environment-specific values should be injected through secure configuration rather than copied into source files.

Observability combines logs, metrics, traces, and meaningful alerts. Operational teams should define service-level indicators, such as request latency or successful transaction rate, and service-level objectives that express acceptable performance. Alerts should identify actionable conditions rather than generate noise.

6. Availability, Backup, and Disaster Recovery

Availability is the ability of a service to perform its function when requested. High availability reduces expected interruption through redundancy and rapid detection. Business continuity includes organizational processes for continuing critical operations. Disaster recovery (DR) restores technology services after major disruption.

Two essential recovery objectives are:

• Recovery Point Objective (RPO): maximum acceptable amount of data loss, measured in time. An RPO of 15 minutes means the organization can tolerate losing up to approximately 15 minutes of updates.
• Recovery Time Objective (RTO): maximum acceptable time to restore service after disruption.

A backup is a recoverable copy maintained according to a retention policy. Good backup design uses appropriate frequency, encryption, access control, geographic or fault-domain separation, immutable or protected copies, and regular restoration tests. A backup that has never been restored is an assumption, not evidence of recoverability.

Recovery strategies range from restore-from-backup, through pilot light and warm standby, to active-active operation. More rapid recovery generally requires more continuously running capacity and therefore greater cost and operational complexity. Recovery must include dependencies such as DNS, identity, keys, images, network configuration, and external integrations.

A simple availability model illustrates redundancy. If independent components must all be available for a service to function, the service availability is:

where A_i is the availability of component i and independence is assumed. If a service depends on two sequential components each with availability 0.99, A_system = 0.99 × 0.99 = 0.9801, or 98.01%. For redundant parallel components, the probability that at least one of two independent components is available is:

These formulas are simplified models. Real systems have correlated failures, maintenance windows, shared dependencies, and imperfect detection, so measured service performance is more reliable than naive multiplication.

7. Cost-Aware Cloud Operations

Cloud cost is an engineering concern because architectural choices determine resource consumption. Cost drivers include compute hours, storage volume, storage operations, data transfer, managed service tiers, database capacity, logs, snapshots, and reserved or committed-use contracts.

A practical cost-management cycle is:

1. Measure: collect billing, utilization, and ownership data.
2. Allocate: apply tags, labels, accounts, or cost centres.
3. Optimize: right-size, schedule non-production resources, use lifecycle policies, and remove waste.
4. Govern: set budgets, alerts, quotas, and approval thresholds.
5. Review: evaluate cost against reliability, performance, and business value.

Rightsizing must not simply reduce capacity without examining peak demand, latency, resilience, and recovery requirements. Spot or interruptible capacity can reduce cost for fault-tolerant batch work but is unsuitable for workloads that cannot tolerate interruption. Data-transfer charges can make a multi-region or multi-cloud design considerably more expensive than expected.

FinOps extends cost control into a collaborative practice involving engineering, finance, and product teams. The correct question is not “What is the cheapest resource?” but “What level of business value and reliability is produced for the cost?”

Illustrative Case: Online Examination Platform

Background

A university plans an online examination platform used heavily during scheduled examination windows. It must support unpredictable peaks, protect student records, and recover from infrastructure failure.

Problem

An initial design places the web application, database, and uploaded answer files on one virtual machine. It uses a public IP address, a shared administrator account, and nightly backups. This design creates a single point of failure, weak access control, poor scalability, and an RPO that may be too large during an examination.

Analysis

The workload has a predictable baseline but sharp peaks. Uploaded files are large and need durable storage, whereas examination transactions require transactional database behavior. Students require public access, but the database should not be public. Academic records require restricted access, retention rules, encryption, and auditability.

Approach

The redesigned architecture uses a public load balancer and multiple stateless application instances across availability zones. A managed relational database resides in a private subnet with automated backups and a tested standby or failover arrangement. Object storage holds encrypted answer files with lifecycle and retention policies. A managed identity service supports multifactor authentication for staff and separate student access policies. Internal DNS provides stable service names; monitoring tracks login success, submission latency, error rate, database health, and storage access.

Infrastructure is declared using IaC. Development, staging, and production use separate accounts or projects. Synthetic load tests are performed before examination periods, and a runbook documents database restoration, DNS changes, communication responsibilities, and escalation paths. Budgets and alerts detect unexpected scaling or data-transfer costs.

Outcome

The revised design removes the principal single points of failure, permits horizontal scaling, reduces direct exposure of sensitive systems, and makes recovery measurable. It costs more than the original single-machine design, but the additional cost is justified by examination continuity, confidentiality, and reduced operational risk.

Learning points

Cloud architecture should begin with workload requirements rather than a preferred product. Availability, security, cost, and operability must be evaluated together. Backups, failover, and IaC provide value only when tested and governed.

8. Governance, Ethics, and Contemporary Practice

Cloud operations involve personal data, financial records, educational information, and potentially sensitive infrastructure details. Teams must follow applicable privacy, cybersecurity, records-retention, and data-residency requirements. Data minimization, purpose limitation, encryption, access review, and auditable processing are important controls.

Automation can accidentally amplify errors. A flawed IaC change may expose thousands of resources; an automated deletion policy may destroy evidence or backups. Therefore, dangerous operations need approval gates, policy checks, protected branches, least privilege, and tested rollback procedures.

AI-assisted operations can summarize logs, identify anomalies, recommend capacity changes, or generate configuration. Such tools can improve triage but may hallucinate causes, expose confidential data, or produce unsafe changes. Human review, provenance, access controls, evaluation datasets, and staged execution are essential. AI should support—not replace—engineering accountability.

Contemporary cloud practice increasingly emphasizes platform engineering, internal developer platforms, policy-as-code, confidential computing, zero-trust access, software supply-chain security, and sustainability. These developments reinforce a central principle: operational quality is designed into systems through automation, measurement, and responsible governance.

Best-Practice Checklist

• Choose a cloud model based on requirements, risk, and total cost.
• Apply least privilege and use short-lived workload identities.
• Keep databases and management interfaces off the public Internet.
• Design for failure across zones or equivalent fault domains.
• Use stable DNS names and meaningful health checks.
• Separate environments and protect production access.
• Manage infrastructure and policy through version-controlled automation.
• Encrypt data, protect secrets, and test key rotation.
• Define RTO and RPO with business owners.
• Test restoration and disaster-recovery procedures regularly.
• Monitor reliability, security, performance, and cost together.
• Treat cloud configuration as code subject to review and audit.

Chapter Summary

Cloud platforms provide flexible infrastructure, but responsibility for architecture, security, governance, and operations remains shared between provider and customer. Public, private, hybrid, and multi-cloud models offer different balances of control, flexibility, complexity, and cost. Compute services range from virtual machines to managed platforms and event-driven functions; storage may be object, block, or file based, each with distinct operational properties.

Secure cloud operations depend on least-privilege IAM, protected secrets, segmented networks, private data services, reliable DNS, and properly designed load balancing. Environment separation, IaC, observability, and controlled change reduce operational risk. Backup and disaster recovery must be designed around RPO, RTO, dependency mapping, and restoration tests. Finally, cost management is a continuous engineering and governance practice rather than a one-time purchasing decision.

Key Terms

Cloud computing: On-demand delivery of computing resources over a network.

IaaS: Cloud delivery of virtualized infrastructure resources.

PaaS: Managed platform for deploying applications without managing the underlying infrastructure.

Public cloud: Provider-operated infrastructure shared by multiple customers through logical isolation.

Private cloud: Cloud infrastructure dedicated to one organization.

Hybrid cloud: Integrated use of private and public cloud environments.

Multi-cloud: Use of services from multiple public cloud providers.

IAM: Identity and Access Management; controls governing principals, actions, resources, and conditions.

Least privilege: Granting only the access necessary for a task.

Object storage: Storage of data as addressable objects in buckets or containers.

CIDR: Notation describing an IP network prefix and prefix length.

Subnet: A subdivided network address range.

DNS: Domain Name System, which maps names to network-related records.

Load balancer: A service that distributes traffic among targets.

Infrastructure as Code: Declarative or programmatic management of infrastructure through version-controlled definitions.

RPO: Maximum tolerable amount of data loss expressed as time.

RTO: Maximum acceptable time to restore service.

Observability: The ability to understand system state through logs, metrics, traces, and related signals.

FinOps: Collaborative financial management of cloud consumption and value.

Configuration drift: Difference between declared and deployed configuration.

Review Questions

Short Answer Questions

1. What is the difference between public cloud and private cloud?
2. Why should application and database resources normally be placed in different network tiers?
3. Define RPO and RTO.
4. Why is replication not necessarily a backup?
5. What is the principle of least privilege?

Long Answer Questions

1. Compare public, private, hybrid, and multi-cloud models, including their benefits and limitations.
2. Explain how IAM, secrets management, network segmentation, and observability contribute to secure cloud operations.
3. Describe a complete environment strategy for development, testing, staging, and production.
4. Compare virtual machines, containers, managed platforms, and serverless functions for DevOps workloads.
5. Explain how an organization should design, test, and govern a disaster-recovery plan.

Analytical / Application Questions

1. A service depends sequentially on a load balancer with availability 0.999 and a database with availability 0.995. Using the independent-component model, calculate the combined availability and explain why the estimate may differ from real performance.
2. Design a network for a public web application with private application servers and a private database. Specify subnets, routes, DNS, security controls, and load-balancing behavior.
3. An organization wants to reduce cloud cost by deleting all non-production resources every evening. Analyze the benefits, risks, and a safer automated alternative.

Multiple Choice Questions with Answers

Question 1

Which cloud model combines public-cloud services with infrastructure dedicated to one organization?

A. Private cloud

B. Hybrid cloud

C. SaaS

D. Community networking

Correct Answer: B. Hybrid cloud

Question 2

Which storage type is most appropriate for durable storage of images and backup objects accessed through APIs?

A. Object storage

B. CPU cache

C. Block register

D. DNS storage

Correct Answer: A. Object storage

Question 3

What does the principle of least privilege require?

A. All users receive administrator access

B. Permissions are granted only as needed for a defined task

C. Passwords are shared within a team

D. Resources are made publicly accessible

Correct Answer: B. Permissions are granted only as needed for a defined task

Question 4

Which component normally distributes requests among healthy application instances?

A. Load balancer

B. Secret vault

C. Object lifecycle rule

D. Source-code branch

Correct Answer: A. Load balancer

Question 5

For an IPv4 CIDR block with prefix /24, how many total addresses are represented?

A. 24

B. 128

C. 256

D. 512

Correct Answer: C. 256

Question 6

What does an RPO of 15 minutes specify?

A. The maximum acceptable service restoration time is 15 minutes

B. The maximum acceptable data loss is approximately 15 minutes of updates

C. The system must run for 15 minutes before backup

D. The backup must be retained for 15 minutes

Correct Answer: B. The maximum acceptable data loss is approximately 15 minutes of updates

Question 7

Which practice best reduces configuration drift?

A. Allowing undocumented manual changes

B. Using version-controlled Infrastructure as Code and drift detection

C. Disabling monitoring

D. Copying production credentials into test systems

Correct Answer: B. Using version-controlled Infrastructure as Code and drift detection

Question 8

Why should a database usually be placed in a private subnet?

A. To allow unrestricted Internet access

B. To reduce direct exposure and restrict inbound paths

C. To eliminate the need for backups

D. To make DNS unnecessary

Correct Answer: B. To reduce direct exposure and restrict inbound paths

Question 9

If two independent sequential components each have availability 0.99, what is the simplified combined availability?

A. 0.0199

B. 0.99

C. 0.9999

D. 0.9801

Correct Answer: D. 0.9801

Question 10

Which is a sound cloud cost-management practice?

A. Ignoring data-transfer charges

B. Removing all monitoring to save money

C. Applying ownership tags, budgets, utilization review, and lifecycle policies

D. Always selecting the largest instance type

Correct Answer: C. Applying ownership tags, budgets, utilization review, and lifecycle policies