Infrastructure Depreciates. Architecture Compounds.

On 1 January 2025, two hyperscalers moved their server clocks in opposite directions. Meta extended the estimated useful life of most of its servers and network assets to 5.5 years. Amazon shortened the life of a subset of its servers and networking equipment from six years to five, citing "an increased pace of technology development, particularly in the area of artificial intelligence and machine learning" (Meta 10-K 2025; Amazon 10-K 2024).

The point is not who was right. It is that infrastructure depreciation runs on an estimate that the people closest to the hardware revisit, and that estimate now moves both ways. Our argument at Yottalyte — an editorial view, not a measured finding — is that hardware is a depreciating input, while architecture decisions outlive several hardware generations and decide what each refresh costs. That is what we mean by architecture compounds: it keeps paying, or keeps costing, long after the servers are written off. The counter-view is real, and we give it room below.

What is infrastructure depreciation, in engineering terms?

Infrastructure depreciation: the allocation of an asset's cost over its estimated useful life — the period over which management expects the asset to deliver economic value. For servers and network equipment, that life is a judgement reviewed at least annually and shaped by technical obsolescence, software efficiency and deployment plans. It is not a fixed physical lifespan.

What the filings say: the clock moved, then moved back

Between 2021 and 2025, the published server lives of the main US hyperscalers lengthened in steps.

• Alphabet extended servers from three to four years and certain network equipment from three to five years in 2021, then servers from four to six years and network equipment from five to six years in 2023 (Alphabet 2021 note; Alphabet 10-K 2022). It expected the 2023 change to cut that year's depreciation by about $3.4bn; the reported effect was $3.9bn lower depreciation and $3.0bn higher net income (Alphabet 2023 note).
• Microsoft extended the estimated useful lives of its server and network equipment in July 2020, then, after an assessment completed in July 2022, increased them from four years to six years, effective from fiscal year 2023. It attributed that change to "investments in software that increased efficiencies in how we operate our server and network equipment, as well as advances in technology" (Microsoft 10-K FY2022).
• Amazon extended servers from five to six years from 1 January 2024, reducing 2024 depreciation and amortisation by $3.2bn (Amazon 10-K 2024).
• Meta moved most servers and network assets from a disclosed range of four to five years to 5.5 years from 2025, lowering 2025 depreciation by $2.92bn (Meta 10-K 2024; Meta 10-K 2025).

Then came the first reversal. Amazon recorded about $920m of accelerated depreciation in the fourth quarter of 2024 for the early retirement of certain servers and networking equipment (Amazon 10-K 2024), and its shortening of a subset of equipment to five years increased 2025 depreciation and amortisation by $1.4bn (Amazon 10-K 2025).

As of each company's latest 10-K, Alphabet depreciates servers and network equipment generally over six years, Amazon over five to six years and Meta over five to 5.5 years (Alphabet 10-K 2025; Amazon 10-K 2025; Meta 10-K 2025). Microsoft discloses a range for its server and network equipment rather than a single figure (Microsoft 10-K FY2026).

An estimate, not a law of physics

The accounting framework expects this movement. IAS 16 requires the useful life of an asset to be reviewed at least at each financial year-end, with any change treated as a change in accounting estimate, and lists technical or commercial obsolescence among the factors that determine it (IAS 16). The US filers above describe their changes in the same "change in accounting estimate" terms. Alphabet's risk factors say changes in "historical asset performance, expected technology advancements, and future network deployment plans could change the period over which we expect to benefit from the asset" (Alphabet 10-K 2025).

We report these disclosures; we do not judge them. For engineering leaders, the useful reading is narrower: the economic life of a server fleet is a reviewed assumption, influenced by software efficiency on one side and accelerator cadence on the other.

Infrastructure is not becoming less important — it is becoming provider-scale

If anything, physical infrastructure matters more to the companies that own it. Each issuer's own cash-flow line, as of its latest 10-K:

• Alphabet — purchases of property and equipment of $32.3bn in 2023, $52.5bn in 2024 and $91.4bn in 2025. Its 10-K says it expects to "significantly increase" investment in technical infrastructure in 2026 relative to 2025 (Alphabet 10-K 2025).
• Amazon — purchases of property and equipment of $52.7bn, $83.0bn and $131.8bn in 2023, 2024 and 2025 respectively (Amazon 10-K 2025).
• Meta — purchases of property and equipment of $27.0bn, $37.3bn and $69.7bn; at the time of filing it anticipated 2026 capital expenditures of approximately $115bn to $135bn (Meta 10-K 2025).
• Microsoft — additions to property and equipment of $44.5bn in fiscal 2024, $64.6bn in fiscal 2025 and $115.9bn in fiscal 2026 (years ending 30 June) (Microsoft 10-K FY2026).

