Traffic from AWS IP addresses is hitting my server

If your logs are full of addresses that resolve to amazonaws.com, you are in good company. A large share of the internet's servers, crawlers, scanners and SaaS platforms run on AWS. An AWS source address tells you the traffic comes from something hosted there. It doesn't tell you who, and it doesn't make the traffic good or bad.

What an AWS source address usually means

Look the address up and note the service code. It narrows things down:

The lookup says	What is connecting to you
EC2 address space	Something an AWS customer runs: a server, a container, a Lambda function, or a company's NAT gateway. This is the usual answer for crawlers, API clients, webhooks, monitors and scanners, and for attackers.
`CLOUDFRONT_ORIGIN_FACING`	CloudFront fetching content from an origin. If you use CloudFront, that's your CDN. If you don't, someone may have set up a distribution with your site as its origin.
`ROUTE53_HEALTHCHECKS`	Route 53 health checkers probing an endpoint, usually because someone configured a health check against your address.
`API_GATEWAY`	API Gateway making an outbound call, for example an integration that forwards requests to your endpoint.
Service not disclosed	AWS uses the range but doesn't say for what. It can be AWS's own systems.

A reverse DNS name such as ec2-54-…compute-1.amazonaws.com is AWS's generic name for EC2 address space. It doesn't mean an EC2 instance specifically, and it never names the customer.

Benign sources and how to verify them

The rule for every case: verify the source address against a list the sender publishes. User agents and reverse DNS names are easy to fake.

Your own infrastructure. Your NAT gateway, Lambda functions or containers may be calling your own server. Search your account for the address.
Amazonbot. Amazon's crawler identifies itself as Amazonbot and runs from EC2 address space. Amazon publishes its crawler addresses, and it follows robots.txt.
CloudFront. If you serve through CloudFront, origin requests come from the CLOUDFRONT_ORIGIN_FACING ranges. See the CloudFront guide to lock your origin down and log the real viewer address.
Route 53 health checks. Run aws route53 list-health-checks in your accounts. Anyone can point a health check at your address, not only you. The traffic is usually light, and you can block it if you don't want it.
Third-party services. Payment providers, monitoring services, SEO crawlers and chat integrations often run on AWS. Most document their source addresses; for webhooks, check the request signature rather than the IP.
Search engines. Googlebot and Bingbot don't crawl from AWS; both publish ways to verify their crawlers through their own networks. A "Googlebot" user agent from AWS address space is almost certainly fake.

Block, rate-limit or ignore?

Situation	Sensible response
Password guessing or exploit attempts from a handful of addresses	Block those addresses for a limited time (fail2ban and similar tools do this automatically). Report to AWS if it continues.
A crawler or scraper using too much capacity	`robots.txt` for well-behaved bots; a per-address rate limit that returns 429 for the rest
Occasional vulnerability scans	Keep software patched; a web application firewall's managed rules; otherwise ignore
A sustained attack	Block, and report it to AWS with log lines and timestamps

A per-address rate limit in nginx:

# in the http {} block
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

# in a server {} or location {} block
limit_req zone=perip burst=20 nodelay;
limit_req_status 429;

Give blocks an expiry. An EC2 instance gets a new public address from a shared pool each time it starts, so an abuser can move to a fresh address in minutes, while the address you blocked may later belong to a customer you want to hear from.

Why blocking all of AWS backfires

Blocking every AWS range looks like a quick fix. It causes more problems than it solves:

EC2 space isn't just EC2. AWS notes that some services are built on EC2 and use its address space, so blocking EC2 ranges also blocks those services.
Outbound breaks. If the same rules filter outbound traffic, your server can no longer reach S3 (backups, uploads, package downloads), APIs, CDNs, webhooks and update mirrors hosted on AWS. Failed S3 uploads after a "block the clouds" rule are a classic symptom.
Real people get locked out. Corporate networks, VPNs and virtual desktops such as Amazon WorkSpaces can send their users' traffic out through AWS.
Your own services break. Your CloudFront distribution, Route 53 health checks, uptime monitoring and payment webhooks may all come from AWS.
It's a moving target. AWS updates its ranges frequently and without a fixed schedule, and the full list is large enough to strain firewall rule limits.
It doesn't stop determined attackers. They also use other clouds and residential proxies.

If you want to treat data-centre traffic differently, scope it: apply stricter rate limits or a challenge to sensitive endpoints such as login and sign-up, and explicitly allow the services you depend on.

Checklist

Look up the address and note the service code, region and data date.
Check whether it's yours: search your AWS accounts.
Check whether it's an expected service from the list above, verifying by address.
If it's harmful, block that address for a limited time or rate-limit it.
If it's sustained, report it to AWS.

Sources

AWS: AWS IP address ranges (services built on EC2 address space)
AWS: Amazon EC2 instance IP addressing
Amazon: About Amazonbot
nginx: ngx_http_limit_req_module
Google: Verifying Googlebot and other Google crawlers; Microsoft: How to verify Bingbot