You obviously encrypt your stuff before putting it on any cloud. Pre-NSA-infiltration TrueCrypt with a proper password works fine enough. That's what I do. While theoretically all encryption can be broken, spending 100 years and a lot of money on someone's trading system isn't realistic - it's much easier to break into your your PC.
www.speedytradingservers.com Our servers are based in downtown Chicago, 1 ms away from CME order matching servers and market gateway servers of most popular brokers/clearing firms, in one of the best data centers in town. We also provide servers New-Jersey, near the main equities exchanges data centers (NYSE in Mahwah, Nasdaq in Carteret, BATS in Secaucus). As an example, from our NJ servers, the latency to FXCM servers in around 1.10 ms, and 2.30 ms to Interactive Brokers servers in Connecticut. These servers have a 1000 Mbit/s network connection to Internet.
So you just have to trust what they say? How do you actually evaluate 1. the latency from VPS to brokers and 2. from brokers to exchange? Every service provider and broker say they are fast, but how do you check if you are latency-sensitive?
Start a free trial with the service provider and evaluate if the product is right for you, every provider and broker have different infrastructure that meets different needs
A few considerations: - It is clear that the strategies you are running are not latency sensitive. Therefore, colocation is not needed. - It's unlikely you will need much firepower for development. Any cheap/modern setup would do. - Your bottleneck will be the internet. - There is no way to ensure that your flow is protected. Since you are routing through a broker, anyone at that level will see that flow. I think this is irrelevant at this level of trading.
You would timestamp an outgoing message from your trading engine (which presumably logs all messages), this message is routed to your broker, who then routes the order (after risk checks etc) to the exchange gateway. When the exchange sees the order, they will provide a timestamp as well. Depending on the message type, you will get some response from the exchange. When this is read off your network card it will be logged as well. In this case you have 3 times, when a message was sent, when it was processed by the exchange, and when a response was sent back to you. The time between the first two is how quickly your engine can respond; however, you will be stale by the time from exchange to network card. If you're talking latency dependent alphas, you would need sub millisecond latency. Note you will incur latency from being routed over shared sessions through your broker to the exchange as well. Although a dedicated session seems pointless if you're not properly colocated.
@globalarbtrader you make good points as always but I'm surprised you need that much specs for a trading machine. I use a Linode with 4GB memory and 48GB SSD for $20 a month, and it easily handles day to day trading across multiple securities, guarantees 24/7 connectivity, easy remote connection through ssh/vnc/more advanced options... and the actual number crunching / database can sit on a home desktop easily. It also enables me to separate the research machine (full of bugs and testing) from the trading machine (simple, clean, as bug-free as possible).
You're right that part the data could be separated out on to a home machine, but that defeats the only point of a virtual machine for me - I don't have to worry about the cat chewing the cable between the router and the machine, or the home machine exploding in a puff of smoke. I probably don't need more than 4GB RAM for my current daily system, but I'm looking at playing with intraday systems which will need more oomph. GAT