Cloud Computing Concepts

Cloud computing gives people access to computing resources over a network when they need them. Those resources include processing power, storage, databases, networks and complete applications. They come from a shared pool and can be made ready and returned quickly, with little interaction with provider staff.

From buying equipment to requesting capacity

A cloud provider supplies services; a customer or consumer uses them. AWS, Microsoft Azure and Google Cloud are major public cloud providers. To provision a resource means to make it ready to use. To deprovision it means to release it. A workload is the application or process, its data and the resources needed to run it.

In public cloud computing, the provider owns and maintains the physical equipment. Customers obtain the services they need and pay according to the service's pricing model. An organization can also run its own private cloud. Its departments still draw from a shared pool, and the system measures their use, even if no outside provider sends a bill.

Compare the ways to run a web shop

With on-premises IT, a company buys a server for its own building. Staff choose hardware, wait for delivery, install an operating system, connect the network and then install the shop. The company also handles power, cooling, repairs and eventual replacement. It has to plan capacity before sales reveal how much is needed.

With a cloud VM, an employee selects a size and location in a web console. The server can be ready within minutes. If the experiment ends after a month, the employee deletes the VM. Its compute charges end, but separately retained storage or other resources can still cost money.

Colocation moves the location of owned servers; it does not itself change how they are provisioned. Likewise, a rented server reached over the internet can be traditional hosting. Network access alone is only one part of the cloud model.

Three separate questions

The NIST definition separates the essential characteristics, service models and deployment models. The characteristics ask, “Does it operate as a cloud?” The service model asks, “Which layers does the provider manage?” The deployment model asks, “Who is the infrastructure for?” A private cloud can provide IaaS, and a public cloud can provide SaaS.

Cloud data has a physical home on storage equipment in data centers. Customers often choose a region, although they usually do not select an individual disk or host. “In the cloud” describes the delivery model, not data without a location.

NIST SP 800-145 describes five essential characteristics of cloud computing. Each answers a different practical question about obtaining and using resources. A service needs the whole combination; a large server pool or an online ordering page alone is insufficient.

The five characteristics

1. On-demand self-service: customers create resources themselves whenever needed. A developer can provision a 100 GB volume at 2 a.m. through a console or API without waiting for a provider employee. An API is an interface that lets software make requests to another system.
2. Broad network access: standard network mechanisms make services available to different devices. Staff might use the same service through a laptop browser, a phone app or software calling an HTTPS API. Access can still require authentication and a private network connection.
3. Resource pooling: the provider assigns and reassigns processing, memory, storage and network capacity among customers. Each customer is a tenant. Logical separation protects tenants while physical resources are shared. Customers can often choose a region without knowing the exact server involved.
4. Rapid elasticity: capacity can expand and contract quickly with demand. A video platform might use 4 servers normally, 40 for a live final and 4 afterward. Automation often performs these changes, but the definition also allows rapid changes initiated by a person.
5. Measured service: the system records use in suitable units, such as compute seconds, GB of storage or active accounts. Provider and customer can monitor, control and report consumption.

Apply the tests to two services

A company rents a dedicated server after filling in a sales form. Delivery takes three days and an upgrade needs a new contract. It pays 200 dollars each month. The wait rules out on-demand self-service, and the upgrade process lacks rapid elasticity. The dedicated equipment is not being drawn from a shared pool. These observations identify traditional hosting.

The fixed monthly fee does not settle the measurement question. The host could still record CPU time or network use. Metering and billing are different: a meter records consumption; a pricing rule turns some measure into a charge.

Now consider an email service. An administrator can add or remove mailboxes immediately, users connect from different devices, pooled infrastructure serves many organizations, capacity changes with account demand, and the service reports active users. This combination meets the five characteristics, even when its bill is a monthly subscription.

Recognize a partial match

An IT department may run many VMs while employees wait days for each request to be approved and created manually. Virtualization helps pooling, but this process lacks self-service. Adding a portal is useful only if automation, rapid provisioning and usage measurement support it.

