How to report abuse from an AWS IP address
AWS has a Trust & Safety team that handles reports about its customers' resources: attacks, spam, phishing, malware, objectionable content and copyright. A useful report takes a few minutes. Confirm the address is AWS, check that it really is abuse, collect timestamps and log lines, and send them through the official channel.
1. Confirm the address is AWS
Look the IP up first. Reports about addresses AWS doesn't operate go nowhere.
- In AWS's published ranges: AWS is the right place to report.
- Not listed, but announced by an Amazon network: still report to AWS. It may be a customer's own address block brought to AWS, or Amazon space AWS doesn't publish. The ASN check tells you which.
- Announced by another network: report to that network instead. Its abuse contact is in the whois or RDAP record for the address.
For email, look at the full headers of the message. Mail sent through Amazon SES passes through servers whose names end in amazonses.com, and most SES sending addresses are not in ip-ranges.json, so a "not listed" result is expected for SES.
2. Make sure it's abuse
A lot of traffic from AWS is expected, and some of it is yours. Don't report these:
| What you see | Likely source | How to check |
|---|---|---|
| Regular requests to one URL or port from addresses around the world | Route 53 health checks that someone in your organization set up | aws route53 list-health-checks; the sources are in ROUTE53_HEALTHCHECKS ranges |
| Requests to your origin server from CloudFront | Your own CloudFront distribution fetching content (CLOUDFRONT_ORIGIN_FACING) | Check which distributions use the server as an origin |
Crawling with an Amazonbot user agent | Amazon's web crawler | Compare the source with Amazon's published Amazonbot addresses; control crawling with robots.txt |
| SSH to your EC2 instance from an AWS range | A colleague using EC2 Instance Connect in the console | Check whether the source is in the EC2_INSTANCE_CONNECT range for your region |
| Scans or probes on a schedule | A vulnerability scanner, uptime monitor or penetration test your organization pays for | Check the vendor's published source addresses |
| Traffic from an address in your own account | Your NAT gateway, Lambda function or container | See find the resource in your account |
Never trust a user agent on its own; anyone can send Amazonbot. Verify the address.
Port scans and login probes are on AWS's list of reportable activity. Occasional background noise, though, is usually better handled by blocking or rate-limiting it yourself. Report when activity is sustained, targeted or harmful.
3. Gather the evidence
AWS asks for:
- Network activity (attacks, scans, brute force): the target IP address, timestamps with the time zone, and log samples that show the activity.
- Content (a phishing page, a malware download, other objectionable content): the URL and a description of the problem.
- Copyright: a valid DMCA notice.
- Many IP addresses: a CSV file with the IP address, an ISO 8601 date-time and the network log details for each.
What makes a report actionable:
- Unambiguous time. Use UTC or an explicit offset:
2026-09-24T14:03:11Zor2026-09-24T16:03:11+02:00. Without a zone a timestamp can be hours off, and AWS addresses change hands. - Raw log lines, not a summary. Copy them as they appear in your logs.
- Enough context. Make sure the log lines show the source address and the port that was targeted.
- Recent evidence. The older the log, the more likely the address has moved to another customer.
- Nothing extra. Leave out personal data about your own users that AWS doesn't need.
ip,timestamp,log
192.0.2.10,2026-09-24T14:03:11Z,"sshd[2211]: Failed password for root from 192.0.2.10 port 51234 ssh2"
192.0.2.10,2026-09-24T14:03:12Z,"sshd[2211]: Failed password for root from 192.0.2.10 port 51240 ssh2"
198.51.100.23,2026-09-24T14:05:40Z,"203.0.113.5:443 POST /wp-login.php 401"The example uses documentation addresses. Use the real addresses from your logs.
4. Send it to the right place
| Channel | Use it for |
|---|---|
| AWS abuse report form | The main route for any report |
| trustandsafety@support.aws.com | Automated reports, or when you can't use the form |
| email-abuse@amazon.com | Spam or malicious email sent through Amazon SES. Include the full message headers. |
| DMCA notice | Copyright complaints |
| Amazon Law Enforcement Guidelines | Requests for customer information from government authorities |
Don't open an AWS Support case: AWS Support can't help with abuse reports. AWS keeps its current instructions in How do I report abuse of AWS resources?
What happens next
According to AWS, Trust & Safety uses your information to investigate, may email you for more details, shares information only with the permission of the party that controls the resource, and mediates between you and the customer when needed. In practice:
- You won't be told who the customer is.
- Because details are shared only with the customer's permission, you may hear little about the outcome.
- A report isn't a firewall. Keep blocking or rate-limiting the source in the meantime.
- If the activity continues, or moves to new addresses, send a new report with fresh log lines.
Related guides
- Who owns this AWS IP address?
- Traffic from AWS IP addresses is hitting my server
- How to check if an IP address belongs to AWS
Sources
- AWS re:Post: How do I report abuse of AWS resources?
- AWS re:Post: Abuse reporting FAQs
- AWS: IP address ranges of Amazon Route 53 servers
- Amazon: About Amazonbot