A cloud is an IT environment built to provision scalable, metered IT resources remotely. Instead of buying servers, you rent compute, storage and networking from a provider and pay for what you use. That one change affects how a team plans capacity, spends money and reacts to change. This note covers why teams move to the cloud, what makes an environment a cloud, who does what, and the risks you accept.
Key terms#
A few words come up in every cloud discussion, so it helps to pin them down first.
- IT resource: anything physical or virtual that does IT work. A virtual server, a program, a physical server and a network switch are all IT resources.
- On-premises: a resource that runs in your own data center. It can call cloud resources, move to the cloud, or run as a redundant copy next to a cloud deployment.
- Scaling: the ability of a resource to handle more or less demand.
- Horizontal scaling (out and in): add or remove resources of the same type, such as more instances. This is the common form in the cloud.
- Vertical scaling (up and down): replace a resource with a bigger or smaller one. It often needs a restart, so it is less common in the cloud.
The load balancing note compares vertical and horizontal scaling in detail.
Why teams move to the cloud#
With the terms in place, start with the why. Three business problems push teams toward the cloud: capacity planning, cost and agility.
Capacity planning#
Capacity planning is the work of deciding how much IT capacity you need and when. Buy too much and you pay for idle hardware (over-provisioning). Buy too little and users see slow or failed requests (under-provisioning). There are three classic strategies.
| Strategy | When you add capacity | Risk |
|---|---|---|
| Lead | Before demand arrives | Paying for capacity you do not use yet |
| Lag | When the resource is already full | Users suffer until the new capacity arrives |
| Match | In small steps, as demand grows | Needs frequent, fast changes |
On-premises, every step means buying and installing hardware, which takes weeks. In the cloud, you can add capacity in minutes, so the match strategy becomes practical.
Cost#
Owning infrastructure has two costs: the purchase and the ongoing ownership. The ongoing part is often the larger share. It includes:
- Staff to keep the environment running.
- Upgrades and patches, each with its own test and deploy cycle.
- Power, cooling and data center space.
- Physical security and access control.
- Staff to track licenses and support contracts.
The cloud turns a large up-front capital expense into a pay-as-you-go operating expense. The provider spreads the ownership costs across many customers.
Organizational agility#
Organizational agility is how fast a business can respond to change. If a new product needs a month of hardware purchasing, the up-front cost alone can stop the idea. With cloud resources, a team can try an idea this week and delete the resources if it fails.
Goals and benefits#
Each benefit below traces back to one of those three problems.
- Lower up-front cost for hardware, software and ownership.
- Less or no need for your own data center, cooling, backup site and operations staff.
- On-demand, pay-as-you-go access to resources.
- Access to very large capacity, and to many kinds of resources (GPUs, managed databases, queues).
- Scaling in minutes instead of weeks.
- Higher availability and reliability, because the provider offers redundant infrastructure.
Cloud characteristics#
Renting servers from someone else isn't enough to call it a cloud. An environment needs a set of properties before it counts as one. The NIST definition lists five; textbooks often add resiliency as a sixth.
| Characteristic | What it means |
|---|---|
| On-demand usage | You provision resources yourself, when you need them, without asking the provider |
| Ubiquitous access | Services are reachable from many devices and networks, through browsers, apps and APIs |
| Multi-tenancy | Many tenants share the same pool of hardware, but each tenant is logically isolated |
| Elasticity | The system adds and removes resources automatically as demand changes |
| Measured usage | The provider meters use (compute hours, storage, bandwidth) and bills for it |
| Resiliency | The service keeps running through failures, using redundancy and failover |
Multi-tenancy and resource pooling#
Multi-tenancy works because of resource pooling, which puts compute, storage and bandwidth into a shared pool and gives each tenant a slice as needed. For example, tenant A uses 5 GB of an 8 GB storage device. Tenant B can use the remaining 3 GB. Neither tenant can read the other's data, because the isolation is logical, not physical.
On-demand usage vs elasticity#
These two are easy to confuse. The difference is who starts the change.
| On-demand usage | Elasticity | |
|---|---|---|
| Who starts it | You | The system |
| Example | You create a virtual machine when you need one | An auto scaling group adds machines when traffic grows |
| Purpose | Flexibility to get resources at any time | Matching resources to load without a person |
Resiliency: failover vs backup#
Resiliency uses redundancy, automated failover and backups. Teams often treat failover and backup as the same thing, but they solve different problems.
| Automated failover | Backup | |
|---|---|---|
| Purpose | Keep the service running when the primary fails | Restore data after loss or corruption |
| Speed | Seconds to minutes, automatic | Slower, usually needs a restore step |
| Data loss | Minimal | Back to the last backup |
| Cost | Needs a live standby | Needs only storage, so usually cheaper |
For example, Amazon RDS can take automatic backups and also run a standby copy in a second Availability Zone for failover. Amazon S3 Standard stores each object across several Availability Zones in one region. To survive a full region outage, you must replicate to a second region yourself. See Regions and Availability Zones.
Roles#
Now that you know what a cloud is, the next question is who does what. Several parties take part in any cloud setup, and one organization can hold more than one role.
| Role | Who | Responsible for |
|---|---|---|
| Cloud provider | AWS, Microsoft Azure, Google Cloud | Making services available as the SLA promises |
| Cloud consumer | A person or organization with a contract | Using the provider's resources |
| Cloud service owner | Whoever legally owns a service hosted in the cloud | Decisions about the service's design and operation |
| Cloud resource administrator | Consumer, provider or a third party | Day-to-day administration of cloud resources |
The last two roles are the easiest to mix up. The service owner and the resource administrator work closely, but their focus differs.
| Cloud service owner | Cloud resource administrator | |
|---|---|---|
| Focus | Business goals and service delivery | Technical operation of resources |
| Decides | SLAs, budget, architecture, provider choice | How to provision, monitor and secure |
| Typical job | CTO, product manager | Cloud engineer, system administrator |
| Example task | Choose AWS or Azure for a new service | Launch EC2 instances, set IAM roles, enforce backups |
Risks and obstacles#
The cloud trades some control for convenience. Know these risks before you move a workload.
- Reduced operational control. The provider runs the hardware and many services. You cannot tune every database or network parameter.
- Vendor lock-in. Over time, an application comes to depend on one provider's services. Moving to another provider, or back on-premises, gets expensive.
- Data confidentiality and compliance. Laws such as HIPAA (US health data) or data residency rules may limit where data can live. If a provider cannot meet them, you cannot use it for that workload.
- Outages you cannot fix. When the platform fails, you wait for the provider. SLAs usually give service credits, not compensation for lost business.
- Performance unpredictability. Shared hardware and networks can cause variable latency.
- Software licensing. Some licenses are tied to physical servers or core counts and do not map cleanly to virtual resources.
Of these risks, lock-in is the one your design choices control most. You reduce it by keeping the core logic portable: standard protocols, open formats, and a thin layer around provider-specific APIs. You do not need to avoid managed services; you need to know which ones would be hard to replace.
Key takeaways#
- The cloud replaces owning hardware with renting metered resources, which makes capacity planning, cost and agility easier.
- Lead, lag and match are the three capacity strategies. The cloud makes the match strategy practical.
- A cloud offers on-demand usage, ubiquitous access, multi-tenancy, elasticity, measured usage and resiliency.
- On-demand usage is started by you. Elasticity is started by the system.
- Provider, consumer, service owner and resource administrator are distinct roles.
- The main risks are reduced control, lock-in, compliance limits, provider outages and variable performance.