A private cloud can use its meter for department reports or internal charges. Measured service therefore applies even without an external invoice. Elasticity also requires giving capacity back: keeping peak capacity permanently leaves resources idle after demand falls.

Virtualization creates software versions of physical computing resources. It allows one physical server to support several separate software computers. Cloud operators combine this with automation, self-service and usage measurement to make capacity available quickly.

Hosts, guests and hypervisors

A virtual machine (VM) has virtual processors, memory, disks and network interfaces. It runs its own guest operating system and applications. The physical computer underneath is the host. A hypervisor creates the VMs, allocates physical capacity and keeps each VM's memory and storage logically separate.

A VM image is a stored starting point for a virtual machine. Software can create a VM from that image without ordering a new physical server. Starting, resizing and deleting VMs supports rapid provisioning and elasticity. The virtualization system can track resource use, which supports metering. Some platforms also support live migration, moving a running VM between hosts so hardware maintenance causes little or no interruption.

Work through consolidation

Suppose 12 equally powerful physical servers each average 10% CPU use. Their combined average load is:

That is 1.2 servers' worth of processing. Moving the workloads into VMs on two equally powerful hosts gives an average per host of:

Ten physical machines can be removed, reducing power, cooling and maintenance. Before doing so, the team must also check peak CPU demand, memory, disks and network needs. The average calculation alone cannot establish that two hosts will handle every busy period or a host failure.

Sharing without sharing data

Multi-tenancy means several customers use shared infrastructure. Isolation keeps one tenant from accessing another tenant's VM memory or disks. Shared physical limits can still affect performance: one unusually busy tenant can compete for capacity, known as the noisy neighbor effect. Resource controls limit that effect. Dedicated hosts provide a whole physical server for customers whose requirements call for one.

Storage virtualization presents pooled disks as virtual volumes. Network virtualization provides separate software-defined networks over shared physical connections.

Containers package applications, libraries and settings while sharing an operating-system kernel. A VM has a complete guest operating system; a container does not. Containers usually start faster and use fewer resources, while VMs provide a stronger operating-system boundary and can run different guest systems. Containers often run inside VMs.

A cloud can also offer bare-metal servers through self-service. Virtualization is a major foundation, while the five service characteristics determine whether the overall offering is cloud computing.

A service model describes what the provider supplies and what the customer manages. Imagine the technology as layers: physical buildings and equipment, virtualization, operating system, middleware and runtime, application, and data. A runtime is the software environment that executes application code, such as Python or Java.

Compare the three standard models

With on-premises IT, the organization manages the entire stack. From IaaS through PaaS to SaaS, the provider takes on more work. The customer gains convenience and gives up some freedom to change the underlying system.

One blog, three ways to run it

An IaaS customer launches a Linux VM, installs the web server, database and blogging software, and maintains those layers. The provider still repairs the physical host and maintains the hypervisor. Guest OS patching belongs to the customer.

A PaaS customer deploys a blog application onto a supported platform. The provider supplies operating-system and runtime updates. The customer maintains the application and must follow the platform's update process. On AWS Elastic Beanstalk, managed patch and minor updates can be enabled; customers keep environments on supported versions and resolve failed updates. Turning managed updates off leaves them responsible for applying those updates.

A SaaS customer subscribes to a ready-made blogging application and starts writing. The provider runs the application, but the customer still controls who can publish and which content is shared.

Recognize common examples

Managed databases, such as Amazon RDS, Azure SQL Database and Google Cloud SQL, are generally treated as PaaS: the customer uses a database without maintaining the underlying server platform.

Classify the service, not the company selling it. One provider can offer all three models, and some products divide responsibilities in ways that sit between the classic categories. Read the duties for the specific offering when the name alone is unclear.

Narrower labels follow the same idea. DBaaS means database as a service; FaaS means function as a service; XaaS is a broad “anything as a service” label. Whatever the label, customer data and access decisions still need an owner.

