Guides

Amazon.com Architecture Explained: How the Amazon Shopping Site Works

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 18 October 2026 · Last updated: 18 October 2026

Short answer: Amazon.com is built from hundreds of small services. Each service owns its own data and is run by its own team ("you build it, you run it"). One product page can call more than 100 services. Today the shopping site runs on AWS, Amazon's own cloud: in 2019 Amazon's consumer business moved about 7,500 Oracle databases to DynamoDB, Aurora, RDS and Redshift. On Prime Day 2025, DynamoDB peaked at 151 million requests per second for Amazon.

Suppose you open Amazon and search for a phone

You open the Amazon app in Kolhapur, search for "phone under 15000" and open a product page. You see the price, delivery date, reviews, "frequently bought together" and offers. Each of these boxes comes from a different service.

1. Your app sends the request to Amazon. Static files like images come from CloudFront, the AWS CDN.
2. An application server that builds pages receives the request.
3. It calls many small services in parallel: price, stock, delivery date, reviews, recommendations, offers.
4. Each service reads its own data. Fast lookups use DynamoDB or ElastiCache; order and money data use relational databases like Aurora.
5. The page server puts all the answers together into one page.
6. If one small service is slow (for example "frequently bought together"), the page can still show without that box.

Back in 2006 the Amazon.com gateway page called more than 100 services to build the page for you.

What architecture style does Amazon.com use?

Amazon is the classic example of a service-oriented architecture (SOA), years before the word "microservices" became popular.

1. Started as a monolith: Amazon.com began as one big application called Obidos, talking to a back-end database. By 2001 the front end could not scale any more.
2. Split into services: each service keeps its data together with its business logic. Other teams can use the data only through the service's published interface.
3. No shared database: no direct database access from outside the service, and no data sharing between services. This lets each team change and scale its database without breaking others.
4. Ownership: each service has one team that designs, builds and operates it. Amazon calls this "You build it, you run it."
5. Purpose-built databases: after the Oracle migration, each team picked the AWS database that fits its job, instead of one database for everything.

In 2007 Amazon introduced Dynamo, a highly available key-value store built for shopping cart-style workloads. Dynamo's ideas influenced many NoSQL databases, and Amazon DynamoDB took its name from it.

Amazon.com architecture diagram (public parts)

This diagram shows only what Amazon.com or its partners have shared publicly. Press Play to follow a request step by step.

What does Amazon.com use? Main technologies

Which cloud provider does Amazon.com use?

Amazon.com runs on AWS. In October 2019 Amazon completed this move: "Migration Complete – Amazon's Consumer Business Just Turned off its Final Oracle Database".

1. More than 100 teams took part, including Alexa, Prime, Prime Video, Kindle, Audible and Zappos.
2. They moved 75 petabytes of data from nearly 7,500 Oracle databases.
3. Low-latency services went to DynamoDB and ElastiCache; transactional workloads went to Aurora and RDS; analytics went to Redshift.
4. Database costs went down by over 60%, latency of consumer-facing apps down 40% and admin overhead down 70%.

How big is Amazon on Prime Day?

Prime Day shows the scale every year. For the 4-day Prime Day 2025, the numbers were:

1. DynamoDB: tens of trillions of calls, peaking at 151 million requests per second.
2. Aurora: 500 billion transactions; 4,071 TB stored.
3. SQS: a record 166 million messages per second; Kinesis Data Streams: a peak of 807 million records per second.
4. CloudFront: over 3 trillion HTTP requests in the Prime Day week; API Gateway: over 1 trillion internal service requests.
5. Lambda: over 1.7 trillion invocations per day; ECS on Fargate: about 107 million tasks launched per day.
6. Graviton processors powered more than 40% of the EC2 compute used by Amazon.com.
7. Amazon ran over 6,800 AWS Fault Injection Service experiments to test resilience before the event.

Prime Day 2024, for comparison

For Prime Day 2024 (17–18 July), the numbers were:

1. DynamoDB: tens of trillions of API calls, peaking at 146 million requests per second, with single-digit millisecond responses.
2. Aurora: 6,311 database instances processed more than 376 billion transactions.
3. CloudFront: a peak of over 500 million HTTP requests per minute, over 1.3 trillion requests in total.
4. ElastiCache: more than a quadrillion requests in a single day.
5. Lambda: over 1.3 trillion invocations.

How does Amazon.com store data?

1. Each service owns its data. There is no single shared Amazon database.
2. DynamoDB for services that need high availability and single-digit millisecond latency at scale.
3. Aurora for services with stable schemas and strong referential integrity.
4. S3 for low-cost long-term storage; Redshift for analytics.
5. Exact table designs of individual Amazon services are not publicly shared.

How does Amazon.com monitor its systems?

1. Service teams run their own services, so each team watches its own metrics and alarms ("you build it, you run it").
2. Prime Day relies on CloudWatch-style metrics, CloudTrail (over 976 billion events in 2024) and GuardDuty for security monitoring.
3. The full internal monitoring stack is not publicly shared in detail.

If we built an app like Amazon.com on AWS (illustrative)

Suppose you want to build "PuneBazaar", a small online shop for local sellers. Here is how you could lay it out on AWS.

1. Network: VPC, subnets, route tables, gateways

1. Create one VPC with CIDR 10.0.0.0/16 in the Mumbai region (ap-south-1).
2. Use two Availability Zones (A and B), so one AZ failing does not stop the app.
3. In each AZ make three subnets: public (load balancer, NAT gateway), private app (your code) and private data (databases, cache).
4. Attach one internet gateway (IGW) to the VPC. Public route table: 0.0.0.0/0 → IGW. This route is what makes a subnet public.
5. Private app route table: 0.0.0.0/0 → NAT gateway, so servers can download updates but nobody can connect in from the internet.
6. Private data route table: only the local VPC route. Use VPC endpoints to reach S3, DynamoDB and SQS without going over the internet.

2. Compute: where the code runs

1. Put an Application Load Balancer in both public subnets.
2. Run separate small services (catalog, cart, orders, payments) on Amazon EKS or EC2 Auto Scaling groups in the private app subnets.
3. Give each service its own database, just like Amazon: no shared tables.
4. Run background workers (send emails, update stock) that read from SQS.

3. Storage and databases

1. S3 + CloudFront for product images.
2. DynamoDB for catalog and stock lookups.
3. Aurora for orders and payments (writer in AZ A, reader in AZ B).
4. ElastiCache (Redis) for carts and sessions.

4. Monitoring

1. CloudWatch alarms on ALB 5xx errors, latency and DynamoDB throttling.
2. X-Ray traces show which service slows a page.
3. Before a big sale, run a load test and an AWS Fault Injection Service experiment.

Request flow diagram

Press Play. The numbered list below the diagram lights up with each step.

Amazon.com versus our AWS design