Region Selection Is Now a Compliance Decision: California's Data Center Package and Virginia EO 22

Region Selection Is Now a Compliance Decision: California's Data Center Package and Virginia EO 22

pr0h0•
data-centerscloud-complianceai-infrastructureregulationregion-selection
AI Usage (80%)

Introduction: Why Region Selection Is Now a Compliance Decision

If your Terraform picks a cloud region on latency and list price alone, you are making a compliance decision without the compliance review. That is the uncomfortable part of two developments reported in late September 2026, and this post explains what the public record does and does not establish — and how to make region selection reviewable.

On 25 Sep 2026, insideenergyandenvironment.com summarized a new California data center package aimed at energy consumption, water use, and environmental impacts. The same day, JD Supra reported that Virginia's Executive Order 22 updates guidance for data center developers in that state. A day later, The Black Chronicle covered a Virginia poll that puts data center infrastructure costs in focus, and The Regulatory Review published a broader analysis of how the AI data center boom is being regulated.

The position here is straightforward: region selection should be a documented, reviewed decision with a named owner and a revisit date — not a default buried in a module, not something only the person who wrote the original Terraform knows. State and local constraints do not care that your us-east-2 variable has been there since 2021.

What California's Data Center Package Actually Says About Energy, Water, and Environmental Impact

The public summary is short, and it is worth being precise about what it does and does not establish. According to the insideenergyandenvironment.com report published 25 Sep 2026, California has introduced a data center package focused on energy consumption, water use, and environmental impacts of data centers.

That is the substance of the summary. It does not give the full rule text, numeric thresholds, an enforcement agency, or effective dates. It also does not say whether this is binding rulemaking, a legislative package, or a policy signal intended to shape future rulemaking. I am not going to guess at any of those, because a fabricated threshold is worse than an open question — teams make budget decisions off numbers.

Confirmed Details Versus Missing Details

Confirmed by the summary:

  • California has introduced a data center package.
  • Its stated focus areas are energy consumption, water use, and environmental impacts.
  • The coverage is dated 25 Sep 2026.

Missing from the summary:

  • Whether the package is binding rulemaking or guidance.
  • Any numeric limits on energy or water use.
  • Whether existing facilities are grandfathered, and from what date.
  • Which agency or agencies enforce it.
  • Effective dates and compliance timelines.

Treat those as questions to answer from the primary documents, not gaps to fill with plausible-sounding assumptions. If a vendor or an internal deck presents a California threshold number, ask which document it came from.

Virginia's Executive Order 22 and the Data Center Cost Conversation

Virginia's Executive Order 22 story runs on a different mechanism. The JD Supra write-up dated 25 Sep 2026 says EO 22 updates guidance to Virginia data center developers. The Black Chronicle's 26 Sep 2026 poll coverage puts data center infrastructure costs in focus — a signal that the political salience of who pays for grid upgrades is rising.

Keep the distinction straight: Virginia's pressure is largely about utility capacity, ratepayer cost allocation, and local siting approvals. California's framing in the coverage above is energy, water, and environmental impact. Different levers, different agencies, different timelines — same net effect on where compute can physically sit and how fast it can grow there.

One caveat on the poll: the summaries we have do not include sample size, margin of error, question wording, or the breakdown of responses. Poll coverage is evidence that cost is now a live political topic in Virginia; it is not evidence of a specific level of public opposition. If you cite it internally, cite it that way.

📝

A state's mechanism matters more than its headline. Water permits and grid interconnection are gating items you cannot buy your way past with a bigger contract. Rate cases and local siting votes are slower and more political, but they can reprice a region after you have already committed capacity.

The Wider Pattern: Regulating the AI Data Center Boom Across States and Utilities

The Regulatory Review's 26 Sep 2026 piece frames these constraints as a stack of state, local, and utility decisions rather than one national rule. That framing is the useful part. There is no single compliance date to put on a calendar, because there is no single regulator.

For engineering teams, that fragmentation is the operational problem. A national rule can be read once, translated into a control, and monitored. A stack of county boards, utility commissions, and state agencies has to be tracked per site, and the sites are the thing your region variable points at.

