Amazon Web Services

What Is Amazon Web Services (AWS)?

Amazon Web Services (AWS) is the world's largest and most comprehensive cloud computing platform. Launched in 2006, it began as the infrastructure Amazon built to run its own retail business and has grown into a global utility that powers an enormous share of the modern internet, from startups to the largest enterprises and government agencies. When you ask "what cloud is this website on?", AWS is statistically the most likely single answer.

The short, useful definition: AWS rents computing infrastructure and managed services on demand. Instead of buying servers, a company provisions virtual machines, storage, databases, content delivery, and hundreds of higher-level services through an API or web console, paying only for what it uses. AWS operates dozens of geographic regions, each containing multiple isolated availability zones, connected by a private global backbone, so applications can run close to users and survive data-center failures.

On market position, AWS is widely and consistently reported as the leading cloud infrastructure provider by revenue and share, ahead of Microsoft Azure and Google Cloud, which round out the "big three." That ranking is well established qualitatively and reported every quarter by analysts such as Synergy Research and Canalys; the exact percentage shifts over time, so treat any specific figure with caution and rely on the durable fact that AWS is number one by a clear margin.

For website detection, the important consequence of AWS's breadth is that "a site runs on AWS" can mean many different things: a single EC2 virtual machine, a fleet behind an Elastic Load Balancer, static files in an S3 bucket, a global cache through CloudFront, a serverless API on Lambda and API Gateway, or any combination. Each leaves slightly different fingerprints.

How Amazon Web Services Works

AWS is organized as a layered catalog of services that customers compose into applications. A handful of building blocks account for the vast majority of public-facing websites and are the ones whose fingerprints you will encounter.

• Amazon EC2 (Elastic Compute Cloud). Resizable virtual servers. A site may run a web server such as Nginx, Apache, or IIS directly on EC2 instances. EC2 itself does not usually announce "AWS" in headers; the running web server does the talking, and AWS shows up at the network layer.
• Amazon S3 (Simple Storage Service). Object storage with effectively unlimited capacity. Static websites, downloads, images, and assets are frequently served from S3, which emits distinctive x-amz-* headers.
• Amazon CloudFront. AWS's global content delivery network, with hundreds of edge locations. It caches and accelerates content and is one of the clearest AWS tells because of its x-amz-cf-id and Via headers.
• Elastic Load Balancing (ELB). Distributes incoming traffic across multiple targets. Application Load Balancers set recognizable session-affinity cookies.
• AWS Lambda and API Gateway. Serverless compute and managed API front ends that power a large share of modern APIs and backends without any persistent server.
• Route 53. AWS's authoritative DNS service, which can reveal AWS involvement through name-server delegation.

The platform is glued together by Identity and Access Management (IAM) for permissions, Virtual Private Cloud (VPC) for network isolation, and CloudWatch for monitoring. Billing is metered and pay-as-you-go, with Reserved Instances and Savings Plans offering discounts for committed usage. The defining experience is that everything is API-driven and programmable, which is why infrastructure-as-code tools and automated deployments are the norm on AWS.

How to Tell if a Website Uses AWS

AWS leaves a substantial trail across HTTP headers, DNS, IP ownership, and asset domains. The catch, more than with most technologies, is that AWS components are frequently hidden behind CloudFront or other CDNs, so you must read signals in combination.

Amazon-specific response headers

The clearest fingerprints are the family of x-amz-* headers AWS services attach to responses. Watch for:

• x-amz-cf-id and x-amz-cf-pop are emitted by CloudFront and identify the request and the edge point of presence that served it. Their presence is a strong indicator of AWS at the edge.
• x-amz-request-id and x-amz-id-2 are returned by S3 and several other services to identify the request for debugging.
• Via: 1.1 <hash>.cloudfront.net (CloudFront) explicitly names CloudFront in the standard Via header.
• Server: AmazonS3 appears directly on objects served from S3 buckets.

Read these with curl -I https://example.com or in the browser DevTools Network tab by clicking a request and inspecting its response headers. Wappalyzer and similar fingerprinting tools also flag CloudFront, S3, and other AWS services automatically.

Load balancer and session cookies

If a site runs behind an AWS Application Load Balancer with sticky sessions enabled, the response sets distinctive cookies:

• AWSALB and AWSALBCORS are set by Application Load Balancers for session affinity.
• AWSELB is the equivalent set by the older Classic Load Balancer.

Spotting an AWSALB cookie in DevTools (Application tab, Cookies) or in the Set-Cookie response header is a reliable sign the site sits behind AWS load balancing.