Serverless means the customer uses code or a service without choosing, sizing or maintaining its servers. Servers still do the work. The provider manages infrastructure and scaling, and charges use service-specific meters.

Follow an event through a function

With function as a service (FaaS), the customer uploads a small unit of code. An event triggers a run: a web request, an uploaded file, a queued message or a schedule. For a photo service, the sequence is:

1. A customer uploads a photograph to storage.
2. The upload event starts a function.
3. The function makes and stores a thumbnail.
4. The run ends.

AWS Lambda, Azure Functions and Google Cloud Run functions are examples. Functions commonly scale to zero when idle and charge by requests and execution time. Serverless also includes services such as Amazon S3, Amazon DynamoDB and Google BigQuery. Stored data can continue to incur charges while no code runs. Function plans with always-ready capacity can also charge during quiet periods.

Calculate a function bill

Consider illustrative rates of $0.20 per million requests and $0.000017 per GB-second. Each of 3 million requests uses 0.5 GB of memory for 200 milliseconds, or 0.2 seconds.

First calculate total running time, then memory-time use:

Compute costs $5.10 and requests cost $0.60, giving $5.70. In this pricing example there is no minimum or idle compute charge. A VM at $0.05 per hour for 730 hours costs $36.50.

Each request costs $0.0000019 in the example. Dividing $36.50 by that amount gives about 19.2 million requests. Above that volume, the VM has a lower listed compute price, provided it can handle the work. Storage, network use and administration also matter to a full comparison.

Understand the operating limits

A cold start is the delay while the service prepares an execution environment. A function should be stateless: later runs must not depend on memory or local files from earlier runs. Put lasting data in a database or storage service.

Each offering has execution limits. Standard AWS Lambda invocations have a 15-minute maximum. Some Lambda Managed Instances invocation modes allow longer runs; the applicable service mode determines the limit. Long-running work must fit the chosen service's rules.

Serverless often fits uneven traffic, event processing, short scheduled work and automation. Constant heavy use can favor other compute options. A need for custom operating-system settings can also rule a function platform out. Provider-specific triggers and APIs can make a future move harder.

Serverless is often grouped with PaaS. Its managed infrastructure reduces server work, while the customer still secures code, permissions, configuration and data.

Start a service-model decision with the workload's requirements. A familiar technology can be a poor choice if it creates maintenance the team cannot support. A highly managed product can also be a poor choice if it removes control the application needs.

Ask what must be controlled

Use these questions in order:

1. Does a ready-made application meet the business need? Consider SaaS.
2. Is the team deploying its own application in a supported language without needing OS control? Consider PaaS.
3. Is the work short, event-triggered and uneven in volume? Consider serverless functions.
4. Must the team control the guest OS, install special software or move a server unchanged? Consider IaaS.

PaaS and serverless overlap. The useful choice is the specific service whose execution model, limits and supported tools fit the application.

Match requirements to models

For the older application, IaaS supplies control of a VM, not unrestricted control of the provider's physical hardware. Compatibility and support still need checking. For SaaS, confirm that its available features and settings meet the requirements before accepting the convenience.

Include operating effort in the cost

Suppose a VM costs $40 per month and needs four hours of administration at $50 per hour. Administration costs $200, so the total is $240. A suitable PaaS plan costs $90 with almost no administration in this example. Its higher service fee comes with a lower total cost.

The work comparison includes patching, monitoring, backups, application updates and the skills needed to respond when something fails. Moving more layers to the provider reduces some of these tasks but does not erase application or access management.

Combine models when the work differs

A business can use SaaS for customer relationship management, PaaS for its website, functions for processing new orders and one VM for an older component. Each service has its own management boundary.

Portability belongs in the decision too. VMs and containers can be relatively easy to move when their dependencies are portable. Managed platforms and function triggers may tie code to one provider. Vendor lock-in is the extra effort and cost that dependence creates.

