http://forums.enterprisedb.com/posts/list/21.page JForum - http://www.jforum.net
Performance issues:
-- Higher network latency for streaming replication, resulting in instances being slightly more out of sync than they could otherwise be.
-- Higher network latency for all PGPool queries that don't go against the master DB (localhost), resulting in reduced perceived performance of the cluster.

Security issues:
-- All traffic coming from PGPool and streaming replication appears as if it is coming from somewhere on the internet, instead of from within the AWS security group, thus there is no way to lock those ports down. I'd be much more comfortable knowing that those ports could only be hit from within the security groups I've given access to, than having the ports wide open to the internet and just trusting in my database user's password to secure my data.
-- Since the traffic is going out to the internet and back it raises the possibility of someone with a network scanner capturing those packets and possibly compromising my data.

Cost issues:
-- Bandwidth usage between AWS EC2 instances is incurred when communicating over the external IP address. It is free when using the internal IP addresses.

So in summary, due to bad configurations generated by Cloud DB I'm going to have a slower cluster, that is less secure, and cost me more money.

For more information on this topic you can read this page: http://aws.amazon.com/ec2/
[quote]If you choose to communicate using your Public or Elastic IP address or Elastic Load Balancer inside of the Amazon EC2 network, you’ll pay Regional Data Transfer rates even if the instances are in the same Availability Zone. For data transfer within the same Availability Zone, you can easily avoid this charge (and get better network performance) by using your private IP whenever possible.[/quote]]]> http://forums.enterprisedb.com/posts/preList/3152/11755.page http://forums.enterprisedb.com/posts/preList/3152/11755.page GMT http://forums.enterprisedb.com/posts/preList/3152/11766.page http://forums.enterprisedb.com/posts/preList/3152/11766.page GMT
Also, if you used the external DNS, instead of the external IP, it will resolve to the internal IP when used within AWS, and the external IP otherwise.]]> http://forums.enterprisedb.com/posts/preList/3152/11767.page http://forums.enterprisedb.com/posts/preList/3152/11767.page GMT I am a bit surprised that this was not originally implemented knowing we have postgresql experts here..
Can you please implement this pretty quick?

Regards,
Hans]]> http://forums.enterprisedb.com/posts/preList/3152/11771.page http://forums.enterprisedb.com/posts/preList/3152/11771.page GMT
Yes, that is our understanding also, but again, we need to test this to make sure we don't break anything else. We are treating this seriously and will keep you posted.]]> http://forums.enterprisedb.com/posts/preList/3152/11779.page http://forums.enterprisedb.com/posts/preList/3152/11779.page GMT
thanks,
Hans]]> http://forums.enterprisedb.com/posts/preList/3152/11818.page http://forums.enterprisedb.com/posts/preList/3152/11818.page GMT