Workload Placement When Data Center Permits Become a Supply Constraint

On this page

Introduction

What the Sources Say — and What They Leave Out

The UK moves to fast-track data center approvals

AVAIO sues Pulaski County over digital infrastructure rules

The standards argument for AI data center development

Separating confirmed details from inference

Why a Permit Hearing Becomes a Deployment Topology Decision

Capacity is a lead-time problem, not a price problem

The three clocks: entitlement, energization, silicon

Where this surfaces in your stack: quotas, SKUs, and zones

The Failure Mode: Assuming Region Symmetry

A worked example of a single-region dependency

Reproducing the assumption with provider CLI queries

Reading the output: what a failed SKU probe tells you

Building a Capacity Signal You Can Measure

Quota and availability-zone inventory probes

Tracking instance-type availability over time

Turning probes into a dashboard instead of a gut feeling

Encoding Placement Policy Instead of Tribal Knowledge

Tiering workloads by relocation cost

Labels, taints, and topology constraints that survive a provider change

Structuring Terraform modules for multi-provider placement

Designing for Region Eviction

Data gravity and the egress bill nobody modeled

Why stateful services are the hard part

Running a dry-run relocation test on a real service

Fast-Tracked Approvals and What They Mean for Buyers

Speed of approval is not speed of power

Contract terms worth negotiating now: ramps, tranches, exit clauses

Regulatory Variance as a Vendor Selection Criterion

Zoning litigation as supplier risk

Questions to ask providers about local entitlement status

Standards Work as a Procurement Filter

Which standards claims are verifiable and which are marketing

Turning a standards claim into a checklist item

A Workload Placement Audit You Can Run This Week

Step 1: Inventory hard dependencies

Step 2: Score relocation cost per service

Step 3: Test the fallback path under load

Step 4: Write the runbook before you need it

Impact and Defense Summary

What Would Change This Analysis

Further Reading

Introduction

A planning reform in London and a lawsuit in an Arkansas county courthouse don't read like infrastructure news. If you own a deployment pipeline, they are — because data center permits are now a supply constraint on the capacity your workloads eventually land on. The useful response isn't to start forecasting construction; it's to stop assuming a cloud region is a symmetric, interchangeable copy of every other one.

What follows is a workload placement playbook built on that idea: probes you can run against your own accounts today, a policy you can encode instead of remembering, and a relocation test you can schedule before an incident schedules it for you.

Three items landed in the same 48-hour window at the end of October 2026:

• ET Datacenters reported on 31 October 2026 that the UK is fast-tracking data center approvals amid power and supply-chain concerns.
• The Arkansas Democrat-Gazette reported on 30 October 2026 that data center developer AVAIO is suing Pulaski County over new digital infrastructure regulations.
• Broadband Breakfast published a piece on 30 October 2026 by Melissa Newman arguing that standards should be the foundation for responsible AI data center development.

It's easy to file these under "policy" and move on. Don't. Each one describes a different clock that decides when physical capacity actually becomes something your terraform apply can reach. Entitlement, energization, and silicon availability don't tick at the same rate, and the gap between them is where placement assumptions quietly rot.

Here's where I land: treat permitting and zoning as infrastructure telemetry. Not as business-news input, but as a leading indicator that specific SKUs in specific zones are about to get scarce, expensive, or contractually locked up — and that your architecture should already be able to lose them without falling over.

What the Sources Say — and What They Leave Out

Before I draw any conclusions: the public detail here is thin. All three items are short reports or opinion pieces — not advisories, not technical filings.

The UK moves to fast-track data center approvals

The ET Datacenters piece says the UK is moving to accelerate data center approvals and attributes the push to power and supply-chain concerns. That's the entire substantive claim in the report summary.

What's missing from the available detail: which planning instrument is in play — permitted-development rights, national policy statement treatment, a call-in mechanism, none of that is stated. Nor is whether the acceleration covers grid connection queues or planning permission alone, or what conditions and community-benefit requirements come attached. Anyone who names the mechanism without citing the instrument is guessing.

AVAIO sues Pulaski County over digital infrastructure rules

The Arkansas Democrat-Gazette reports that AVAIO, a data center developer, is suing Pulaski County over new digital infrastructure regulations. What's confirmed: the parties, the general subject, and that litigation exists.