A decision can change over time. Rehosting an application on a VM may be a useful first move, followed later by a platform migration. The reason for choosing IaaS should be a present requirement, such as OS control, rather than familiarity alone.

A deployment model describes the users for whom cloud infrastructure is provided. A service model describes the layers supplied. These are separate choices: an organization can obtain virtual machines through IaaS in either a public or private cloud.

Public cloud

Public cloud infrastructure is available for use by the general public. A provider owns and operates it in its data centers. AWS, Microsoft Azure and Google Cloud are examples; other providers include Oracle Cloud, IBM Cloud and Alibaba Cloud.

Customers share infrastructure and commonly access services over the internet, although private network access is also possible. They avoid buying physical equipment, can obtain large amounts of capacity quickly and can choose among locations around the world. They also depend on the provider's service choices and network connectivity, with less control of physical hardware.

“Public” describes who can become a customer. It does not mean that everyone can see every customer's data. Isolation and access controls separate resources. Making a storage container publicly readable is a configuration choice, not an unavoidable feature of public cloud.

Private cloud

A private cloud is reserved for one organization, possibly with many departments. The organization, a third party or both can operate it. It can be in the organization's building or hosted elsewhere.

Private cloud provides closer control of equipment, location and security configuration. That control can help with particular contractual or regulatory requirements. The operator must fund capacity and employ people to run it. Expansion is limited by the available hardware, so it has fewer economies of scale than a large public provider.

An on-premises server room counts as a private cloud only when it provides cloud characteristics, including self-service, pooling, rapid elasticity and measured use. Installing VMs alone leaves important parts of that service model missing. OpenStack is one example of software used to build private clouds.

Community cloud

A community cloud serves a specific group of organizations with shared concerns. They might share a mission, security policy or compliance requirements. Member organizations, a third party or a combination can operate it, on or off premises. Several hospitals could share infrastructure designed around their common health-data requirements.

A government-only offering may serve a community, but the actual eligibility and operating arrangement determine its classification. Location alone cannot identify a deployment model. A hosted private cloud stays private even though it sits in a supplier's building.

Organizations often keep some workloads local and run others in public clouds. The names hybrid cloud and multicloud describe different features of that arrangement. A business can have both at the same time.

Connect environments in a hybrid model

NIST defines hybrid cloud as distinct cloud infrastructures connected by technology that enables data or applications to move between them. The components remain separate. In everyday cloud discussions, including foundational provider exams, hybrid commonly means public cloud connected to private cloud or on-premises systems.

A secure link might be an encrypted VPN over the internet or a dedicated private connection. Shared identity and management tools can help staff operate the environments together. Azure Arc, AWS Outposts and Google Distributed Cloud support different forms of operating across locations; they are examples, not interchangeable products.

Hybrid can keep sensitive records, older software or equipment-control systems local while public cloud hosts a website or handles extra demand. It also supports migration in stages and remote backup or recovery arrangements. These benefits bring additional networking, security and management work.

Work through cloud bursting

A retailer's private cloud handles 2,000 orders per minute. During a sale, demand rises to 5,000. The public cloud handles the excess:

Its share of peak work is:

This is cloud bursting: extra capacity is used during peaks and released afterward. The application and data connections must support splitting that work. Simply subscribing to a second service does not make bursting happen.

Use several public providers

Multicloud means using services from two or more public cloud providers. A company might choose one provider's analytics and another's web hosting. The services can be used separately; multicloud does not require moving the same workload between them.

Possible reasons include choosing the best fit for each task, meeting location requirements, reducing dependence on one supplier or combining systems after a merger. Costs include multiple skill sets, security tools and data-transfer bills.

For a startup without a data center, public cloud can minimize initial equipment spending. An organization with an exclusive-infrastructure requirement may choose private cloud. A factory that needs very short local response times may keep machine control on site while using public cloud for analysis. The requirement for each workload leads the placement decision; using more environments increases the work needed to connect and govern them.