IP ranges and reverse DNS

Network-level checks are powerful for AWS. Resolve the domain with dig example.com or nslookup example.com, then examine the address:

• Reverse DNS. A reverse lookup on an AWS-hosted IP frequently resolves to a hostname under amazonaws.com, such as ec2-203-0-113-25.compute-1.amazonaws.com or a *.elb.amazonaws.com load-balancer name. That amazonaws.com suffix is a direct giveaway.
• Published IP ranges. AWS publishes its complete list of IP ranges in a public ip-ranges.json file, broken down by region and service. Checking whether a site's IP falls within those ranges confirms AWS hosting and can even reveal the region and whether the address belongs to CloudFront, EC2, or S3.

Asset domains and DNS delegation

The domains a page loads its assets from are revealing. Resources served from *.s3.amazonaws.com, *.s3.<region>.amazonaws.com, or *.cloudfront.net indicate S3 storage and CloudFront delivery respectively. On the DNS side, name servers under awsdns (for example ns-123.awsdns-45.com) show the domain uses Route 53, another strong AWS signal you can confirm with dig NS example.com.

The crucial caveat: CloudFront and CDNs mask the origin

This is the defining detection challenge for AWS. CloudFront is so widely used, including in front of origins that are not on AWS at all, that the headers you see often describe the CDN edge rather than the true origin. Two patterns recur:

1. CloudFront in front of a non-AWS origin. A site can serve through CloudFront while its origin runs on another cloud or on-premises. The x-amz-cf-id header tells you the edge is AWS, not that the application lives on AWS.
2. A third-party CDN in front of an AWS origin. Conversely, an AWS-hosted application can sit behind Cloudflare or Fastly, in which case the public Server header reads cloudflare or Fastly and the AWS origin is hidden entirely.

Because of this, no single header is conclusive. Combine HTTP headers, cookies, reverse DNS, published IP ranges, asset domains, and DNS delegation, and where possible rely on a server-side analysis that correlates all of them rather than trusting the edge alone.

Key Features

AWS's catalog is vast, but the capabilities most relevant to running and identifying websites include:

• Global infrastructure. Dozens of regions and availability zones plus hundreds of CloudFront edge locations for low-latency delivery worldwide.
• Elastic compute. EC2 virtual machines, container services (ECS and EKS), and serverless Lambda functions that scale on demand.
• Durable storage. S3 object storage with very high durability, plus block (EBS) and file (EFS) storage options.
• Managed databases. Relational (RDS, Aurora), key-value (DynamoDB), caching (ElastiCache), and analytics (Redshift) services.
• Networking and delivery. VPC isolation, Elastic Load Balancing, Route 53 DNS, and the CloudFront CDN.
• Security and identity. Fine-grained IAM permissions, AWS Shield DDoS protection, AWS WAF, and broad compliance certifications.
• Programmability. A comprehensive API, command-line interface, SDKs, and first-class support for infrastructure-as-code.

Pros and Cons

AWS's scale is both its greatest strength and the source of its main drawbacks.

Pros

• The broadest and deepest service catalog of any cloud, covering nearly every workload.
• The largest global footprint, enabling low latency and strong availability.
• A mature, battle-tested platform with an enormous ecosystem of tools, partners, and expertise.
• Fine-grained, pay-as-you-go pricing with discounts for committed usage.
• Strong security tooling and a wide range of compliance certifications.

Cons

• Significant complexity; the sheer number of services has a steep learning curve.
• Pricing is granular and can be hard to predict, with data-egress (transfer-out) charges a common source of surprise bills.
• Risk of vendor lock-in as applications adopt proprietary managed services.
• Cost optimization requires ongoing attention and expertise to avoid waste.

AWS vs Alternatives

AWS is most often compared with Microsoft Azure, Google Cloud Platform, and developer-focused providers such as DigitalOcean. The table summarizes the trade-offs.

Feature	AWS	Microsoft Azure	Google Cloud (GCP)	DigitalOcean
Market position	Largest by share	Second-largest	Third of the big three	Niche, developer-focused
Service breadth	Widest	Very wide	Wide	Focused/simpler
Best-fit strength	Everything at scale	Enterprise / Microsoft stack	Data, analytics, AI	Simplicity, predictable pricing
Edge/CDN	CloudFront	Azure Front Door / CDN	Cloud CDN	Built-in CDN
Detection header tell	x-amz-cf-id, AmazonS3	x-azure-ref	Google Frontend	provider IP ranges
Pricing model	Pay-as-you-go, granular	Pay-as-you-go	Sustained/committed discounts	Flat predictable rates