What's not: the specific ordinance provisions being challenged, the legal theory, the relief sought, the hearing schedule. Those details matter enormously if you're modeling this site as future capacity — a challenge to a zoning map amendment and a challenge to a utility fee schedule are two different risks, not one.

The standards argument for AI data center development

The Broadband Breakfast piece is an argument, not a finding. Newman's position is that standards should underpin responsible AI data center development. Read it as a signal of where procurement questions are heading — not as evidence that any specific standard is being applied anywhere.

Separating confirmed details from inference

The last two rows are the ones that matter for engineering. I'm flagging them as inference up front, because everything below rests on them.

Why a Permit Hearing Becomes a Deployment Topology Decision

Capacity is a lead-time problem, not a price problem

Cloud pricing feels like the primary signal because it's the only one with an API. It's also a lagging one. By the time GPU capacity pricing moves, the constraint has been binding for quarters.

Lead time is the real variable. If a metro needs three years to entitle and energize a new facility, a one-year delay in a zoning decision doesn't raise prices next month — it removes an option from the 2029 supply curve. Your 2027 architecture is what has to absorb that.

So teams that plan placement off price sheets arrive late, consistently, because price sheets only describe the present. Teams that plan off lead times and availability probes are the ones describing the future.

The three clocks: entitlement, energization, silicon

Those ranges are rough industry-typical figures, not numbers from the sources above — treat them as directional. The ratio is the point. Energization is measured in years and entitlement can add more on top; silicon moves in quarters. A fast-tracked approval compresses the first row and does nothing to the second.

The sharp version: speed of approval is not speed of power. If the UK accelerates planning decisions and the grid connection queue doesn't move, what it accelerated is the start of the wait, not the end.

Where this surfaces in your stack: quotas, SKUs, and zones

Regulatory friction never appears to you as a permit. It appears as:

1. Service quota ceilings that don't get raised because the region is capacity-constrained.
2. SKU availability that differs per availability zone — the instance type exists in the region but is offered in two of three AZs.
3. Zone-level offering gaps that make a "three AZ" architecture secretly a two-AZ architecture.
4. Contract terms that shift from on-demand to committed capacity with ramp schedules.

Here's the model I find useful: new capacity isn't elastic, it's tranched. Providers get megawatts in tranches and hand them to committed customers first. On-demand availability in a constrained region is the leftover.

The Failure Mode: Assuming Region Symmetry

A worked example of a single-region dependency

Consider a service with an obvious shape:

• ledger-api runs on m7g.large behind an ALB.
• It writes to a managed Postgres instance that uses the pg_stat_statements and pgcrypto extensions.
• It reads and writes objects in a bucket in the same region, with a large working set.
• It has one batch job that needs g6e.xlarge for a few hours a day.

Four dependencies, four very different relocation costs. Compute is portable. The bucket is portable but expensive. The database is portable but slow, and the extension set is exactly the kind of thing that turns a 40-minute restore into a two-day incident because the target engine version doesn't ship pgcrypto the same way. The GPU batch job is the dependency that may just not exist in the fallback region at all.

The failure mode isn't "the region goes down." It's "leadership asks if we can move to region B, someone checks m7g.large exists in B, and the answer comes back yes." That answer is true and useless.

Reproducing the assumption with provider CLI queries

The cheapest way to break it is to probe offerings per AZ instead of per region.

aws ec2 describe-instance-type-offerings \
  --region eu-west-1 \
  --location-type availability-zone \
  --filters Name=instance-type,Values=p5.48xlarge \
  --query 'InstanceTypeOfferings[].[Location,InstanceType]' \
  --output table

Trimmed output from a sandbox account:

+-------------+--------------+
|  eu-west-1a | p5.48xlarge  |
|  eu-west-1b | p5.48xlarge  |
|  eu-west-1c | p5.48xlarge  |
+-------------+--------------+

Now the same query shape for a different type in a different region:

aws ec2 describe-instance-type-offerings \
  --region eu-central-1 \
  --location-type availability-zone \
  --filters Name=instance-type,Values=g6e.xlarge \
  --query 'InstanceTypeOfferings[].[Location,InstanceType]' \
  --output table

+-------------+--------------+
|  eu-central-1a | g6e.xlarge |
|  eu-central-1b | g6e.xlarge |
+-------------+--------------+

Two of three AZs. A three-AZ deployment manifest schedules fine on paper and fails to hit its spread target in practice.