Cloud capacity can be adjusted as work changes. Scalability describes that ability to adjust. Elasticity adds rapid expansion and contraction so capacity closely follows demand. Both can reduce the need to buy equipment for the highest possible load.

Scale one machine or change the number of machines

Changing a VM from 2 to 8 vCPUs is vertical scaling. Changing from 2 web servers to 6 is horizontal scaling. A load balancer distributes incoming requests among copies. Additional copies can also provide redundancy, provided they are deployed to survive the relevant failures.

An auto scaling policy might add a VM after CPU use remains above 70% for five minutes and remove one when it stays below 30%. A minimum of two and maximum of ten keep the policy within a planned range. A single cloud VM does not adjust itself merely because it runs in a cloud. Some managed services handle scaling for the customer.

Calculate the capacity saved by elasticity

A ticket site needs 4 servers normally and 20 for 10 hours in a 730-hour month. Keeping 20 running all month uses:

With elastic capacity, first keep the normal four servers for the full month:

Then add only the 16 extra servers for the peak:

The total is 3,080 server-hours, about 21% of 14,600. Counting 20 extra servers during the peak would double-count the four baseline servers. Keeping only four permanently would avoid idle capacity but leave the peak unmet.

Provision quickly and reach users worldwide

Agility is the speed of obtaining resources, testing an idea and delivering a result. A team can rent 50 VMs for a two-hour analysis, using 100 VM-hours, then release them. It avoids waiting for 50 machines to be purchased and installed. Fast experiments make it less costly to reject an idea that fails.

Global reach means using provider locations around the world without building overseas data centers. Placing an application closer to users can reduce latency, the delay in communication. It still requires choosing a suitable location and meeting the workload's data requirements.

The provider's hardware work also frees staff time for products and services.

Availability is the share of a period when a service is up and usable. High availability uses redundant components to keep downtime low when something fails. Reliability also concerns continuing to work correctly and recovering from failures.

Turn a percentage into downtime

Use the unavailable share of the period:

A 30-day month has 43,200 minutes. At 99.95%, the unavailable share is 0.0005, so downtime is 21.6 minutes.

A service-level agreement (SLA) sets a provider's formal commitment and remedy. The remedy is often service credits, with eligibility conditions and exclusions, not compensation for all business losses. A service's SLA can depend on using multiple instances or locations. Free or preview offerings may have none.

Distinguish dependencies from redundant copies

If an application needs both its web tier and database, each can interrupt the application. In a simplified model with independent failures and comparable measurements, multiply their decimal availabilities:

That is about 99.94%, below either component. SLA commitments alone do not establish actual application uptime; shared dependencies and measurement rules also matter.

For two independent copies where either one is sufficient, both must fail to stop the service. If each is available 99% of the time, each has a 1% failure share:

Independence is crucial. Copies that both depend on the same failed power supply do not provide that protection.

Use the right protection and measure

Providers offer separate data centers called availability zones, multiple regions and managed replication. Copies in separate zones can protect against one data-center failure; a second region can protect against a wider regional incident. Designing and paying for suitable copies remains a customer decision.

Fault tolerance aims to continue without interruption after a component fails. High availability can allow a brief interruption. Disaster recovery restores service and data after a major incident. Backups protect data but do not keep a failed server serving requests while restoration takes place.

Predictability includes consistent performance and understandable cost. Scaling and load balancing help manage performance; usage reports, forecasts, budgets and alerts help manage spending. Higher availability usually needs extra resources, so the target should reflect the cost of downtime for the business.

Cloud providers bring security teams, physical controls and monitoring at a scale many organizations cannot build themselves. They also offer tools that help customers apply consistent rules. The benefit comes from using those tools and assigning the work clearly.

Use provider security and compliance evidence