Three Constraint Layers That Reach Software Teams

  1. Grid interconnection and water permits that gate capacity timelines. The source coverage describes these as the physical and permitting constraints behind the political attention. They determine when new capacity can exist at all, which is why a provider can announce a region and still deliver it late.
  2. Local siting and cost-allocation decisions that can reprice or delay capacity. Also in the sources — this is the Virginia cost thread. The financial exposure lands on ratepayers, developers, or hyperscalers depending on how a case resolves.
  3. Disclosure and reporting expectations that propagate into enterprise vendor contracts and audit questionnaires. This layer is an inference, not something the four reports state. It follows from how enterprise procurement already behaves: once a customer's own regulators or board ask where their data physically resides and what it costs the local grid, those questions show up in security questionnaires and contract schedules.

Be honest about which of those three you can cite. Layers 1 and 2 are in the source material. Layer 3 is my read of how procurement works.

Why Cloud Region Selection Is Now a Compliance Decision

When capacity in a region can be constrained, repriced, or publicly contested by state and local action, the standard trio — latency, price, service availability — stops being sufficient. Not wrong, just incomplete.

The failure mode is specific and easy to miss: a region still shows as available in the provider console, still accepts new resource creation, still passes your integration tests. But it has quietly become commercially or politically awkward to expand in. The API surface did not change. The console did not change. What changed is that a utility commission docket, a county siting vote, or a state package made additional capacity there slower, more expensive, or reputationally loaded. Your IaC has no way to observe that.

I have watched teams discover this in the worst possible order: first a procurement conversation, then a legal review, then an architecture review that should have run eighteen months earlier.

What Changes Concretely for Infrastructure Teams

  • Capacity lead times for new AI capacity in contested regions. If you are planning a GPU cluster, the schedule risk is not the provider's sales cycle, it is the permitting and interconnection queue. Assume longer, and make the provider commit in writing.
  • Cost volatility tied to rate cases rather than list pricing. List price per instance-hour is a poor proxy for total cost when the underlying power cost is subject to a public proceeding. I am not attaching a percentage to this — the source material contains no figures, and inventing one would be worse than saying it is unknown.
  • Disclosure requests from enterprise customers asking where compute physically runs. That is the inference layer again, but it is the one that lands on a platform team's desk as a questionnaire deadline.
  • Audit questions the platform team cannot currently answer, because nobody owns the answer by name.

Region-Selection Checklist and Vendor Questions for Compliance Review

Convert the news into something runnable.

Checklist Table

CriterionWhat to verifyWho owns it
Regulatory posture of state and localityWhich agencies have jurisdiction, what is proposed versus binding, and what the next decision point isPlatform lead, with legal review
Water and grid constraints at the specific facilityWhether the site has secured power and water, and what the interconnection queue position isInfrastructure lead, raised with the provider
Provider disclosure commitmentsWhat the provider will put in writing about site-level power and water, and under what terms it can change thatProcurement, with security
Contract terms for cost pass-throughHow utility rate increases reach your invoice and what caps or notice periods existProcurement, with finance
Exit options if a region becomes unviableData egress paths, provider-assisted migration terms, and how much of the stack is region-pinnedArchitecture lead

Questions to Ask Your Cloud Provider About Region Compliance

  1. Where is this specific capacity physically located — which state, which locality, which facility?
  2. What power and water profile does the provider publish for that site, and how often is it updated?
  3. What disclosure commitments exist in writing, and can they be attached as a contract exhibit, not a marketing page?
  4. How are utility rate increases passed through to committed-spend customers, and with how much notice?
  5. What happens to committed capacity if a facility is delayed or blocked by a local siting decision — credit, substitution, or nothing?

If a provider cannot answer question 5, that is your answer.

Encoding Region Policy in CI to Make Region Selection Reviewable

A policy file and a CI check make the decision reviewable instead of tribal knowledge. To be explicit: this is policy plumbing, not a compliance guarantee. It cannot tell you whether a region is legally safe. It can tell you the decision was made deliberately and by whom.

Example regions.yaml

## regions.yaml — internal policy record. Not a compliance certification.
allowed:
  - id: us-west-2
    provider: aws
    owner: platform-team
    reviewed: 2026-09-26
    reason: primary production region
    notes: confirm grid and water status with provider before Q1 capacity request
  - id: us-east-1
    provider: aws
    owner: platform-team
    reviewed: 2026-09-26
    reason: approved for staging and burst
    notes: revisit date 2027-03-01

The Check and Its Output