Numbers are illustrative — your account and region will differ. The shape is the point: this API returns per-AZ offering rows, and an absent row is not a warning.

Reading the output: what a failed SKU probe tells you

Three distinct negative signals, three different meanings:

Conflating the first and third is the planning error I see most often. A missing offering in an AZ is a topology fact. InsufficientInstanceCapacity is a scheduling fact. One changes your architecture; the other changes your retry policy.

Quota is the other half:

aws service-quotas get-service-quota \
  --service-code ec2 \
  --quota-code L-1216C47A \
  --query 'Quota.[QuotaName,Value,Adjustable]' \
  --output table

+----------------------------------------------------------+-------+----------+
|  Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances  | 5.0 | True |
+----------------------------------------------------------+-------+----------+

A fresh account at 5 vCPUs isn't a capacity constraint, it's a paperwork constraint. It's also invisible on a cost dashboard, because you can't spend what you can't launch.

Building a Capacity Signal You Can Measure

Quota and availability-zone inventory probes

Three providers, three shapes of the same question.

AWS quota inventory:

aws service-quotas list-service-quotas \
  --service-code ec2 \
  --query "Quotas[?contains(QuotaName,'Running On-Demand')].[QuotaCode,QuotaName,Value]" \
  --output table

GCP quota inventory per region:

gcloud compute regions describe europe-west4 \
  --format="value(quotas)" | tr ';' '\n' | grep -Ei 'CPUS|GPUS'

{'metric': 'CPUS', 'limit': 24.0, 'usage': 24.0}
{'metric': 'NVIDIA_L4_GPUS', 'limit': 0.0, 'usage': 0.0}

A limit of 0.0 is the GCP equivalent of an AZ that never appears: not a shortage, a non-option until someone grants it.

Azure SKU and usage:

az vm list-skus --location eastus2 --size Standard_NC --output table
az vm list-usage --location eastus2 --output table

While you're here, note the AZ-ID subtlety on AWS:

aws ec2 describe-availability-zones \
  --query 'AvailabilityZones[].[ZoneName,ZoneId,State,ZoneType]' \
  --output table

+------------+-----------+---------+-----------------+
| us-east-1a | use1-az1  | available | availability-zone |
| us-east-1b | use1-az2  | available | availability-zone |
| us-east-1c | use1-az6  | available | availability-zone |
+------------+-----------+---------+-----------------+

us-east-1a maps to different physical zones for different accounts. use1-az1 doesn't. If you're comparing capacity across two accounts — the classic setup where one team has committed capacity and another is on-demand — compare ZoneId, not ZoneName.

Tracking instance-type availability over time

A probe is a data point. A signal needs a series.

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date -u +%FT%TZ)

for region in eu-west-1 eu-central-1 us-east-2; do
  for itype in p5.48xlarge g6e.xlarge m7g.large; do
    count=$(aws ec2 describe-instance-type-offerings \
      --region "$region" \
      --location-type availability-zone \
      --filters "Name=instance-type,Values=$itype" \
      --query 'length(InstanceTypeOfferings)' \
      --output text)
    echo "$STAMP,$region,$itype,$count"
  done
done

2026-11-02T06:00:11Z,eu-west-1,p5.48xlarge,3
2026-11-02T06:00:12Z,eu-west-1,g6e.xlarge,3
2026-11-02T06:00:12Z,eu-west-1,m7g.large,3
2026-11-02T06:00:13Z,eu-central-1,p5.48xlarge,2
2026-11-02T06:00:14Z,eu-central-1,g6e.xlarge,0
2026-11-02T06:00:14Z,eu-central-1,m7g.large,3

Append that to object storage, load it into a warehouse table, and you've got a time series with a single question: did the AZ count for a tier-0 SKU ever drop? A drop from 3 to 2 is an architecture change that nobody emailed you about.

Turning probes into a dashboard instead of a gut feeling

Three panels, in priority order:

1. Offering presence — count of AZs offering each tier-0 SKU, per region, over 90 days. Alert on any decrease.
2. Quota headroom ratio — limit - usage divided by steady-state demand. Below 1.5 means you're one deploy away from a quota ticket.
3. Launch failure rate — count of InsufficientInstanceCapacity per 1,000 launches, by region and AZ. The only panel here that measures actual scarcity rather than declared scarcity.

The first panel is regulatory telemetry in an infrastructure costume, and it's the cheapest of the three — three read-only API calls per SKU per region.

