I'm blocking connections from AWS to my on-prem services
Blocks on traffic from AWS and other cloud providers are emerging as a way for small self‑hosters to cut down on bots, scanners, and suspected abuse hitting their on‑prem servers. Critics argue this accelerates the “balkanization” of the internet, breaks access for legitimate users behind VPNs or cloud desktops, and makes small sites invisible to search engines and archives. Supporters counter that search is already dominated by large platforms, cloud IPs are widely treated as second‑class or hostile, and that operators have a right to prioritize human visitors over automated traffic.
Motivations for Blocking Cloud / AWS IPs
- Main motivation: reduce “meaningless, low‑value, non‑human” traffic (scanners, bots, scrapers, spoofed pings) and avoid contributing to model training.
- Author sees the blog and on‑prem services as for humans or known contacts; often shares links directly instead of relying on public discoverability.
- Frustration with cloud providers’ abuse handling (perceived as unhelpful / one‑way) and with expectations of “just scale” to absorb abusive traffic.
- For some, blocking clouds or specific ASNs is a pragmatic response to repeated abusive activity (DoS, DNS amplification attempts, spam, bad crawlers).
Critiques and Concerns About Blocking
- Risk of losing search engine indexing, archive inclusion, and incidental discovery (including by smaller alternative search engines).
- Possibility of collateral damage: blocking cloud IPs can also block:
- VPN exit nodes for individuals and enterprises.
- Desktop / Workspaces‑type services running in clouds.
- Blocking large ranges is seen by some as contributing to Internet “balkanization”; they argue the blockers are themselves driving fragmentation.
- Others argue it’s mostly symbolic: big AI and clouds can buy or obtain data indirectly anyway.
Data Center IP Reputation & Self‑Hosting
- Several comments note that “data center IPs” are already second‑class:
- Completely blocked by some streaming and copyright‑sensitive services.
- Treated as suspicious by CDNs (more CAPTCHAs, stricter rate limits).
- A rough hierarchy is described: residential > mobile > institutional > public cloud/hosting, with clouds being the most heavily filtered.
- This trend is seen as an increasing barrier to self‑hosting.
Alternative Mitigations & Operational Practices
- Suggested alternatives to blanket blocking:
- Rate‑limiting (ICMP, HTTP, etc.).
- Better TLS configuration, redirects, HSTS.
- Using abuse contacts for specific incidents (though experiences with responsiveness vary).
- Some admins accept background scans as “Internet radiation” and instead:
- Harden services, require keys for SSH, VPN‑gate access, or bastion hosts only.
- Use IPv6, WireGuard, OpenVPN, port knocking, or “no‑cat” style access gating.
- There is debate over whether the real issue is technical (traffic volume) or social/legal (data usage, AI training, commercialization).