WAF++ WAF++
Back to WAF++ Homepage

Design Principles for Sustainable Architecture (SD1–SD8)

The eight technical design principles translate the Sustainability Principles (SP1–SP7) into concrete architecture requirements and decisions. Each design principle is linked to specific WAF-SUS controls and shows practical implications for cloud architectures.

SD1 – Prefer ARM/Graviton

Tagline: 30–40% better energy efficiency without loss of functionality.

Technical Background

ARM-based processors (AWS Graviton2/3, Azure Ampere Altra, GCP T2A) achieve significantly better performance-per-watt ratios compared to equivalent x86 processors due to their RISC architecture. At AWS, Graviton3 (m7g, c7g, r7g) is 25% more energy-efficient than Graviton2.

Instance Family x86 Equivalent Energy Efficiency

m7g (Graviton3)

m6i (Ice Lake)

~40% better performance/watt

c7g (Graviton3)

c6i

~35% better CPU performance/watt

r7g (Graviton3)

r6i

~40% better for memory workloads

t4g (Graviton2)

t3

~20% better for burst workloads

Lambda arm64 (Graviton2)

Lambda x86_64

~20% less energy per invocation

Application Rule

New deployments: ARM/Graviton as default; x86 only with documented exception (e.g. x86-only binaries). Brownfield: Priority on Lambda (simplest migration), then container workloads, then EC2.

Related Controls

SD2 – Use Managed Serverless for Bursty Workloads

Tagline: No idle compute through scale-to-zero.

Technical Background

Serverless compute (AWS Lambda, Azure Functions, GCP Cloud Functions/Run) differs from container-based compute through the scale-to-zero principle: when no requests arrive, no resources run — no energy is consumed.

For workloads with strong burst profiles (APIs with day/night rhythm, event triggers, webhook handlers), serverless is the more energy-efficient choice compared to always-on containers or EC2 instances.

When Serverless, When Containers?

Characteristic Serverless (Lambda/Functions) preferred Container/EC2 preferred

Traffic profile

Burst, irregular, event-driven

Consistently high, predictable

Latency requirement

< 100ms cold start acceptable

Sub-10ms consistently required

Runtime

Short (< 15 minutes)

Long-running (background worker)

Energy

Pay-per-use; zero idle

Idle energy at low utilization

Related Controls

SD3 – Time-Shift Batch Workloads to Low-Carbon Windows

Tagline: Same load — 20–60% less CO₂ through the right timing.

Technical Background

The carbon intensity of the electricity grid varies considerably depending on time of day and season:

  • Solar: Peaks at midday, falls to zero at night → higher intensity in early morning/evening without solar

  • Wind: Variable, but statistically stronger at night in many regions

  • Base load: Coal/gas often has a higher proportional share at night in coal-dependent regions

The Green Software Foundation calls this temporal shifting: shifting batch jobs to the time window with the lowest carbon intensity.

Implementation Options

Method Description Tool

Fixed Off-Peak Scheduling

Jobs shifted to 22:00–06:00 UTC; statistically lower

EventBridge, Cron, Cloud Scheduler

Flexible Windows

EventBridge Flexible Time Window ±2h around target time

aws_scheduler_schedule.flexible_time_window

Dynamic Carbon Scheduling

Real-time carbon intensity API determines execution time

electricityMaps API, WattTime API

Related Controls

SD4 – Cache Aggressively to Reduce Compute Cycles

Tagline: A cached response is the most energy-efficient response.

Technical Background

Caching is the most effective measure for reducing compute energy per delivered response. A CDN hit for a static page consumes a fraction of the energy of an origin hit that triggers database queries, application server compute and network egress.

Cache Levels and Sustainability Impact

Cache Level Implementation Sustainability Impact

CDN (Edge)

CloudFront, Azure CDN, Cloud CDN

Eliminates long-haul network + origin compute for cached content

Application Cache

Redis/Elasticache, Memcached

Eliminates repeated DB queries; 10–100x energy reduction per cache hit

Query Result Cache

DB query cache, materialized views

Heavy aggregations computed only once

Browser Cache

Cache-Control headers (max-age, ETag)

Client-side; eliminates network request entirely

Related Controls

SD5 – Minimize Data Transfer

Tagline: Every byte transfers energy — transmit as little as possible.

Technical Background

Network energy arises proportional to data volume: switch energy, router energy, undersea cable energy, last-mile energy. Cross-region transfers consume more energy than same-region transfers (more network hops, greater distance).