These are four different line items with different definitions and fiscal calendars, so they are presented per company and not combined or compared. What each series shows on its own is the direction: the infrastructure cycle is getting larger and faster for the providers. It is also bound by physical constraints. Microsoft's 10-K states that its datacentres depend on "the availability of permitted and buildable land, predictable energy" among other factors (Microsoft 10-K FY2026).

Different layers, different clocks

"Infrastructure" is not one asset. The latest 10-K policy notes put buildings on clocks measured in decades — Meta 25 to 30 years, Alphabet seven to 40 years for data-centre and office buildings, Amazon up to 40 years (Meta 10-K 2025; Alphabet 10-K 2025; Amazon 10-K 2025) — while servers and network equipment run on roughly five to six. Code is not exempt either: capitalised internal-use software is amortised on its own schedule, which Microsoft's 10-K discloses alongside its equipment lives (Microsoft 10-K FY2026).

So the durable thing is not "software" as opposed to "hardware". Specific code gets rewritten and written off too. What persists is the set of decisions that sit above any one asset: how services talk to each other, how data is modelled and governed, how environments are declared, who owns what. Those decisions have no accounting life at all, which is exactly why they are easy to underinvest in.

Responsibility is moving up the stack

For most enterprise buyers, the provider-scale cycle sits behind a service boundary. Microsoft's shared-responsibility matrix makes the boundary explicit: physical hosts, physical network and the physical datacentre move to the provider from infrastructure as a service onwards; the operating system moves at platform as a service. Customer data, configurations and settings, and identities and users remain the customer's responsibility in every model — "for all cloud deployment types, you own your data and identities" (Microsoft Learn).

Provider architecture guidance pushes the same way. AWS's Well-Architected principles include "Stop guessing your capacity needs", "Consider evolutionary architectures", using managed services and running operations as code, and "Stop spending money on undifferentiated heavy lifting" such as racking, stacking and powering servers (AWS general principles; operational excellence; cost optimisation). Google Cloud's framework lists "Design for change", "Simplify your design and use fully managed services" and "Decouple your architecture" among its core principles (Google Cloud Well-Architected Framework).

The important word is moves. Abstraction moves effort; it does not remove it. The responsibilities that never transfer — data, configuration, identity — are architectural.

Enterprises are investing in the abstraction layer

The investment shows up in the platform layer. DORA reports that by 2025, 90% of organisations in its research reported using an internal developer platform and 76% had established dedicated platform teams. DORA also cautions that platform adoption often follows a J-curve and can reduce throughput and change stability if not carefully managed (DORA). The CNCF's annual survey found 82% of container users running Kubernetes in production in 2025, up from 66% in 2023, from 628 respondents (CNCF Annual Cloud Native Survey).

The CNCF's platforms white paper describes the target as "the thinnest reasonable layer that provides consistency across provided implementations", relying on externally provided services as much as possible (CNCF Platforms White Paper). How to build such a platform is covered in our Insight on Platform Engineering Beyond Terraform and Kubernetes; here it is evidence of where enterprise effort is going.

The counter-view: when infrastructure is the strategy

An argument that only cites friendly evidence is not worth much. There are strong cases where infrastructure is the decision that matters.

Accelerator cadence. NVIDIA said in 2024 that new semiconductors "will arrive on a one-year rhythm" (NVIDIA). Amazon cited the pace of AI and machine-learning development when it shortened lives. Where workloads depend on current accelerators, refresh timing is a strategic variable.

The opposite bet. CoreWeave, a specialist GPU cloud, changed the useful life of its data-centre computing equipment from five to six years from 2023, citing hardware performance, software optimisation and data-centre design, and depreciates GPU-bearing technology equipment over six years (CoreWeave 10-K 2025). Two disclosed estimates point in different directions; both are bets on how long the hardware stays economic.

Steady load and ownership. 37signals, the company behind Basecamp and HEY, reports in its own unaudited account that moving compute to owned hardware cut its cloud bill from a $3.2m annual run rate to $1.3m in 2024, and projects more than $10m of savings over five years (37signals, self-reported). The same post concedes that "the cloud can still make a lot of sense", especially very early on or under large swings in load. Exit costs have also shifted: AWS announced free data transfer out to the internet for customers moving off AWS in March 2024, subject to conditions (AWS).

Power and land. At provider scale, the binding constraints are physical, as Microsoft's own risk language shows.

There is no universal winner. Infrastructure is decisive where scale, power, specialised accelerators or steady load dominate. For most enterprise buyers outside those conditions, we think the decisions that outlast the hardware deserve more attention than the hardware.

What "architecture compounds" means in practice

This section is our view. We have no metric for compounding and present none; the argument rests on the evidence above and on how refreshes play out in engineering practice.