Providers protect buildings, equipment and physical networks. They maintain their infrastructure and supply platform updates for managed services. Customers can use identity controls, encryption, firewalls, security monitoring and protection against distributed denial-of-service attacks, where many systems flood a service with traffic.

Providers also undergo audits against standards and frameworks such as ISO/IEC 27001 and SOC 2. Those reports provide evidence about the provider's controls. Customer access rules, data handling and service configuration still need to meet the organization's requirements. The provider's audit is one part of that evidence, not approval of every application running there.

Keep cloud use within organizational rules

Governance is the policies, processes and controls that align cloud use with business rules, legal duties and budgets. It includes much more than reducing bills.

For example, an organization can restrict VM creation to an approved set of regions. A policy rejects a request outside that set before the resource exists. Tags can identify the team responsible for a VM, while logs show who changed it. Each tool answers a different management question.

Manage resources consistently

Microsoft distinguishes management of the cloud, the capabilities used to operate resources, from management in the cloud, the methods people use to control them. The first includes automatic scaling, health checks, replacement of failed resources and alerts. The second includes a portal, command-line interface (CLI), APIs, software development kits (SDKs) and infrastructure as code.

Infrastructure as code (IaC) describes resources in files that deployment tools can read. A template for two web VMs, a load balancer and a database can create a matching test environment in minutes. The same resource description can be used again without remembering a sequence of manual clicks. Region-specific settings and other required values still need to be correct.

Automation can also schedule shutdowns, apply updates or take backups. Fewer repeated manual actions reduce opportunities for inconsistent settings and can lower operating costs. After a test, deleting its resources ends their resource-specific charges; retained backups, disks or other services remain billable. Keeping track of those remaining resources is part of managing the environment.

Cloud computing shifts much spending from buying assets to paying for services as they are used. Understanding the meters is the first step in reading a bill and comparing cloud with owned equipment.

Compare spending types

Capital expenditure (CapEx) buys assets used over several years, such as servers and storage equipment. Accounting spreads their cost through depreciation. Operational expenditure (OpEx) pays ongoing costs, such as electricity, subscriptions and cloud services, as expenses occur.

On-premises capacity costs are largely fixed: bought equipment, space and staff still cost money when machines are quiet. Consumption-based cloud charges vary with use. A commitment or per-user subscription can still create a fixed part of a cloud bill.

Pay-as-you-go lets customers obtain resources without a long-term usage commitment. Releasing a resource ends its own usage charges. Merely ceasing to use an allocated VM does not release it, and deleting a VM can leave separately billed disks or backups.

Read a bill one line at a time

Use a 730-hour month and illustrative rates. Two VMs run all month at $0.10 per hour. A third runs for 120 hours. Storage averages 500 GB at $0.02 per GB-month, and 200 GB leaves for the internet at $0.09 per GB.

• Baseline compute: two lots of 730 hours give 1,460 VM-hours, costing $146.
• Extra compute: 120 hours cost $12.
• Storage: 500 GB-month cost $10.
• Egress: 200 GB cost $18.

Add the separate charges:

The monthly total is $186. Egress is data leaving the cloud; ingress is data entering it. Many offerings make ingress free and charge for internet egress or transfers between regions. A media service that sends large files to users must include those outbound volumes in its estimate.

Compare total ownership cost

Total cost of ownership (TCO) compares all relevant costs over the same period. For owned IT, include equipment and replacement, software licenses, space, power, cooling, physical security, networking and staff time. For cloud, include compute, storage, transfers, licenses, administration and any migration costs relevant to the comparison.

Large providers gain economies of scale by buying and operating equipment in large volumes and sharing those costs among customers. Their lower unit costs can support attractive prices. An individual workload's saving still depends on utilization, suitable sizing and the plan it uses. Constantly running oversized resources can cost more than a well-used owned server.

Usage-based spending also needs oversight. Forgotten resources and unexpected scaling can raise a variable bill. Monitoring, forecasts, budgets and alerts help the team respond while the resources are still running.

