Seems like you're all set then. 10200v will cover capacity needs for years to come.
Go with DNS/FQDN or raw IP?
With any short-lived connection applications, DNS name-resolution delay should not be taken as lightly as with your typical long-lived web frontend. In AWS, you have Route53 which should be replaced with similar enterprise DNS provider to not lose those valuable milliseconds. If you have any significant number of clients that are not isolated to a single state, go with a DNS service provider that has good global spread.
On the other hand, if you have a few major clients and no minor ones, don't even use DNS/FQDN name. Go solely with IP-port combo API calls for best outcome. When given a choice, a heavy client of your API would much prefer any performance gains over the benefit of using FQDN target in their API calls. Another flaw of using DNS is exposure to risk of service downtime due to DNS problems. The risk is minimal but a DNS provider can go down (i.e. to a DOS attack) and bring down your service with itself. This happened on a massive scale to Dyn DNS clients not too long ago.
BigIP configuration?
Let's look at this once you're past initial setup phase. There are a number of settings to consider, most notably TCP profile, HTTP compression profile, cache (Web Acceleration) profile. Depending on how much response payload there is, and how dynamic it is, we can determine best settings to use. To figure out best configuration, I normally start with default configuration that "just works", and then capture ~50 API calls and responses with full payload and headers to have a reference to work with.
Regards,
Cirrus
