Situation and constraints
Northstar Tools runs its customer portal, inventory system, and reporting database in a small server room at its main office. The hardware is approaching the end of its support period. The company now has two choices:
- buy servers, storage, network equipment, licenses, and support contracts for another refresh cycle; or
- move suitable workloads to AWS and pay for cloud resources as the company uses them.
The decision looks like a simple price comparison, but it is not. Northstar must plan for seasonal demand, decide how much spare capacity to buy, account for power and cooling, understand application dependencies, train its staff, and keep the business running during any migration.
The learner decision is therefore:
Should Northstar commit capital to another fixed on-premises footprint, or adopt AWS for the workloads where variable capacity, faster change, and reduced infrastructure ownership create better business value?
This is not a request to design the target architecture. At Cloud Practitioner depth, the goal is to understand the business and migration reasoning that comes before an architect chooses subnets, instance types, or database configurations.
The decision to make
The weakest approach is to compare only this year's server invoice with one month's AWS estimate. An honest decision compares the full consequences of both operating models.
For another on-premises refresh, Northstar must estimate:
- hardware bought before demand is known;
- data-center space, power, cooling, physical security, and network capacity;
- software licenses and maintenance contracts;
- staff time for procurement, installation, patching, replacement, and capacity planning;
- spare capacity held for growth and failure; and
- the risk of owning too much or too little capacity for several years.
For AWS, Northstar must estimate:
- the compute, storage, and data transfer it expects to consume;
- temporary migration and parallel-running costs;
- support, software, and licensing choices;
- training and organizational change; and
- the governance needed to prevent unused resources from accumulating.
Cloud value is broader than “the monthly bill is lower.” Faster experimentation, shorter procurement cycles, global reach, access to managed capabilities, elasticity, and the ability to stop paying for some unused resources can all matter. AWS does not guarantee that every workload will be cheaper, and moving an unchanged, oversized system to the cloud can preserve waste in a new location.
A practical cloud mental model
Think of on-premises capacity as owning a bus and cloud capacity as purchasing transport when it is needed.
Owning the bus can be sensible when demand is predictable and consistently high. But the owner pays for the vehicle even when most seats are empty, maintains it, and must buy another bus before demand grows. Paying per trip turns much of that commitment into a variable expense, although careless or constant use can still become expensive.
The cloud model changes three related decisions.
Fixed expense becomes variable expense
A fixed expense is committed before actual usage is known. Buying servers for the next three to five years is the classic example. Northstar pays for the capacity even during quiet periods.
A variable expense changes with consumption. Many AWS services let Northstar pay for the resources it uses without purchasing the underlying data-center hardware. This improves financial flexibility, but it does not remove the need for cost management. Resources that run unnecessarily still generate charges.
The important comparison is not capital expense versus “free infrastructure.” It is a large up-front commitment and ownership burden versus metered consumption with continuing governance.
Elasticity follows demand
Elasticity is the ability to add resources when demand rises and remove them when demand falls. If Northstar's portal becomes busy during a seasonal sale, an elastic environment can grow for the peak and shrink afterward.
On premises, the company normally buys enough hardware for expected peaks. That capacity may sit idle for most of the year. In AWS, access to capacity on demand can reduce the need to provision years ahead.
Elasticity is not a promise that every application scales automatically. The workload and services must support scaling, and the company must configure the relevant behavior. At this level, remember the business effect: capacity can more closely follow demand instead of being permanently sized for the highest forecast.
Economies of scale change the provider's cost base
AWS serves demand across many customers. That aggregate scale gives the provider purchasing and operating efficiencies that a single company usually cannot reproduce in one server room. AWS can spread facilities, hardware, networking, and operational expertise across a very large customer base.
This is the economies of scale idea behind lower variable expense. It does not mean that every AWS configuration is automatically economical. Northstar still has to rightsize resources, remove waste, and choose appropriate pricing options. Economies of scale explain a provider advantage; they do not replace customer discipline.
Compare the options without hiding the tradeoffs
| Question | Refresh on premises | Move suitable workloads to AWS |
|---|---|---|
| When is capacity paid for? | Largely before it is used | As services are consumed, subject to the chosen pricing model |
| How is peak demand handled? | Buy enough capacity in advance | Add and remove capacity where the workload supports elasticity |
| Who owns the physical infrastructure? | Northstar | AWS operates the cloud infrastructure; Northstar still has responsibilities for what it runs and configures |
| How quickly can a team try something? | Procurement and installation may delay work | Resources can often be provisioned in minutes |
| What creates waste? | Idle purchased capacity and long refresh cycles | Idle or oversized cloud resources, unnecessary data transfer, and weak cost controls |
| What must change beyond technology? | Existing operating model may continue | Skills, governance, security, finance, and operations must adapt |
The sensible conclusion is not “cloud always wins.” Northstar should compare workloads, business outcomes, risk, timing, and total cost. Some systems may move now, some may be modernized later, and some may remain where they are for valid technical, regulatory, or economic reasons.
Migration is a business program, not a copy command
Before moving anything, Northstar needs an inventory. A server list alone is not enough: applications depend on databases, file shares, identity systems, scheduled jobs, network connections, licenses, owners, and recovery procedures.
A useful migration sequence is:
understand the business goal
-> discover workloads and dependencies
-> assess readiness and cost
-> choose a strategy for each workload
-> migrate in manageable waves
-> validate outcomes and improve
Common migration strategies include:
- Rehost: move a workload with minimal change. This is often called “lift and shift.”
- Replatform: make a limited change that reduces operational work without redesigning the entire application.
- Refactor: change the application more substantially to use a different architecture or cloud-native capabilities.
- Repurchase: replace the current application with another product, often a software-as-a-service offering.
- Relocate: move a compatible environment with little change to its workload configuration.
- Retain: keep a workload where it is for now.
- Retire: remove a workload that no longer provides value.
These are choices, not a maturity ranking. A deadline may make rehosting appropriate today, while a later project modernizes the workload. Database replication is another migration concept in the CLF-C02 guide: copying existing data first and then continuing to apply changes can reduce the gap before cutover. The scenario does not require knowing a detailed replication design.
For an architecture-level treatment of migration waves, cutover, and specialized transfer services, use Arcflow's On-Premises Migration To AWS scenario as an optional deeper reference. That SAA-oriented detail is not required to understand this Cloud Practitioner lesson.
Use AWS CAF before treating migration as an IT-only project
The AWS Cloud Adoption Framework (AWS CAF) helps an organization evaluate cloud readiness and build an evolving transformation roadmap. It prevents Northstar from asking only, “Can the engineers move the servers?”
AWS CAF groups readiness into six perspectives:
- Business: Which measurable outcomes justify the change?
- People: Do teams have the skills, roles, leadership, and change support they need?
- Governance: How will priorities, risk, benefits, data, and cloud finances be managed?
- Platform: How will the cloud environment and reusable technology capabilities be prepared?
- Security: How will identity, data, threats, vulnerabilities, and incidents be handled?
- Operations: How will the company monitor, support, change, and recover workloads?
Northstar could discover that the technical move is possible but the finance team cannot allocate cloud costs, the operations team lacks new runbooks, or the security team has not agreed on controls. AWS CAF makes those organizational gaps visible early.
The framework describes an iterative journey: Envision the outcomes, Align people and capabilities, Launch useful pilots, and Scale what proves valuable. This reinforces an important migration idea: the company can learn through smaller waves instead of betting the entire business on one large move.
AWS CAF is not a migration tool, a service that copies data, or the same thing as the AWS Well-Architected Framework. AWS CAF helps the organization prepare for and govern cloud adoption. Well-Architected helps evaluate design and operational decisions for workloads.
Put cost estimates in the right place
Northstar needs an estimate before it can compare options. AWS Pricing Calculator is a planning tool for modeling AWS service costs before resources are deployed. It can help the company document assumptions about compute, storage, and data transfer.
An estimate is not the same as an actual bill. After workloads run, tools such as AWS Cost Explorer help analyze historical cost and usage, while AWS Budgets can monitor spending or usage against thresholds. This distinction connects the scenario to CLF-C02 task statement 4.2 without turning the lesson into a detailed billing tutorial.
The comparison should also avoid two common mistakes:
- excluding on-premises facilities, labor, maintenance, and unused capacity from the current-state cost; and
- assuming a calculator estimate includes every future usage pattern, tax, support choice, or operational mistake.
The estimate supports a decision. It does not eliminate uncertainty.
Where the manifest services fit
The scenario manifest names two migration and transfer services. Their conceptual boundaries are more important than their console steps.
AWS Application Discovery Service collects configuration and usage information about on-premises servers and databases to support migration planning. Discovery helps answer “what do we have, how is it used, and what depends on what?” It does not move the workloads by itself.
AWS Migration Hub provides a central place to discover existing servers, group resources into applications, plan migration work, and track application migration status. It is a visibility and coordination layer rather than a universal data-copy engine. See Arcflow's shared AWS Migration Hub reference for the service boundary.
The decision sequence is:
discovery data -> application understanding -> migration plan -> progress tracking
Do not reverse it into “Migration Hub moves every workload” or “Application Discovery Service performs the migration.”
Common exam confusion
This Arcflow scenario is not an official AWS exam question. It is a learning situation designed around the published CLF-C02 task statements.
Watch for these distinctions:
- Elasticity is not merely buying a bigger server. It is matching resources more closely to changing demand, including reducing them when demand falls.
- Variable expense is not automatically low expense. Pay-as-you-go resources still cost money while they run.
- Economies of scale are a provider advantage, not a guarantee about one workload's bill.
- Migration is not always all-or-nothing. Retaining, retiring, rehosting, or replatforming different workloads can all be rational.
- AWS CAF is organizational adoption guidance. It covers business, people, governance, platform, security, and operations—not just infrastructure.
- AWS Pricing Calculator is for estimates. Cost Explorer is for analyzing cost and usage after it exists; Budgets monitors against thresholds.
- Discovery and tracking are not migration engines. Application Discovery Service informs planning, and Migration Hub organizes visibility.
Recall prompts
Answer these without looking back:
- Why can a server refresh create waste before the new hardware is even installed?
- What is the difference between variable expense and elasticity?
- Why do AWS economies of scale not guarantee that Northstar's cloud bill will be lower?
- Which AWS CAF perspectives would reveal a skills gap, an unclear cost-ownership model, and missing operational runbooks?
- What is the difference between Application Discovery Service and Migration Hub?
- When should Northstar use AWS Pricing Calculator rather than Cost Explorer?
Check your reasoning
- The company must buy capacity before actual demand is known and normally sizes for growth, peaks, and failure, so some purchased capacity may remain idle.
- Variable expense describes how cost changes with consumption; elasticity describes how capacity can grow and shrink with demand.
- Provider-scale efficiencies can lower the underlying variable cost, but poor rightsizing, idle resources, and unsuitable workload choices can still produce a high bill.
- People, Governance, and Operations, respectively.
- Application Discovery Service gathers workload and dependency data for planning; Migration Hub groups, plans, and tracks migration progress. Neither is a universal workload-moving engine.
- Use Pricing Calculator to model expected AWS costs before deployment; use Cost Explorer to analyze actual cost and usage after resources are running.
Summary
Northstar should compare operating models, not just invoices. An on-premises refresh commits money and capacity in advance; AWS can replace part of that fixed commitment with variable consumption, let capacity follow demand, and expose provider economies of scale. Those benefits are real, but they require rightsizing and cost governance.
A responsible move begins with discovery, readiness, cost assumptions, and a workload-by-workload migration strategy. AWS CAF broadens the plan across business, people, governance, platform, security, and operations. Migration Hub and Application Discovery Service explain the discovery and tracking concepts in the current exam scope, with the important current caveat that new AWS customers are directed to AWS Transform.
Official references: CLF-C02 Domain 1, CLF-C02 Domain 4, AWS pricing principles, AWS Cloud Adoption Framework, AWS Migration Hub availability, and AWS Application Discovery Service availability.