Concrete Measures

  • HTTP compression: gzip/brotli reduces text payloads by 70–90%

  • VPC endpoints: AWS service traffic stays within the AWS backbone; no internet gateway

  • Same-region co-location: Databases and application servers in the same AZ

  • Field filtering: GraphQL, OData $select, sparse fieldsets; only transmit requested fields

  • Binary protocols: Protocol Buffers, MessagePack instead of JSON for internal services (20–50% smaller)

Related Controls

SD6 – Store Only What You Need

Tagline: Storage lifecycle policies are sustainability controls.

Technical Background

Data storage consumes energy proportional to volume and tier: hot storage (S3 Standard, Premium SSD) consumes more energy per GB than cold storage (Glacier, Archive, Cool Tier). Infinite retention in hot storage tiers is therefore continuous energy waste.

Lifecycle Strategy

Data Category Lifecycle Rule WAF-SUS Reference

Operational logs

90 days Standard → delete; or 90d Standard → 365d Glacier → delete

WAF-SUS-050

Business data

30d Standard → 90d IA → 365d Glacier → expire per policy

WAF-SUS-050

Audit/CSRD data

365d Standard → Glacier → 7 years (CSRD obligation) → delete

WAF-SUS-090

Temporary data (build artifacts, caches)

7–30 days → auto-delete

WAF-SUS-050

Backups

Generation-based (e.g. 7 daily, 4 weekly, 12 monthly) → auto-expire

WAF-SUS-050

Related Controls

SD7 – Optimize Algorithms Before Scaling Hardware

Tagline: An efficient algorithm is greener than more hardware.

Technical Background

Algorithmic complexity has a direct impact on energy consumption. An algorithm with O(n²) complexity running on 10,000 elements performs 100 million operations — an O(n log n) algorithm only ~133,000. This factor of 750 directly translates into CPU time and energy consumption.

Practical Optimization Levers

Pattern Sustainability Impact

Eliminate N+1 queries

100 DB queries to 1 bulk query → 99% database energy reduction for this code path

Pagination instead of full table scans

Transfer and process only the first 20 rows instead of 10,000

Indexes for frequent queries

Index hit instead of full table scan → 100–1000x faster, proportionally less energy

Batch processing

100 items in one Lambda invocation instead of 100 separate invocations → 99% less cold-start energy

Lazy loading

Load data only when needed; do not eagerly load all associations upfront (ORM eagerness)

Related Controls

SD8 – Choose Regions by Carbon Intensity, Not Just Latency

Tagline: Green energy is an architecture parameter — not a luxury.

Technical Background

Regions differ considerably in their carbon intensity (gCO₂eq/kWh):

Region (AWS) Location Renewable Energy (approx.) CO₂ Intensity

eu-north-1

Stockholm, Sweden

~95% (hydro/wind)

Very low

eu-west-1

Dublin, Ireland

~80% (wind)

Low

us-west-2

Oregon, USA

~89% (hydro/wind)

Low

eu-central-1

Frankfurt, Germany

~60% (wind/solar/mix)

Medium

us-east-1

N. Virginia, USA

~40% (mix)

Medium-high

ap-east-1

Hong Kong

~25% (mix with coal)

High

Decision Framework for Region Selection

  1. Are there regulatory residency requirements? → If yes, this is the dominant requirement

  2. Are there hard latency SLAs? → Maximum acceptable region selection

  3. Within the remaining regions: Carbon intensity as a tiebreaker

Related Controls

Summary of Design Principles

Principle Short form Core Decision Primary Control

SD1

ARM First

Graviton/ARM as default; x86 only with justification

WAF-SUS-020

SD2

Serverless for Bursts

Scale-to-zero for event workloads

WAF-SUS-040

SD3

Time-Shift Batch

Off-peak scheduling + carbon-aware APIs

WAF-SUS-060

SD4

Cache Aggressively

CDN + app cache + query cache

WAF-SUS-080

SD5

Minimize Transfer

Compression + VPC endpoints + same-region

WAF-SUS-080

SD6

Store Only Needed

Lifecycle policies everywhere; data minimization

WAF-SUS-050

SD7

Algorithm First

Efficiency before hardware; eliminate N+1

WAF-SUS-070

SD8

Green Region

Carbon intensity as an architecture parameter

WAF-SUS-030