If an organization is weighing clouds, the most common cross-shops are Google Cloud Platform for data and AI workloads and Microsoft Azure for Microsoft-centric enterprises; AWS remains the default when breadth and scale matter most.

Use Cases

• Web and application hosting at scale. From a single EC2 instance to auto-scaling fleets behind load balancers serving global traffic.
• Static sites and asset delivery. S3 for storage and CloudFront for global caching, a very common pattern for marketing sites and SPAs.
• Serverless backends and APIs. Lambda and API Gateway power event-driven applications without managing servers.
• Data lakes and analytics. S3-based data lakes feeding Redshift, Athena, and machine-learning pipelines.
• Disaster recovery and global redundancy. Multi-region architectures that survive zone or region failures.
• Competitive and infrastructure research. Detecting AWS, and which services a target uses, informs lead generation, vendor analysis, and security assessments. See our guides on how to tell if a website is hosted on AWS and how to find out where a website is hosted.

Frequently Asked Questions

How can I tell if a website is hosted on AWS?

Use several signals together. Start with HTTP headers by running curl -I https://example.com or opening DevTools and inspecting the document request's response headers; look for x-amz-cf-id (CloudFront), Server: AmazonS3 (S3), or x-amz-request-id. Check for AWSALB cookies that indicate an AWS load balancer. Then resolve the domain with dig or nslookup and do a reverse-DNS lookup, watching for hostnames ending in amazonaws.com, and check whether the IP falls within AWS's published ip-ranges.json. Asset domains under s3.amazonaws.com or cloudfront.net are additional confirmation. Our walkthrough on how to tell if a website is hosted on AWS covers the full process.

Does seeing a CloudFront header mean the whole site is on AWS?

Not necessarily, and this is the most common misconception. CloudFront is a content delivery network that can sit in front of origins hosted anywhere, including other clouds or on-premises servers. An x-amz-cf-id or Via: ... cloudfront.net header confirms that AWS's CDN is serving the request at the edge, but the origin application could live elsewhere. To determine where the origin actually runs, you need to look past the edge, using origin-revealing signals and ideally a server-side analysis that correlates DNS, IP ownership, and headers rather than trusting the CDN layer alone.

What are the x-amz headers and why do they appear?

The x-amz-* headers are custom HTTP headers that various AWS services add to their responses, mostly to carry request identifiers used for debugging and support. For example, S3 returns x-amz-request-id and x-amz-id-2, while CloudFront returns x-amz-cf-id and x-amz-cf-pop. They are not security-sensitive by design and are usually left in place, which makes them reliable fingerprints. That said, a customer can configure CloudFront or a proxy to strip or rename them, so their absence does not rule AWS out; treat their presence as strong positive evidence and their absence as inconclusive.

Can I find out which AWS region a website uses?

Often, yes, at least approximately. AWS publishes a machine-readable ip-ranges.json file that maps every IP range to a region and service. By resolving the site's IP with dig and checking it against that file, you can frequently determine the region (for example us-east-1) and whether the address belongs to EC2, S3, CloudFront, or a load balancer. Reverse-DNS hostnames sometimes embed region hints too, such as compute-1 for the North Virginia region. When the site is fronted by CloudFront, however, you will see the edge location rather than the origin region, so regional attribution is most reliable for origins that are not hidden behind a CDN.

Is AWS the biggest cloud provider?

Yes. AWS is consistently reported as the largest cloud infrastructure provider by revenue and market share, ahead of Microsoft Azure in second place and Google Cloud in third; together these three dominate the market. This ranking is reported quarterly by analyst firms and has held for years. The precise share percentages move from quarter to quarter and vary by how each analyst defines the market, so it is best to rely on the durable qualitative fact, AWS is number one by a clear margin, rather than quoting an exact figure that may be out of date.

Why do AWS-hosted sites sometimes show a non-AWS server header?

Because the public-facing layer may not be AWS even when the origin is. If an AWS-hosted application sits behind a third-party CDN such as Cloudflare or Fastly, the Server header you receive reflects that CDN, not AWS, and the AWS origin is masked. Similarly, the web server software running on an EC2 instance (Nginx, Apache, or IIS) will populate the Server header rather than AWS itself, since EC2 is just a virtual machine. The lesson is that the Server header alone rarely tells the whole story; combine it with cookies, reverse DNS, and IP-range checks for an accurate picture, as explained in our guide on how to read a website's HTTP headers.

Need to see past the CloudFront edge and confirm whether a site's true origin runs on AWS? Run a server-side analysis with StackOptic.