scripts/check-regions.mjs
// Read-only. No network calls, no cloud credentials, no state written.



const POLICY = "regions.yaml";
const SCAN_ROOT = process.argv[2] ?? "infra";
const REGION_RE = /(?:region|location)s*[:=]s*"([a-z]{2}-[a-z]+-d)"/g;

function walk(dir, out = []) {
for (const entry of readdirSync(dir, { withFileTypes: true })) {
  const p = join(dir, entry.name);
  if (entry.isDirectory()) walk(p, out);
  else if (extname(p) === ".tf") out.push(p);
}
return out;
}

function approvedRegions(file) {
return new Set(
  readFileSync(file, "utf8")
    .split("
")
    .map((line) => line.match(/^s*-s*id:s*([a-z]{2}-[a-z]+-d)s*$/))
    .filter(Boolean)
    .map((m) => m[1])
);
}

const approved = approvedRegions(POLICY);
const seen = new Map();

for (const file of walk(SCAN_ROOT)) {
for (const match of readFileSync(file, "utf8").matchAll(REGION_RE)) {
  if (!seen.has(match[1])) seen.set(match[1], new Set());
  seen.get(match[1]).add(file);
}
}

const violations = [...seen].filter(([region]) => !approved.has(region));

if (violations.length === 0) {
console.log(`region policy OK (${seen.size} region(s) referenced)`);
process.exit(0);
}

for (const [region, files] of violations) {
console.error(`FAIL: region "${region}" is not approved in ${POLICY}`);
for (const f of files) console.error(`  - ${f}`);
}
process.exit(1);

Running it against a repo with three unapproved regions produced this:

$ node scripts/check-regions.mjs infra
FAIL: region "us-east-2" is not approved in regions.yaml
  - infra/prod/main.tf
FAIL: region "eu-central-1" is not approved in regions.yaml
  - infra/prod/main.tf
FAIL: region "ap-southeast-1" is not approved in regions.yaml
  - infra/experiments/gpu-pool.tf
$ echo $?
1

The value is not the regex. It is that someone now has to add a line to regions.yaml with an owner and a reason before the build goes green, and that the reason is still reviewable a year later.

Confirmed, Inferred, and Unconfirmed Claims

Confirmed — the four reports exist, with the publishers and dates given: insideenergyandenvironment.com on California's data center package (25 Sep 2026), JD Supra on Executive Order 22 guidance for Virginia developers (25 Sep 2026), The Regulatory Review on regulating the AI data center boom (26 Sep 2026), and The Black Chronicle on the Virginia cost poll (26 Sep 2026). The stated focus areas — energy, water, environmental impacts for California; developer guidance for Virginia — come from those reports.

Inferred — that these constraints will surface in enterprise contracts and audit questionnaires, and that enterprise buyers will start asking for site-level power and water disclosure. That is my read of procurement behavior, not a claim any of the four sources makes.

Unconfirmed — whether the California package is binding rulemaking or guidance; what EO 22 actually changes in practice beyond updating developer guidance; and whether Virginia cost allocation shifts toward ratepayers. None of that is resolvable from the summaries we have.

What to Watch Next

  • The full California package text and effective dates. If it turns out to be binding with numeric limits and no grandfathering for existing facilities, site selection in California becomes urgent rather than advisory. If it is guidance, it mostly changes what providers are willing to commit to publicly.
  • The EO 22 guidance document itself. If it adds disclosure or siting conditions, Virginia developers inherit new documentation obligations; if it only restates existing process, the practical impact is small.
  • Virginia rate-case outcomes. These determine whether compute in the state gets more expensive through the power bill rather than the instance price.
  • Any utility commission docket that changes interconnection queue priority. This is the item most likely to move a capacity timeline by quarters, and the least visible from a cloud console.

Conclusion: Region Selection Is a Documented Compliance Decision

Region selection is now a reviewed, documented, owned decision with a revisit date — and a region can be technically available while being a bad place to keep growing. The console will not warn you. The API will not warn you. The only warning you get is the one your own policy file and CI check produce.

The cost of ignoring this is not a failed deployment. It is a workload you can run but cannot easily justify or expand: latency is fine, the invoice is fine, and then someone asks where it runs and what the local grid and water situation is, and nobody has an answer.

Further Reading

Share this post

More posts

Comments