Provisioning and Deployment
This chapter explains how workloads are provisioned and migrated into the cloud. You will learn to use templates and infrastructure as code, to size resources correctly, to design networks with subnets and CIDR blocks, and to choose the right migration strategy for an existing application.
Infrastructure as code and templates
Infrastructure as code (IaC) defines resources in declarative, version-controlled templates so that environments can be created identically and repeatedly. Because the definition is code, it can be reviewed, tested, and rolled back like any other software artifact, which reduces configuration drift and manual error. This is the foundation for reproducible, auditable deployments across development, test, and production.
Migration strategies
There are several common paths for moving workloads to the cloud, often called the R's. Rehosting (lift-and-shift) moves an application as-is for speed but gains few cloud-native benefits. Replatforming makes small optimizations, such as switching to a managed database, without a full redesign. Refactoring re-architects the application to take advantage of cloud services. Retiring removes workloads that are no longer needed, and retaining leaves some on-premises. Choosing among them balances effort, risk, and long-term value.
Networking and subnetting
Cloud networks are typically organized as virtual private clouds divided into subnets using CIDR notation, which defines the range of IP addresses available. Public subnets have a route to an internet gateway; private subnets do not, which is why database and application tiers that should not be reachable from the internet are placed in private subnets. Route tables, security groups, and network access control lists together determine what traffic is allowed.
Right-sizing resources
Capacity planning matches instance size to the workload's expected vCPU, memory, storage throughput, and network needs. Over-provisioning wastes money while under-provisioning harms performance. Teams estimate from baseline metrics, deploy, then observe utilization and adjust. Cloud elasticity means sizing decisions are not permanent, but a reasonable starting point avoids repeated disruptive changes.