What the cloud is genuinely bad at
A good mechanic will occasionally tell you the repair costs more than the car. It is the sentence that earns every other sentence they say, because it proves the advice is about your problem and not their invoice. A cloud engineer needs the same sentence, and this class is where you learn to say it.
The previous two classes made the case for moving. They were true. But a case made only in one direction is a sales pitch, and the market is thick with people who will tell you every workload belongs in the cloud — usually people who are paid when it does. The professionals are the ones holding the list of exceptions, because the exceptions are where the expensive mistakes live.
Start with the misconception that funds most of those mistakes: that the cloud makes a system better. It does not. It changes where the system runs and how it is billed. A badly designed application, moved unchanged, becomes a badly designed application that now bills by the hour — and the failure of a "lift and shift" is almost always that the shifting happened and the lifting of the design did not.1
- Data gravity
- The tendency of a large dataset to pull applications and services toward wherever it already lives, because moving the data is slower and costlier than moving the code that uses it.
Data gravity is the single most underestimated force in a migration. It is easy to move a stateless web tier and feel that the project is going well. The database, the years of images, the analytics archive — those resist, and they resist in a way that shows up on an invoice rather than in an error log. Most of this class is really about the places data gravity, physics and the law each say slow down.
Egress: the bill nobody forecasts
Here is the asymmetry that catches out more first migrations than any other. Putting data into Azure is free and unlimited. Taking data back out — to the public internet, to your office, to another provider — is metered and charged. The door is free to enter and costs money to leave.
- Egress
- Data transferred out of the provider's network. Ingress (data in) is free; egress past a small monthly allowance is billed per gigabyte, and the rate rises the further the data has to travel.
The current numbers, for the regions Campux would use, look like this. Read the free rows as carefully as the priced ones — they are the reason small tests never reveal the problem.2
| Direction / volume | Charge |
|---|---|
| Inbound (ingress), any volume | Free |
| Outbound, first 100 GB per month | Free |
| Outbound, up to 10 TB / month | ≈ $0.087 per GB |
| Outbound, next 40 TB | ≈ $0.083 per GB |
| Outbound, next 100 TB | ≈ $0.07 per GB |
| Outbound, beyond 150 TB | ≈ $0.05 per GB |
Data enters free and pays to leave.
Put a number on it in Campux's world. Suppose the finance team refuses to move its reporting warehouse off-premises, so every night a five-terabyte extract is pulled from Azure down to the office. That is roughly 150 terabytes a month across the boundary; run it through the tiers in Table 1 and it bills around $11,000 a month, on the order of $135,000 a year — for a design choice that appears nowhere on the architecture diagram and produces not one new feature. The storage the data sits on costs a fraction of that. The movement is the expense.
This is why architecture that respects data gravity keeps computation next to the data instead of hauling the data to the computation, and why a plan that quietly assumes free data movement is not a cheaper plan — it is the same plan with a bill hidden in a footnote. When you review a migration design, the first question worth asking is always: what crosses the boundary, how often, and in which direction?
Latency, and the one law you cannot appeal
Light travels about three hundred kilometres in a millisecond — closer to two hundred in the glass fibre a network actually runs through, and the reply must make the same trip back — and no datacentre, no SLA and no amount of money changes that. When a workload must respond faster than the round trip to the nearest region allows, the cloud is not slow because it is badly built — it is slow because the region is four hundred kilometres away and physics is charging you for the distance.
Most web applications never notice; a hundred milliseconds is invisible to someone browsing a storefront. But the exceptions are real and worth recognising on sight: industrial control loops that must react in single-digit milliseconds, high-frequency trading, live audio processing, a factory robot that cannot pause to consult a server in another country. These belong at the edge or on the premises, close to the thing they control, and the correct engineering answer is to say so rather than to promise a latency the map forbids.
Campux has a smaller version of this. When the storefront had its nine-hour outage in Class One, the in-store point-of-sale tills kept taking card payments, because they were designed to work whether or not a distant server was reachable. That property — degrading locally rather than failing globally — is one you keep deliberately, and it is a reason some of the store systems will stay partly on-premises long after the website is entirely in Azure.
Compliance, residency and custody
The third place the answer is "not like that" is not technical at all. Some data is bound by law or contract to live in a particular country, to stay under a particular custody, or to never sit on hardware shared with anyone else. These constraints do not care how elegant your architecture is.
- Data residency
- A requirement that data be stored, and sometimes processed, within a defined geography — a country or economic region — to satisfy a law, a regulator, or a contract.
The cloud has real answers here: Azure offers regions in dozens of countries, lets you pin resources to a chosen geography, and operates sovereign and government clouds for the strictest cases. But every one of those answers is something you must choose and configure on purpose. Nothing about the cloud keeps regulated data in-country by default; a resource created in the wrong region is a compliance incident that no amount of encryption undoes. The obligation to know where the data physically rests sits squarely above the line you drew in Class One — it is yours.
Notice the pattern across §2 to §4: the hard limits are money, physics and law, in that order of how often you will meet them. You will argue about egress every month, about latency occasionally, and about residency rarely but with a lawyer in the room. None of the three is a reason to distrust the cloud. Each is a reason to design for it deliberately.
When workloads move back
Repatriation — moving a workload out of the cloud and back onto owned hardware — is the word the marketing never uses and the honest engineer keeps ready. It is not an admission of failure; it is what happens when a workload's shape stops matching the model. The candidate is nearly always the same: something large, steady and predictable, running hot around the clock with no peak to amortise and no idle trough to save on.
That is the mirror image of Campux's storefront. The store site has a sharp November peak and a dead January — the exact profile consumption pricing rewards. A workload that runs flat at ninety percent every hour of every day gets none of that benefit and pays the cloud's convenience premium on every one of those hours. For a few companies at a certain scale, buying the hardware back is simply the cheaper arithmetic, and a few have said so publicly.3
The one system you do not migrate yet
Leadership, encouraged by Class Two's numbers, wants everything in Azure by year-end. You find the exception hiding in the back office: the point-of-sale batch job that reconciles every store's takings overnight. It runs on an ageing server, and it depends on a third-party licence tied to that specific physical machine — move it to a cloud VM and the licence, as written, is void until renegotiated. It is also steady, nocturnal and predictable, with none of the peaky shape that makes the cloud pay.
So the recommendation writes itself, and it is a "no, not yet": leave the POS batch job where it is for now. The licensing constraint is a contract problem to be solved before it is a technical one, and the workload's flat profile means there is no cost prize for rushing. You will bridge to it with a hybrid connection during the migration in Class Five, plan its proper home in Class Four, and revisit its shape once the licence is renegotiated.
Saying "not this one, not this way, not this quarter" — and being right — is worth more to Campux than migrating one more box. It is the sentence the mechanic taught you at the top of the class.
The person who says "not this, not yet"
An eager lead proposes lifting a latency-critical box and a decade-old licensed appliance straight to Azure. You are the one who says "not this, not yet." You separate what the cloud makes better from what it makes worse or merely more expensive, and hand back the migration list with two items crossed off and a reason beside each. Knowing when not to is the judgment that gets you trusted with the yes.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B. Ingress is free and unlimited; egress is free only for the first 100 GB a month and metered per gigabyte after that. D is the belief that quietly sinks a budget — engineers who assume symmetry design systems that haul data out constantly and are stunned by the bill. The asymmetry is not a detail; it is the shape of the whole cost model, and it is why "we'll just query it from on-prem" is rarely as free as it sounds.
C. Residency is a legal constraint on where data lives, and it sits above the line from Class One — yours to satisfy. The trap is A: the cloud offers in-country regions, but choosing one is a deliberate act, and a resource spun up in the wrong region is a compliance breach no default prevents. Confuse "the provider has a region there" with "the provider keeps my data there for me," and you have promised a regulator something you never configured.
Flat high utilisation, hard latency needs, and a licensing or legal binding. Those are reasons rooted in money, physics and law — the three real limits of this class. The other two are postures, not arguments: a preference for owning things and a suspicion of what competitors do are how workloads end up in the wrong place for reasons no invoice or regulator will ever respect. Campux's POS batch job trips two of the three genuine reasons at once.
MEMORANDUM — Analytics migration plan
1. Move the reporting compute to Azure; it autoscales for month-end.
2. Keep raw data in Azure Blob Storage — ingress is free, storage is cheap.
3. The on-prem BI tool queries that blob data across the internet each night.
4. Since ingress is free and storage is cheap, this adds no meaningful
data-transfer cost.
Line four. Lines one and two are sound, and line three describes a real design — but that design is exactly what makes line four false. Every nightly query pulls data out of Azure, and outbound is egress, billed per gigabyte after the free 100 GB. Ingress being free is a red herring; the traffic here runs the other way.
Consider the consequence. A terabyte pulled nightly is about 30 TB a month of egress — a four-figure monthly charge that appears in no line of this plan, discovered only when the invoice arrives. The author priced the direction that was free and never looked at the one that was not. Reading a plan for what crosses the boundary, and which way, is the skill this drill is training.
The tell is the word "everything." No competent engineer makes an absolute claim about a portfolio they have not read. The account director is paid on consumption; "all of it, this year" is their invoice speaking, and leadership can feel it even if they cannot name it. Your value is being the person in the room whose incentive is Campux's, not the vendor's.
Agree with the direction, refuse the absolutism. Most of Campux's estate genuinely should move, and the storefront's shape makes the case emphatic. Say that clearly — you are not the anti-cloud voice. Then name the exceptions on their merits: the POS batch job's licence, anything bound by residency, anything that must answer faster than the region can.
Close on method, not opinion. Offer to score each workload against three questions — what does it cost to move data in and out, how fast must it respond, and what law or licence binds it — and migrate in that order. That reply makes you the trustworthy one precisely because it is the one the vendor cannot give.
Lead with the constraint that has a lawyer attached. The batch job's third-party licence is tied to that physical machine; moving it to a cloud VM voids the licence as written until it is renegotiated. That is not an engineering preference, it is a contract — start there, because it ends the "just get rid of it" framing immediately.
Then show there is no prize for rushing. The job runs flat and nocturnal, with none of the peaky shape that makes the cloud cheaper. Migrating it today would spend real effort and legal cost to move a workload that would not save a cent by moving — the opposite of the storefront's case in Class Two.
End with a plan, not a refusal. Make it "not yet, and here's the path": renegotiate the licence, bridge to the job over a hybrid connection during the wider migration, and revisit once the contract is clean. "No" with a dated route forward is leadership hearing diligence; "no" on its own is leadership hearing reluctance.
Five things worth carrying out of this class
- The cloud changes where a system runs and how it bills — it does not make a bad system good. Lift the design, not just the server.
- Data enters free and pays to leave. Egress, not storage, is the cost that ambushes a migration that ignored it.
- Latency is physics. Some workloads must live near the thing they control, and no SLA overrules the speed of light.
- Residency is law, and it is yours to configure. The cloud offers in-country regions; it does not choose them for you.
- "Not this one, not yet" — argued on money, physics or law — is a professional answer, and often the valuable one.
- "Lift and shift" — rehosting a workload onto cloud infrastructure with minimal change — is a legitimate first step when the goal is to exit a datacentre quickly. The mistake is treating it as the destination rather than the on-ramp; the savings and the resilience come from the redesign that is supposed to follow, and too often does not. ↩
- Bandwidth prices change, vary by region, and carry exceptions — notably, providers now waive egress fees for customers moving their data out of the cloud entirely, under regulations such as the EU Data Act. Treat the specific per-gigabyte figures here as illustrative of Zone 1 rates at the time of writing, and the asymmetry between free ingress and metered egress as the settled point. Always price against the current bandwidth pricing page before you commit a number. ↩
- A handful of companies have published repatriation cases in which a large, steady workload proved cheaper on owned hardware. Read them as existence proofs, not as a trend — for most organisations, and for almost everything Campux runs, the direction of travel is still toward the cloud. The lesson is that the decision is per-workload arithmetic, not ideology. ↩