Sustainability Principles (SP1–SP7)

Every sustainability initiative that is not based on measurement data is at best ineffective — and at worst greenwashing. The question "How much CO₂ does this workload generate?" must be answerable before optimization measures are taken.

Cloud providers supply the necessary tools: AWS Customer Carbon Footprint Tool, Azure Emissions Impact Dashboard, GCP Carbon Footprint. These must be activated, queried regularly and integrated into ESG reports.

Energy efficiency and sustainability are structurally aligned. An optimized Lambda function that runs in 100ms instead of 500ms consumes 80% less energy. A Graviton instance that handles the same load as an x86 instance at 30% lower energy consumption is both cheaper and greener.

This means: Every performance optimization, every rightsizing measure, every idle elimination is also a sustainability measure — even if that is not the primary motivator.

Identical workloads have different CO₂ emissions depending on where and when they are executed. An identical batch job running in Stockholm (95% renewable energy) instead of Hong Kong (high coal intensity) can emit 60–80% less CO₂ — without any code changes.

Carbon-aware architecture means integrating location (region) and time (scheduling window) as sustainability parameters in architecture decisions.

Every stored byte consumes energy — more in the hot storage tier than in the cold tier, and more over time when no lifecycle rules exist. Every byte transferred over the network consumes network energy.

The principle of data minimization — originally from data protection (GDPR Art. 5) — is also a sustainability principle: Store only what you need, for as long as you need it, in the most efficient tier. And: transmit only the data that the recipient actually needs.

An EC2 instance running at 5% CPU utilization consumes almost the same energy as one under 80% load — but delivers only a fraction of the economic value. Over-provisioning is therefore a form of energy waste that arises from a lack of rightsizing governance.

The counter-model: Size resources so that actual utilization justifies the energy consumption. Autoscaling, serverless and spot instances are technical enablers of this principle.

Every software rewrite consumes significant engineering energy: building infrastructure, parallel development, migration compute, test runs. Software designed to be maintainable and extensible for 10 years is more sustainable than software that must be completely replaced after 3 years.

This principle also includes hardware: over-engineering that forces hardware upgrades is less sustainable than a design that runs efficiently on current infrastructure.

Technical debt is known deviations from the target state that are consciously tolerated. Sustainability debt is the equivalent for known CO₂-inefficient architecture decisions: x86 instances not yet migrated to Graviton for compatibility reasons; S3 buckets without lifecycle policies; batch jobs still running at peak times.

The crucial difference from technical debt: Sustainability debt is a governance risk under CSRD. If known inefficiencies are not documented and addressed, gaps arise in ESG reporting and missing evidence of active governance — both weaknesses in CSRD audits.