Encoding Placement Policy Instead of Tribal Knowledge

Tiering workloads by relocation cost

Write the tier down. If it lives in someone's head, it will be re-litigated during the incident.

The policy falls out of it: tier 0 gets a named owner and a documented fallback; tier 1 gets a rehearsed restore path with a measured RTO; tier 2 gets spread constraints; tier 3 gets whatever's cheapest.

Labels, taints, and topology constraints that survive a provider change

Use your own label namespace, not the provider's, and map provider topology onto it in one place. A provider change becomes a node-label change instead of a manifest rewrite.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ledger-api
spec:
  replicas: 6
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: ledger-api
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: hackyjs.io/relocation-tier
                    operator: In
                    values: ["1", "2"]
      tolerations:
        - key: hackyjs.io/capacity-tranche
          operator: Equal
          value: "committed"
          effect: NoSchedule

Two things to notice. whenUnsatisfiable: DoNotSchedule is a hard constraint — it leaves pods Pending instead of silently producing a two-AZ deployment. That's exactly right for a tier-1 service and exactly wrong for a tier-3 consumer that just needs to run somewhere. And hackyjs.io/relocation-tier is the portable piece: "this node is an acceptable home for a service that costs days to move" is a statement about your business, not about a provider.

Structuring Terraform modules for multi-provider placement

The trap is provider aliases. You can't for_each over a map of regions and get distinct provider configurations, because provider blocks are static per Terraform configuration. Try it and you get errors about unknown provider configurations, or worse, everything silently lands in the default region.

The workable shape is one module block per region with an explicit providers map:

provider "aws" {
  alias  = "primary"
  region = "eu-west-1"
}

provider "aws" {
  alias  = "secondary"
  region = "eu-central-1"
}

module "cell_primary" {
  source    = "./modules/cell"
  providers = { aws = aws.primary }

  cell_name     = "primary"
  instance_type = var.instance_type
  min_azs       = 3
}

module "cell_secondary" {
  source    = "./modules/cell"
  providers = { aws = aws.secondary }

  cell_name     = "secondary"
  instance_type = var.instance_type
  min_azs       = 2
}

The duplication is deliberate; keep it in one small file — placement.tf — so the diff that changes a region is obvious in review. The alternative, passing region as an input variable to a module that declares its own provider, works but breaks the mapping between module instances and provider configurations at plan time. That's how you end up with a plan that looks correct and a state file that disagrees.

Express AZ asymmetry as a variable, not a comment. min_azs = 2 for the secondary is a recorded fact about that region, and it should show up in plan output every time someone touches placement.

Designing for Region Eviction

Data gravity and the egress bill nobody modeled

Cross-region and cross-AZ traffic is cheap per gigabyte and enormous per month. Rough list prices, to be verified against current provider pricing:

40 TB isn't a big number for a service with a read-heavy cache. The dollar figure isn't the point — it's that a relocation turns a one-time egress charge into a recurring architectural cost. After the move, the two halves of the system live in different regions permanently unless you finish the migration.

Model it as: one-time transfer cost + (steady-state cross-region traffic × months until consolidation). The second term is the one everybody misses, because it only exists if the migration stalls — and migrations stall.

Why stateful services are the hard part

Stateless services relocate with a kubectl apply. Stateful services relocate with a project plan, and the reasons are boring and specific:

• Extension sets. The target engine version may not ship the same extensions or the same versions of them.
• Restore time is superlinear in practice. A 2 TB database doesn't restore in twice the time of 1 TB once you account for index rebuilds and WAL replay.
• Sequences and identity columns need explicit handling when you cut over writes.
• Cross-region replicas lag, and lag is a data-loss window if you promote under pressure.
• Backup storage may be regional. A backup that lives in the region you're evicting is not a backup.

None of this is novel. All of it gets discovered during the incident rather than before it, because nobody ran the restore against the fallback engine version.

Running a dry-run relocation test on a real service

The test: stand the service up in the secondary region, restore real data, and measure. Not a tabletop exercise — an actual deployment with a stopwatch.

A real result from a test like this tends to look unglamorous:

restore: 1.9 TB, 41m12s, 0 extension errors, engine version matched
deploy: 18/18 pods Ready, spread 6/6/6 across 3 AZs
p99 at 100% RPS: primary 84ms, secondary 118ms
write replay: 3 duplicate-key errors on sequence gaps
teardown: 1 orphaned KMS key, 2 orphaned log groups