Cloud pricing trades flexibility against commitments or interruption risk. Start with the workload's expected use, then choose terms that fit.

Match the main pricing options

AWS offers Reserved Instances and Savings Plans; Azure offers Reservations and savings plans; Google Cloud offers committed use discounts. Exact terms differ, but the central question is whether predictable use will cover the commitment.

Spot examples include AWS Spot Instances, Azure Spot Virtual Machines and Google Cloud Spot VMs. They suit jobs that can stop and resume, such as batch analysis or rendering. Notice can be very short: AWS provides best-effort two-minute notices for stop or terminate interruptions; hibernation can start immediately. Azure Spot notifications can arrive up to 30 seconds before eviction. A continuously needed checkout or database needs protection beyond an interruptible instance.

Calculate the break-even point

An illustrative VM costs $0.10 per hour on demand. A one-year commitment costs $0.06 for all 8,760 hours:

Divide that annual cost by the on-demand hourly rate:

That is 60% of the year. Above 5,256 hours, the commitment is cheaper under these rates. At nonstop use, on demand costs $876, so the saving is $350.40. At 2,080 office hours, on demand costs $208, below the full commitment. Applying the discounted rate only to the hours used would miss the contractual payment.

Reduce the need before discounting it

Right-sizing matches resources to measured demand. An 8-vCPU VM averaging 10% CPU use is a candidate for review. Before reducing it to 2 vCPUs, check representative peaks, memory, storage and network requirements. If the smaller size handles those demands and the price is proportional, compute cost falls to about one quarter. Buying a commitment first could lock in an oversized resource.

Scheduling matters too. A test environment running 10 hours on each of five weekdays uses 50 of a week's 168 hours. Releasing it outside those hours cuts compute time by about 70%.

Include software and other pricing terms

License-included prices contain the software license. Bring your own license (BYOL) uses existing licenses where their terms permit cloud use; Azure Hybrid Benefit is one example. Eligibility, tracking and any dedicated-hardware requirement still apply.

Other offerings use per-user subscriptions, volume tiers, trial credits or dedicated-host pricing. A practical mix can use commitments for the steady baseline, pay-as-you-go for uncertain demand and spot for recoverable batch work.

The shared responsibility model divides security, compliance and operating work between provider and customer. AWS calls the provider's part security “of” the cloud and the customer's part security “in” the cloud. The boundary changes with the service, but it never leaves customer data and access decisions without an owner.

Start with the physical layers

The provider protects and operates data center buildings, physical access, power, cooling, physical networks, hosts and virtualization. Customers rely on those controls and audit evidence. They do not patch the provider's hypervisor as part of ordinary IaaS use.

Customers decide how their data is classified, protected, retained and shared. They manage accounts, identities, access rights and customer-controlled service settings. They also protect the devices used to access services. A SaaS provider can supply device-management features while the organization remains responsible for managing its users' devices.

Locate the changing boundary

Platform maintenance has service-specific procedures. Some PaaS offerings require enabling managed updates, moving to a supported version or resolving failed updates. The customer must follow those procedures even though it does not operate a general-purpose server itself.

Assign three incidents

A company uses an IaaS website, a managed PaaS database and SaaS email. A guest OS vulnerability appears. The company patches its website VM; the provider maintains the operating systems underneath the managed database and email application, subject to the relevant update arrangements.

Next, an employee's password is stolen. The company must reset access, investigate permissions and strengthen account protection across all affected services. Moving to SaaS has not transferred its identity decisions to the provider.

Finally, customer files become readable to the public because the company enabled open sharing. The company must fix that setting and address the exposure. Physical data center security cannot prevent an authorized administrator from choosing an unsafe sharing rule.

Divide controls, not just labels

Some controls have a part on each side. Providers patch infrastructure; customers patch software they control. Each party configures its own layers and trains its own staff. Physical controls are inherited from the provider, while application settings remain with the customer.

