Turn AWS's 2027-28 GPU ramp into a capacity and token-cost plan

The ramp is a dated supply curve

You are pricing 2027 inference before the GPUs that will serve it are installed. The trade-off is dated supply versus guaranteed serving. On August 26, AWS and NVIDIA announced a two-million-GPU expansion for Amazon's cloud, covering Blackwell Ultra, Rubin, and Rubin Ultra parts in 2027 and 2028. The deal reserves 100,000 GPUs in AWS secure infrastructure for U.S. federal and national-security workloads. Subtract the secure allocation from the announced pool, and the base for commercial planning is 1.9 million GPUs. Use that reduced pool before pricing inference.

The ramp builds on a prior pledge to place over one million GPUs into service starting in 2026. The 2026 cohort sets the first serving baseline; the 2027 and 2028 cohorts set the planning horizon. A later cohort cannot fill an earlier quarter's serving gap. Keep the date separate from the marketing ramp. The planning window is a staged supply curve.

Subtract the GPUs you cannot serve

Secure units are unavailable for ordinary commercial serving. Non-serving units do not produce customer tokens. If a unit is not billed as a token, it does not belong in the serving denominator. Commercial capacity is the remainder after those exclusions. Reservation behavior reduces the pool further. NVIDIA CEO Jensen Huang framed the AWS-NVIDIA tie-up as a key growth engine for the AI era and said demand is outrunning every forecast. When demand is ahead of supply, operators may hold capacity for peak traffic instead of selling it at a lower average price. Reserved capacity becomes the scarce input. The usable pool is smaller before tokens are billed.

CPU and interconnect limits shrink usable capacity

AWS will also offer NVIDIA Vera CPUs as an option for agentic jobs that need heavy CPU compute next to accelerators. That CPU requirement reduces the accelerator pool, because agentic serving consumes both CPU and GPU time. CPU hours belong in the cost numerator. CPU allocation affects both cost and throughput. Plan CPU allocation before assuming every accelerator hour produces tokens.

NVIDIA is extending NVLink Fusion, its high-speed chip interconnect, to Amazon's Annapurna Labs Trainium silicon so Trainium and NVIDIA GPUs can share a rack-scale design. The serving unit becomes a shared domain, not a standalone card. Build the serving model around the rack, not the chip. Rack topology determines how many accelerators can serve a job. A GPU that cannot reach the right memory, CPU, or peer accelerator produces fewer tokens. The constraint is the path between components.

Recompute token price and outage cost

Cost per token is a ratio, not a list price: total serving cost divided by tokens served. Put every line item in dollars per token, including accelerator time, CPU time, interconnect, power, labor, and maintenance. If the numerator rises while tokens per GPU-hour fall, the unit price rises. The denominator is the part that can offset a larger numerator. Track the ratio by serving quarter.

Outage cost is the other side of the same ratio. Lost tokens reduce the denominator, while recovery work raises the numerator. SLA credits and customer churn can add another cost layer. A short outage can erase margin from many billed tokens. Outage exposure belongs in the same ratio, under stress.

Use this order to turn the announced ramp into a dated serving-capacity plan:

• Date each GPU cohort through 2028; do not count a later cohort in an earlier serving quarter.
• Subtract reserved federal and non-serving capacity before assigning production inference.
• Apply CPU and NVLink constraints, because a serving domain is only as fast as its slowest path.
• Recompute cost per token and outage cost after every capacity change.