On Apr 6, 2013, at 6:51 PM, David Boreham wrote: First I need to say that I'm asking this question on behalf of "a friend", who asked me what I thought on the subject -- I host all the databases important to me and my livelihood, on physical machines I own outright. That said, I'm curious as to the current thinking on a) whether it is wise, and b) if so how to deploy, PG servers on AWS. As I recall, a couple years ago it just wasn't a wise plan because Amazon's I/O performance and reliability wasn't acceptable. Perhaps that's no longer the case.. Tomas gave you a pretty good run-down, but I should just emphasis that you need to view AWS instances as disposable, if only because that's how Amazon views them. You have multiple AZs in every region.... use them for replication, because its only a matter of time before your master DB goes offline (or the entire AZ it's in does). So script up your failover and have it ready to run, because you will need to do it. Also, copy data to another region and have a DR plan to fail over to it, because history shows AZ aren't always as independent as Amazon intends. Of course, these are things you should do regardless of if you're in AWS or not, but AWS makes it more necessary. (Which arguably pushes you to have a more resilient service.) Also, if you go the route of CC-sized instances, you don't need to bother with EBS optimization, because the CC instances have 10Gb network links already. Also, if you go the ephemeral instance route, be aware that an instance stop/start (not reboot) means you loose your data. There are still too many times where we've found an instance needs to be restarted, so you need to be really, really ok with your failover if you want those local SSDs. I would say synchronous replication would be mandatory. Overall I won't say that you can get amazing DB performance inside AWS, but you can certainly get reasonable performance with enough PIOPs volumes and memory, and while the on-demand cost is absurd compared to what you can build with bare metal, the reserved-instance cost is more reasonable (even if not cheap). |