That last line is what pays for the exercise. Orphaned resources on teardown mean your module's dependency graph is incomplete — which means your primary module is also incomplete, which means a partial apply during an emergency leaves debris you don't know about.

The three duplicate-key errors are the other useful bit. That's not the test failing; that's the test telling you sequence handling is unsolved in your migration runbook.

Fast-Tracked Approvals and What They Mean for Buyers

Speed of approval is not speed of power

This is the core claim, and it's worth stating flatly: accelerating planning approval compresses entitlement and leaves energization exactly where it was. If the binding constraint is grid interconnection, a faster permit gets you a faster queue entry, not a faster megawatt.

The engineering implication is about which announcements to believe. A provider announcing a new region with a permit in hand has cleared one of three clocks. A provider announcing a new region with an executed interconnection agreement, a substation schedule, and a committed power tranche has cleared two. Those are different products, and only one of them will have capacity when you need it.

When you evaluate any new region or expansion, the questions that matter are the boring contractual ones: when does power physically arrive, in what tranches, and what happens if it's late?

Contract terms worth negotiating now: ramps, tranches, exit clauses

If you're buying committed capacity — and in constrained markets you increasingly are — the terms carry more architectural weight than the SKU list.

• Ramp schedule with dates, not quarters. "Q3 2027" is not a schedule. "Physical delivery of tranche 1 by 2027-08-31" is, and it should come with a remedy attached.
• Tranche sizing matched to your own rollout. Committing to 100% of a tranche you can't fill is worse than committing to 60% with a right of first refusal on the rest.
• Exit clause tied to delivery failure. What you want: if tranche N isn't delivered by date D, the remainder of the commitment is cancellable without penalty. Without this, a provider's permitting problem becomes your balance-sheet problem.
• Migration assistance. Egress waivers and engineering hours for a relocation you didn't choose. Ask at signing, when you have leverage; you'll never get them during an incident.
• Regional flexibility clause. The right to satisfy the commitment in a different region of the same provider. Worth less than it sounds — regions aren't interchangeable — but not nothing for tier-2 and tier-3 workloads.

Regulatory Variance as a Vendor Selection Criterion

Zoning litigation as supplier risk

The AVAIO / Pulaski County dispute illustrates a category procurement teams usually don't model: the supplier's own entitlement is a dependency of yours.

If a developer's site is in litigation, the schedule variance belongs on your risk register even though you're not a party. Litigation delays the special use permit, which delays construction, which delays the tranche your commitment is sized against, which pushes your 2028 rollout into 2029 with no change to your own code.

Whether this specific dispute delays this specific project is unknown from the available reporting. What's known is that the dispute exists and the county's rules are new — the combination that most reliably produces schedule variance.

Questions to ask providers about local entitlement status

Ask these before signing, and ask for documents rather than reassurances:

1. Is the site's zoning approved unconditionally, or conditionally? What conditions?
2. Is there any active litigation or appeal against the approval? Who are the parties?
3. What is the interconnection position — queued, studied, or agreement-executed?
4. If an agreement is executed, what's the energization date, and does the utility have a track record at that scale in that jurisdiction?
5. Which tranche of power is our commitment fulfilled from, and what's the delivery date of that tranche?
6. What happens contractually if items 2 or 4 slip?

A provider that answers 1, 3, and 5 with dated documents is a different supplier from one that answers with adjectives.

Standards Work as a Procurement Filter

Which standards claims are verifiable and which are marketing

The standards argument points at a real gap: "responsible AI data center development" has no single definition, and without one, every vendor claims it. The engineering response is to convert the claim into a request for an artifact.

The left column is the whole filter. A claim that can't be paired with an artifact is not a criterion, it's a mood.

Turning a standards claim into a checklist item

A checklist item needs three fields: the claim, the artifact, and the failure action.

- claim: "Facility reports energy and water usage under a recognised scheme"
  artifact: "Most recent published report, facility identifier, reporting period"
  fail_action: "Downgrade supplier score; require remediation date in contract"

- claim: "Information security controls independently audited"
  artifact: "Audit report, period, auditor, scope covering this facility"
  fail_action: "Block until received"

- claim: "Power delivery committed for our tranche"
  artifact: "Interconnection agreement excerpt or utility confirmation letter"
  fail_action: "Treat committed capacity as on-demand in planning"

