1{2 "_what_this_is": "App Service Plan SKU -> Elastic Beanstalk / EC2 instance type. Consumed by design-refs/compute.md section 5 (Right-Sizing) after the rubric has already chosen a service. It NEVER influences the service choice.",3 "_selection_rule": "Nearest-not-smaller on BOTH vCPU and memory across the t3, c6i, m6i and r6i families, then cheapest of those that satisfy both axes. Every row records vCPU and memory for the Azure SKU AND the AWS instance so the arithmetic is checkable without trusting this file. If a row's aws side is smaller than its azure side on either axis, the row is a bug.",4 "_architecture": "x86_64 by default, per compute.md section 4 (Windows/.NET prevalence on Azure). The graviton_alternative field names the Arm equivalent for the cases where compute.md section 4's conditions all hold; it is an OFFER, never the default.",5 "_provenance": "Azure vCPU/memory figures are the published App Service plan specs; AWS figures are published instance specs. Authored, not machine-generated, and NOT verified against a live API. A row whose two sides do not justify each other should be corrected here rather than worked around downstream.",6 "_when_absent": "There is no longer an 'absent' case for App Service plans. Before this file existed, compute.md told the model to state a dev-tier default while also forbidding it to invent a number, which was unsatisfiable, and every size in the committed golden was a pretrained association."
30 "note": "t3.xlarge also satisfies both axes but carries 16 GiB, over double the source. c6i.xlarge is the tighter fit; if burstable-to-burstable matters more than the memory overshoot, that is a workshop decision."
66 "note": "t3.large matches on both axes and is cheaper; m6i.large is chosen because Pv3 is a production tier and burstable credits are a poor fit for always_on. If the plan is dev/test, t3.large is defensible."
106 "note": "App Service Environment (isolated). The isolation is a networking property, not a size; it becomes a private subnet, not a bigger instance."
120 "note": "Consumption plan. There is no instance: compute.md routes this to Lambda and there is nothing to size. Memory per function is a Lambda config, not an instance type."
130 "note": "Elastic Premium for Functions. The pre-warmed instance count maps to provisioned concurrency, NOT to an EC2 instance. Pricing it as an instance is the trap."
143 "rule": "From the plan's worker_count, NOT from the number of apps hosted on it. This is the App Service Plan fan-in (compute.md section 3): five apps on one S1 plan is one S1's worth of compute.",
144 "minimum": 1,
145 "zero_workers": "A plan with worker_count 0 or no apps is idle capacity. Map it, size it, and raise it as a cost-optimization finding rather than pricing it as running."