Hardware is replaced on a schedule. The decisions around it are not. An interface contract, a data model, an identity design or an infrastructure-as-code module survives several refreshes, and each refresh is cheaper or dearer because of it. That is the compounding, and it runs in both directions. Clean contracts, declared environments and explicit ownership make the next instance family, accelerator generation or provider change routine. Workloads coupled to one machine shape, hand-built environments and unowned configuration make every refresh a project.

Architecture review questions

1. Could we change instance family, accelerator generation or region without changing application contracts?
2. Is the workload — applications, infrastructure, configuration and procedures — fully expressed as code?
3. Which data models and interfaces would survive a provider or hardware change, and which would not?
4. Who owns data, configuration and identity, the responsibilities that stay ours under every service model?
5. Are refresh-life assumptions in our business cases reviewed at least annually, as filers review theirs?
6. What would exit cost — data transfer, re-platforming, contracts — and is that written down?
7. Is our platform layer the thinnest that delivers consistency, or are we rebuilding managed services?

Frequently asked questions

Does a longer server useful life mean hardware physically lasts longer?

Not necessarily. Useful life is an accounting estimate of the period an asset delivers economic value, reviewed at least annually. Alphabet, Amazon, Meta and Microsoft each extended server lives between 2021 and 2025, and Amazon then shortened them for a subset of equipment, citing the pace of AI and machine-learning development.

Should enterprises repatriate workloads from the cloud?

It depends on load shape, team capability, existing facilities and exit costs. 37signals reports large savings from owned hardware for steady load, in a self-reported account that also says the cloud still makes sense for early-stage or highly variable workloads. Neither outcome generalises.

Is "architecture compounds" a measured effect?

No. It is Yottalyte's editorial argument, built on disclosed depreciation practice, the shared-responsibility model and provider architecture guidance. No figure in this article measures compounding.

What this is not

• Not investment or accounting advice, and not a judgement on any company's estimates.
• Not a cloud-versus-on-premises verdict.
• Not a platform-engineering how-to, nor a guide to AI commitments and reservations — for spend governance see GenAI FinOps as a capacity and commitment problem.
• Not a vendor ranking. Provider names illustrate public disclosures and documented guidance and reflect technology capability coverage, not formal partnerships.

Operational implications

Infrastructure depreciates on a schedule that its owners re-estimate. Architecture decisions have no schedule, and they keep paying or keep costing through every refresh. Treat refresh-life assumptions as reviewable inputs, keep data, configuration and identity under named ownership whatever the service model, and design interfaces and environments so that the next hardware generation is a change rather than a programme.

That work sits within Cloud, Platform & DevSecOps — architecture, infrastructure as code and platform foundations — with continuity through Managed Data, AI & Cloud Operations when refresh planning and operational ownership need to persist after handover. Prefer decisions that outlast the hardware over hardware choices that outlast their decisions.

References

Primary sources used for claims in this article; the 37signals account is a company-authored, self-reported counter-view. Inline citations in the body remain authoritative for the locus of each claim.

1. Alphabet Inc. — Form 10-K FY2021, accounting policies note — SEC EDGAR
2. Alphabet Inc. — Form 10-K FY2022 — SEC EDGAR
3. Alphabet Inc. — Form 10-K FY2023, accounting policies note — SEC EDGAR
4. Alphabet Inc. — Form 10-K FY2025 — SEC EDGAR
5. Amazon.com, Inc. — Form 10-K FY2024 — SEC EDGAR
6. Amazon.com, Inc. — Form 10-K FY2025 — SEC EDGAR
7. Meta Platforms, Inc. — Form 10-K FY2024 — SEC EDGAR
8. Meta Platforms, Inc. — Form 10-K FY2025 — SEC EDGAR
9. Microsoft Corporation — Form 10-K FY2022 — SEC EDGAR
10. Microsoft Corporation — Form 10-K FY2026 — SEC EDGAR
11. CoreWeave, Inc. — Form 10-K FY2025 — SEC EDGAR
12. IAS 16 Property, Plant and Equipment — IFRS Foundation
13. Shared responsibility in the cloud — Microsoft Learn
14. General design principles — AWS Well-Architected Framework
15. Operational excellence design principles — AWS Well-Architected Framework
16. Cost Optimization Pillar: design principles — AWS Well-Architected Framework
17. Google Cloud Well-Architected Framework — Google Cloud
18. CNCF Platforms White Paper — CNCF TAG App Delivery
19. Platform engineering — DORA
20. The CNCF Annual Cloud Native Survey — CNCF
21. "Accelerate Everything," NVIDIA CEO Says Ahead of COMPUTEX — NVIDIA
22. Our cloud-exit savings will now top ten million over five years — 37signals (self-reported)
23. Free data transfer out to internet when moving out of AWS — AWS News Blog