Compliance follows the same division. A provider's certification covers its assessed controls. The customer needs evidence that its configuration, data handling and processes satisfy the requirements for its workload. The specific service's responsibility documentation and contract explain the detailed boundary.

Cloud adoption is a workload-by-workload decision. Elasticity, quick deployment and managed services can be valuable, but each benefit has to fit the organization's requirements. Name each risk precisely enough to choose a response.

Identify dependencies and control limits

Vendor lock-in occurs when proprietary APIs, services or data formats make changing suppliers slow or expensive. Exporting large amounts of data can also incur egress charges. Open formats, portable tools, containers and tested data exports can reduce switching effort. Each adds some cost or limits the features available, so portability is a choice to evaluate.

The provider controls its equipment, facility design and service lifecycle. Customers rely on contracts, documentation and independent audits for evidence about infrastructure. They also need a response when a service changes or is retired.

Check connections, location and response time

Cloud access depends on the network. An office connection failure can block staff from using a healthy cloud application. A distant region adds communication delay. Factory control that needs responses within milliseconds can remain local, while cloud services analyze the resulting data.

Data residency is where data is stored and processed. Data sovereignty concerns the laws and jurisdiction applying to it. Choosing a region addresses location, but contracts, access arrangements and legal requirements also matter. An organization may need an approved region, a suitable sovereign offering or local processing. No particular legal rule is assumed for every country.

Pair each risk with a practical response

A budget alert signals a threshold; it does not itself switch resources off. Scaling limits help constrain capacity, while a recovery plan addresses interruptions. These controls solve different problems.

Make a reasoned adoption decision

A 40-person law firm considers SaaS document management. Its expected benefits are remote access, less server work and provider security expertise. The firm checks that the storage location meets its requirements, documents can be exported in standard formats and all users can use multifactor authentication.

Those checks connect each concern to evidence: region and contract for residency, an export test for portability, and account controls for access. The firm can decide to move when the service meets those requirements. A different workload, such as a local machine-control system, can reasonably remain on premises.

Cloud operations also need people who understand security, costs and automation. Fast self-service makes new resources easy to create, so governance must make their owner, purpose and permitted settings clear.

A cloud migration moves applications, data or infrastructure from existing systems into a cloud. Begin with an inventory of applications, dependencies, use, costs and business value. Then choose a strategy for each workload. This portfolio approach avoids forcing every system through the same move.

Compare the seven strategies

AWS's 7 Rs are a useful vocabulary:

Google also uses terms such as “move and improve” for replatforming and “reimagine” for broader change. The action taken is more useful than memorizing a vendor's wording alone.

Separate easily confused moves

Rehosting leaves the application's code and core design unchanged. It can reduce the immediate effort of moving, but it retains many maintenance duties. Relocating moves a whole compatible virtualization environment and its operating approach, not just an application onto a newly chosen VM platform.

Replatforming changes a limited part of the environment. A managed version of the same database engine can remove server administration while preserving the application's core design. Repurchasing replaces the product itself. Replacing custom customer-management software with SaaS CRM is repurchasing, even though both products serve the same business purpose.

Refactoring changes the architecture to gain benefits such as independently scalable components. That can bring substantial long-term value, but the initial work may not pay off for a stable, low-value system. Retaining an application can be a deliberate decision pending a contract expiry, compatibility work or a later review.

Move the data and plan the switch

A low-downtime database migration can start by copying data into a new database, then replicating later changes while the original remains in use. The team checks that the destination has caught up before cutover, the agreed switch of users or traffic to the new system.

Replication reduces the amount of change left to transfer at cutover. It does not remove the need to check correctness, coordinate the final switch and plan for problems. For very large datasets, physical transfer devices can move the initial bulk data when network transfer is impractical.

Review dependencies before sequencing moves. An application that still needs a local database may require a connection or a coordinated migration. Rehosting can be a first step followed by optimization; a useful portfolio can include all of retire, retain, replace and redesign.