An Alternative to Required API Keys

But for a first experimental API, it's much better than having no info on who your users are besides an IP address pointing to AWS. And logging API requests to a text file and doing analytics manually with grep is much faster than setting up developer accounts.

That one is easy to reduce the effect of: as well as a per-IP limit have a per-/24 limit that is much lower then 256 times the single address limit. To avoid seeming to be too unfair to other people on the same ISP who happen to be at an address next to a heavy-but-not-abusive user make this limit's bucket refill more often (i.e. if you limit to 100 requests/day per IP, try 100 requests/hour per 256 address block).

You might consider different granularities instead of or as well as /32 and /24. It is not uncommon for a small organisation to have a /29 or /28 allocated (heck, I have a /29 on my line at home as I host a couple of services from it that need their own address). Perhaps set limits for granularities of /32, /28, /24 and /20? Of course this requires development effort, implementing an efficient method of enforcing these limits, but not lots.

> They will try Tor, then various anonymizer proxies (forcing you to block all of them or give up)

Are there really enough reliable cost-free options out there to make that a massive problem? A few determined people will use more resource than you wont by these methods, but the majority will either put up with the rate limit, pay what-ever you are asking for a less limited option, or do somewhere else (the third option being something you'd prefer didn't happen, of course, but you'll always lose some users by refusing to give them the moon on a stick).

> Amazon EC2 instances or other VPS, or large public proxies / ISP proxies that you cannot block

While you can't block them, you can apply rate limits at multiple granularities as mentioned above to limit their effect. To reduce the effect of ISP proxies on HTTP APIs force the use of HTTPS (less HTTPS traffic goes via a proxy than does HTTP traffic - ISPs that use transparent proxies for HTTP caching don't do the same for HTTPS as there would be no point).

THE THING NO ONE HAS MENTIONED YET

Of course this all changes a little once you consider IPv6. A per address limit is meaningless when everyone has a /64 or wider to play with so you are going to have to implement ranged limits (perhaps with gradiated limits like above for /64, /56, /48, ...) if you are limiting by address, and you are going to limit by ISP when trying to limit by individual more often than you will filtering IPv4 addresses this way (some VPS providers hand out small numbers of v6 addresses to each VM so they presumably use one /64 for everyone, where-as I have a /64 allocated to my home line.

I'd rather see simulated data if it's purely for development purposes. You would have far more control over the conditions you need to test.