Why AWS API Endpoints Differ by Region - The Design of Global and Regional Services
We explain the design reasons behind the separation of regional endpoints like ec2.us-east-1.amazonaws.com and global endpoints like iam.amazonaws.com, as well as the existence of dual-stack and FIPS endpoints.
The Design Intent Behind Regional Endpoints
Most AWS services have independent API endpoints for each region. For EC2, these look like ec2.us-east-1.amazonaws.com and ec2.ap-northeast-1.amazonaws.com, with the region code included in the URL. This design has two intentions. First, fault isolation. Each region's endpoint runs on independent infrastructure, so if the EC2 API in us-east-1 experiences a failure, the EC2 API in ap-northeast-1 is unaffected. If all regions shared a single global endpoint, a failure at that endpoint would cascade to all regions. Second, data locality. API requests are processed by the control plane in that region, so requests don't need to cross continents. When you call the EC2 API in the Tokyo region, the request is processed by the Tokyo control plane, minimizing latency. SDKs send requests to the endpoint of the configured region by default, so developers rarely need to be aware of endpoint URLs.
The Special Design of Global Services
IAM, Route 53, CloudFront, WAF (for CloudFront), and STS global endpoints use URLs without region codes (iam.amazonaws.com, route53.amazonaws.com). The reason these services are global is that by nature they manage resources not tied to any specific region. IAM users and roles apply across the entire AWS account and don't belong to a specific region. Route 53 hosted zones are also global resources. However, the control planes of global services physically run in some region. IAM's control plane is concentrated in us-east-1, and during the 2021 us-east-1 outage, IAM management operations were affected. STS is an interesting exception. STS has both a global endpoint (sts.amazonaws.com) and regional endpoints (sts.ap-northeast-1.amazonaws.com). AWS recommends using regional STS endpoints because the global endpoint is processed in us-east-1, meaning STS calls from other regions would also be affected during a us-east-1 outage.
The Complexity of S3 Endpoints
S3 endpoints are the most complex among AWS services. Two URL formats exist: path-style (s3.amazonaws.com/bucket-name/key) and virtual-hosted-style (bucket-name.s3.amazonaws.com/key). AWS has recommended virtual-hosted-style since 2020, and newer SDKs use virtual-hosted-style by default. Furthermore, S3 has both regional endpoints (s3.ap-northeast-1.amazonaws.com) and a legacy global endpoint (s3.amazonaws.com). The legacy global endpoint redirects to us-east-1, so accessing buckets in other regions results in a 307 redirect, adding extra latency. When S3 Transfer Acceleration is enabled, yet another endpoint (bucket-name.s3-accelerate.amazonaws.com) is used. This endpoint routes data through CloudFront edge locations to improve upload speeds over long distances. S3's dual-stack endpoint (s3.dualstack.region.amazonaws.com) supports both IPv4 and IPv6.
FIPS Endpoints - Encryption Requirements for the US Government
AWS provides FIPS (Federal Information Processing Standards) 140-2 compliant endpoints for many services. FIPS endpoints use FIPS 140-2 certified cryptographic modules for TLS communication. The URL format appends fips to the standard endpoint (e.g., ec2-fips.us-east-1.amazonaws.com, s3-fips.us-east-1.amazonaws.com). FIPS endpoints are primarily needed by US federal government agencies and their contractors. Regulations like FedRAMP and FISMA require FIPS 140-2 compliant encryption for government data communications. Private companies may also be required to use FIPS endpoints when doing business with the government. There is no functional difference between FIPS endpoints and standard endpoints. The only difference is the cipher suites used during the TLS handshake. On FIPS endpoints, cryptographic algorithms not approved by FIPS 140-2 (such as ChaCha20) are disabled. The performance impact is negligible.
VPC Endpoints - API Access Without the Public Internet
Normally, when an EC2 instance calls an AWS API, the request goes through an Internet Gateway or NAT Gateway to the public internet and reaches the AWS API endpoint. With VPC Endpoints (PrivateLink), requests complete within AWS's private network without traversing the public internet. There are two types of VPC Endpoints. Gateway Endpoints are exclusive to S3 and DynamoDB and work by adding entries to route tables. There is no additional charge. Interface Endpoints (PrivateLink) create an ENI (Elastic Network Interface) in the VPC, enabling API access via private IP addresses. They cost $0.01 per hour plus data processing charges. The security benefit of VPC Endpoints is that API requests are not exposed to the public internet. In environments like financial institutions and healthcare organizations where data paths must be strictly controlled, VPC Endpoints are essential. There's also a cost benefit of reducing NAT Gateway data processing charges ($0.045/GB). To systematically learn about AWS endpoint design, specialized books (Amazon) can be helpful.