On this page · 10 sections
Summary. AWS announced general availability of an AWS Local Zone in Las Vegas, Nevada on 20 August 2026, with an RSS publication timestamp of Thu, 20 Aug 2026 21:45:00 GMT. The announcement names the zone us-west-2-las-2a and lists Amazon EC2 C7i, M7i, R7i and C8gn instances plus Amazon EBS volume types gp3, gp2, io1, sc1 and st1. AWS's own Local Zones features page, last updated 7 August 2026 and the page its FAQ tells buyers to consult for exactly these two questions, carries a single Las Vegas row - for the older us-west-2-las-1a - listing T3, C5d, R5d and G4dn instances and the gp2 volume type only. There is no overlap between the two instance lists and a five-to-one gap on EBS. This is also the second Las Vegas Local Zone, not the first: AWS has served the metro since 26 October 2021.
If you size a Las Vegas deployment from the features table, you will get a completely wrong answer, and the FAQ sent you there twice.
What AWS actually announced
The AWS What's New item, posted 20 August 2026, reads in full on the service list:
"AWS Local Zone in Las Vegas, Nevada is now generally available. The new AWS Local Zone supports Amazon Elastic Compute Cloud (Amazon EC2) C7i, M7i, R7i, and C8gn instances, Amazon Elastic Block Store (Amazon EBS) volume types gp3, gp2, io1, sc1, and st1, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Application Load Balancer, and AWS Direct Connect."
The activation instruction names the zone directly: "To get started, enable the Las Vegas Local Zone (us-west-2-las-2a)".
The Local Zones availability table in the user guide confirms both Las Vegas zones and their parents.
| Attribute | New zone | Existing zone |
|---|---|---|
| Local Zone name | us-west-2-las-2a |
us-west-2-las-1a |
| Local Zone ID | usw2-las2-az1 |
usw2-las1-az1 |
| Network Border Group | us-west-2-las-2 |
us-west-2-las-1 |
| Parent Region | us-west-2 |
us-west-2 |
| Parent Zone ID | usw2-az1 |
usw2-az3 |
| GA date | 20 August 2026 | 26 October 2021 |
The parent zone row is the one architects should read twice. The two Las Vegas Local Zones hang off different Availability Zones in Oregon, so a parent-AZ event does not take both out. AWS does not discuss this anywhere in the announcement, and it is the strongest argument for the new zone existing at all.
The 2021 date comes from AWS's own record: the general availability announcement of 26 October 2021 states "Today we are announcing the general availability of AWS Local Zones in Las Vegas, New York City (located in New Jersey) and Portland." Coverage framing this as AWS arriving in Las Vegas is wrong by nearly five years.
The contradiction that costs you a sizing exercise
AWS's Local Zones features page is the canonical per-location services table. Its North America section contains one Las Vegas row, mapped to us-west-2-las-1a, and us-west-2-las-2a does not appear on the page at all. That omission is not a formatting artefact - Los Angeles is listed twice, as us-west-2-lax-1a and us-west-2-lax-1b, so the page does split multi-zone metros when they exist.
| Question | What's New, 20 August 2026 (las-2a) |
Features page, updated 7 August 2026 (las-1a) |
|---|---|---|
| EC2 instance families | C7i, M7i, R7i, C8gn | T3, C5d, R5d, G4dn |
| EBS volume types | gp3, gp2, io1, sc1, st1 | gp2 |
| Load balancing | Application Load Balancer | ALB |
| Shield | Not stated | Standard |
The AWS Local Zones FAQ routes both questions to the stale page. On storage: "Which Amazon EBS volume types are available in Local Zones? - For EBS volume types offered in each Local Zone, see AWS Local Zones features." On compute: "What instance types are supported in Local Zones? - ...see AWS Local Zones features."
The practical consequence is specific. A team planning a gp3-backed workload on Graviton-class C8gn in Las Vegas would read the features page, find gp2 and G4dn, and conclude the zone cannot carry the design. The opposite team, already running on las-1a, might read the What's New note and assume gp3 and io1 arrived in their zone. Neither AWS page corrects the other. This is the same pattern we documented when AWS Cost Anomaly Detection docs conflicted on third-party Bedrock models - two pages, both current, both authoritative-looking.
A third page adds to it. The Local Zones locations page carries an update timestamp of 20 August 2026, announcement day, and still leads with "New Local Zones are now available in Istanbul (Türkiye), Hanoi (Vietnam), and Athens (Greece)." Las Vegas is not mentioned.
Price: AWS says different, never says how different
The Local Zones pricing page states the position in one sentence: "Amazon Elastic Compute Cloud (EC2) Instances and other AWS resources in Local Zones will have different prices than in the parent region."
Read the verb. "Different", not higher, and no magnitude anywhere. Data transfer gets the same treatment: "Data Transfer in AWS Local Zones is charged with Local Zone specific rates." The link from that sentence goes to the EC2 On-Demand pricing page, where every rate table is rendered client-side and returns nothing to a plain fetch. The FAQ confirms the method rather than the number: "For pricing information, please visit the pricing section on the respective services. You can filter pricing information by choosing the Local Zone location in the drop-down list."
So the on-demand rate for a C7i in us-west-2-las-2a, and the Local-Zone-to-Region data transfer rate, are obtainable only through a console widget. Neither is published as a table you can diff, budget against, or put in a business case. One item is explicitly equal: "You pay the same price for Amazon Machine Images (AMIs) and services purchased from AWS Marketplace as in the AWS Region."
Anyone building a cost model here should treat the Local Zone line as unpriced until they have pulled it from the console for their own account, the same discipline we apply to cloud storage pricing across AWS S3, Azure and GCP.
The limits nobody puts in the announcement
The how Local Zones work page carries the constraints, and several of them break common network designs outright:
- "You cannot create VPC endpoints inside Local Zone subnets."
- "The AWS Site-to-Site VPN is not available in Local Zones. Use a software-based VPN to establish a site-to-site VPN connection into a Local Zone."
- "You cannot select a subnet from a Local Zone while creating a Cloud WAN or transit gateway VPC attachment. Doing so will result in an error."
- "Network traffic will hairpin to the AWS Region when connecting from an on-premises location into a Local Zone using a Transit Gateway."
- "Amazon EBS snapshots storage vary depending on the Local Zone selected" and "Default encryption behavior of Amazon EBS volume varies depending on the Local Zone selected".
The sharpest number is the maximum transmission unit. AWS documents "1300 bytes between an Amazon EC2 instance in a Local Zone and an Amazon EC2 instance in the Region for all Local Zones except: 9001 bytes for us-west-2-lax-1a and us-west-2-lax-1b; 8801 bytes for us-east-1-atl-2a, us-east-1-chi-2a, us-east-1-dfw-2a, us-east-1-iah-2a, us-east-1-mia-2a, us-east-1-nyc-2a, and us-west-2-phx-2a".
Neither Las Vegas zone is in an exception list, so both run at 1300 bytes to Oregon against 8801 or 9001 for the favoured zones - roughly a seven-fold framing penalty on traffic that is also billed at rates AWS does not publish. Direct Connect follows the same split: 1500 bytes for Las Vegas against 8500 for the exception zones. That matters if your design depends on Direct Connect, which is one of only four services the announcement names; our note on Direct Connect inbound prefix controls covers the routing side.
IPv6 produces a second, cleaner contradiction. The EC2 user guide on Regions and zones says Amazon-provided IPv6 VPC addresses are "available only in the Los Angeles zones". The Local Zones user guide lists nine: "us-east-1-atl-2a, us-east-1-chi-2a, us-east-1-dfw-2a, us-east-1-iah-2a, us-east-1-mia-2a, us-east-1-nyc-2a, us-west-2-lax-1a, us-west-2-lax-1b, and us-west-2-phx-2a". One says one metro, the other says seven. Both agree on the part that affects this launch: neither Las Vegas zone supports Amazon-provided IPv6, so plan IPv4-only.
Availability: there is no Local Zone SLA
The FAQ's entire answer on service levels is a redirect: "What Service Level Agreements (SLAs) apply to Local Zones? More information about the SLAs for AWS services can be found here." No Local-Zone-specific commitment is published.
The same FAQ claims "Both Local Zones and Availability Zones allow you to build applications for high availability." Each Las Vegas Local Zone is a single zone with a single Network Border Group tied to one parent AZ, and unlike Los Angeles there is no second zone in the metro. In-metro multi-AZ does not exist here. Availability comes from pairing the Local Zone with us-west-2 itself, which is exactly the hop that runs at a 1300-byte MTU.
Per the features table, us-west-2-las-1a also has no entry for FSx, EMR, ElastiCache, RDS, GameLift, NAT Gateway, AWS Elastic Disaster Recovery or S3, while ECS, EKS, VPC, Direct Connect, Application Migration Service and Route 53 Geoproximity are present, ELB is Application Load Balancer only with no Network Load Balancer, and Shield is Standard only. Since the features page never mentions las-2a, whether that list carries over is unstated.
India-specific considerations
There is no Local Zone in India, so this launch changes nothing directly for Indian workloads. It is worth reading as a pattern instead: AWS ships an edge location, names a service list in the announcement, and leaves the canonical table behind. Indian teams evaluating latency-sensitive edge placement should verify every service and instance claim against the availability table in the user guide rather than the marketing features page, and should assume unpublished pricing until the console confirms it. Where personal data would sit in an edge zone, the Digital Personal Data Protection Act 2023 makes the processing location a recorded decision, and an undocumented service list is a poor basis for one. The broader cost discipline is in our cloud FinOps guide for Indian teams.
What is still unknown
Three things, and none of them should be filled with a guess. Whether us-west-2-las-2a inherits the las-1a service ticks for ECS, EKS, Route 53 Geoproximity and Application Migration Service is not stated anywhere. The on-demand and data-transfer rates for the zone are not published in fetchable form. And AWS has not said whether the features page omission is a lag or a signal that the new zone carries a different service set. Until the features table is updated, the announcement text is the only per-zone source that exists for las-2a, and one paragraph is a thin basis for a production design.
FAQ
How eCorpIT can help
eCorpIT designs and moves production workloads onto AWS edge and multi-Region topologies, and we verify service availability against the user guide tables rather than the marketing pages before a design is signed off. Our senior engineering teams model the data-transfer and MTU consequences of a Local Zone hop before the first instance launches. See our cloud migration services or contact us to review a Las Vegas or edge placement.
Related reading: multicloud interconnect cost architecture.
References
Last updated: 21 August 2026.
