Set a upper bound on the length of the message, and everything within it -- constrain string lengths, numeric ranges, nesting depth, etc. This should be built into the parser. Discard messages that are truncated, malformed or don't conform to the schema (don't forget to check types...).
Load balancing is ultimately your call, and HTTP might be the simplest solution if very quick turnaround is critical. But don't be afraid of the Internet's plumbing, understanding it will make you a better engineer. For example, you can still have fail-over to any of the DNS A records (completely transparent with any decent HTTP/websocket client), or if you're seriously concerned about availability, anycast/multihoming. But I'd put money on you having more downtime due to errors on your end or with your provider, than with DNS.
Basically, these problems have been studied for a long time, so it's valuable to be comfortable with the various approaches. FWIW, adding extra A records is just a couple clicks on Linode, and they don't make you pay for each request to boot, unlike S3.