The last requirement for the communication stack is a protocol for product-specific messages to support your feature set. This is the real Wild West of IoT at present, because few established standards have emerged for controlling specific classes of devices.
Lack of standardization has opened the door to aggregation solutions such as Revolv that attempt to simplify cross product management. There also are convenient standard message description formats such as XML, JSON, and GPB that can ease message exchange with the back office.
Choices here depend on factors such as the CPU and memory limits of your product. Operating and development costs may also be a concern.
If you choose to host your back office on Amazon Web Services or GAE you are paying proportional to resource use. Optimizing resources is of great interest if your product is connected 24/7 and frequently communicating.
Hosting service providers strongly encourage the use of established frameworks such as HTTP, REST, and HTML. If you choose a standard or protocol that isn't in the mainstream, development effort may be substantially increased.
Finally, you need to consider the presence of firewalls and route-ability. If your IoT device resides behind a firewall it is best to have it establish communication with the Internet back office to circumvent the firewall. Asking consumers to configure their firewalls isn't viable if you want to reach a non-technical consumer base.
Furthermore, not all protocols are routed through the entire Internet. HTTP is the lingua franca of the Internet and is almost universally routed, making it a natural choice. If you choose a different protocol I advise careful consideration of your network topology before proceeding.
Ultimately you will need to evaluate your specific product needs and decide on a communication stack that makes sense for your product. As time progresses I expect more cohesive standards and frameworks will emerge to simplify development.
Next page: A table of recommended protocols