The third one is the one people forget to write down, and the one that changes your architecture. If you can't verify the power commitment, plan as though the capacity doesn't exist — in a constrained market, that's the safer assumption.

A Workload Placement Audit You Can Run This Week

Step 1: Inventory hard dependencies

List every dependency that pins a workload to a region. Then classify each one.

service          dependency                    pinned?  tier
ledger-api       postgres+pgcrypto             yes      1
ledger-api       object bucket (18 TB)         yes      1
ledger-api       m7g.large                     no       2
risk-batch       g6e.xlarge                    yes      0
risk-batch       training data lake            yes      0
notifier         none                          no       3

What you're looking for is the count of rows where pinned? = yes. That's your real region dependency, and it's almost always larger than the number of things in the architecture diagram.

Step 2: Score relocation cost per service

For each tier-1 service, record three numbers: restore time, deploy time, and steady-state cross-region traffic. Then compute the monthly cost of a stalled migration.

The second row is the interesting one: it can't be restored, only rebuilt, and the traffic cost accrues the whole time you're rebuilding.

Step 3: Test the fallback path under load

Don't test the fallback at 1% of traffic and call it done. Scale to 100% of production request rate in the secondary cell — even for ten minutes — and record p99. A fallback that works at low load and collapses at high load is worse than no fallback, because it manufactures false confidence in a runbook.

Record the numbers in the runbook itself. "Secondary handles 100% RPS at p99 118ms vs 84ms primary" is a sentence someone can act on at 3 a.m. "Secondary is ready" is not.

Step 4: Write the runbook before you need it

The runbook is short and specific:

1. Which cell is authoritative for writes, and how do you confirm it?
2. What's the exact sequence to promote the secondary database, including sequence reconciliation?
3. Which DNS or routing change moves traffic, and who has permission to make it?
4. What degrades deliberately — which tier-0 features turn off to protect tier-1?
5. What's the teardown order in the abandoned cell, and what's expected to be left behind?
6. Who decides to go back?

Question 6 is missing from most runbooks. A failover without a stated rollback decision is a one-way door dressed up as a temporary measure.

Impact and Defense Summary

Restating the position: permitting is a leading indicator of placement constraints. The response is measurement, not prediction. What you need is per-AZ SKU availability over time, plus a rehearsed eviction path for the services that can't move quickly.

What Would Change This Analysis

Being explicit about falsifiers is worth more than being confident.

• If the UK reform includes grid connection reform — for example, accelerated or prioritised queue treatment for data centers — then entitlement and energization compress together and the "approval is not power" argument weakens for that market specifically. That would need the published instrument, not a summary.
• If new capacity is delivered with executed interconnection agreements and dated tranches, the three clocks collapse toward the silicon clock, and per-AZ SKU probing becomes less predictive of future scarcity.
• If the Pulaski County litigation resolves quickly — dismissed, settled, or the ordinance amended — that site's variance drops and zoning litigation looks less like a general supplier risk. One case isn't a pattern.
• If GPU supply loosens enough that SKU availability stops being regional, the offering-presence panel loses most of its signal. Still worth keeping for quota.
• If providers publish per-region, per-AZ capacity commitments with contractual delivery dates, then procurement questions 5 and 6 above become answerable and the "unverifiable standards" problem shrinks.

None of these are in evidence today. All of them are checkable, which is the point.

Further Reading

The three reports this post is built on, as distributed:

• UK fast-tracks data center approvals amid power, supply chain concerns — ET Datacenters, 31 October 2026
• Data center developer AVAIO sues Pulaski County over new digital infrastructure regulations — Arkansas Democrat-Gazette, 30 October 2026
• Melissa Newman: Standards as the Foundation for Responsible AI Data Center Development — Broadband Breakfast, 30 October 2026

Primary technical documentation for the probes used above:

• AWS CLI: describe-instance-type-offerings — per-AZ offering reference
• AWS Service Quotas User Guide — quota codes and increase workflow
• Kubernetes: Pod Topology Spread Constraints — maxSkew, whenUnsatisfiable, zone spreading
• Kubernetes: Assigning Pods to Nodes — node affinity and taints
• Terraform: Provider Configuration — aliases and the providers map in modules
• Google Cloud: Regions and Zones — zone-to-region mapping and resource scope