我目前正在研究高stream量高可用性网站的架构。
我们正在使用AWS。
目前，我们有：
路线53 – > ELB – >多个EC2实例 – > RDS多AZ。
每个EC2实例运行Varnish + Nginx和PHP FCGI。 会话和其他一些共享数据通过ElastiCache存储。
我们计划在每个EC2实例上运行Varnish和Nginx，因为这样可以减less故障点，并在负载增加时运行额外的实例。
但是，我们必须添加iptables（fail2ban）。 当然，我们获得ELB的IP而不是真正的客户端IP …
我们想到了以下解决scheme：
1）在Route 53和ELB之间添加一个EC2实例，运行iptables / firewalls（也可能是varnish？）并将所有内容转发到ELB。
2）用运行HAProxy + iptables的自定义EC2replaceELB。
3）使用mod_security并构build一些自定义的东西来dynamic地将IP列入黑名单
4）坚持目前的架构，并从我们的待办事项列表中删除iptables。
什么是一个好方法？
谢谢
当然，我们获得ELB的IP而不是真正的客户端IP …
你会想要使用x-forwarded-for头，这将给你的客户端IP。
当您使用HTTP / HTTPS负载均衡器时，X-Forwarded-For请求标头可帮助您识别客户端的IP地址。
这里有一些你可能感兴趣的东西
AWS提供了两个很好的安全特性，它们在iptables的相同区域中运行：
安全组（考虑replace为iptables）使您能够根据ip和端口来允许/拒绝stream量。 还有其他function可以提供另一个AWS资源来代替IP地址。
networkingACL可以进一步控制networking。 您可以根据VPC内部和子网内的IP和端口来允许/拒绝stream量。
如果您希望在您的EC2上添加额外的安全措施（如fail2ban），并且您在负载均衡器后面使用多个EC2，则需要deviseEC2，以便它们没有任何唯一的数据（如果EC2＃2不在EC2＃2上，则添加规则EC2＃1是没有意义的）。
有一些技术可以使EC2彼此保持同步，例如在S3上存储数据，从主服务器上拉取configurationpipe理，或者从同一个回购站点提取内容。 使用金色图像以及引导脚本（从S3中提取数据）。
1）在Route 53和ELB之间添加一个EC2实例，运行iptables / firewalls（也可能是varnish？）并将所有内容转发到ELB。
在ELB前添加一个EC2实例会降低您的扩展能力。 你也创build了一个单一的失败点，所以你可能不想这样做。
2）用运行HAProxy + iptables的自定义EC2replaceELB。
你可以做到这一点，但它是以自己pipe理它为代价的。 你成为负责软件，安全，更新，可用性等。你想避免这个如果可能的话（即只有这样做，如果你不能解决问题使用ELB）。
3）使用mod_security并构build一些自定义的东西来dynamic地将IP列入黑名单
这是一个选项，但您可能需要在操作系统/networking级别pipe理安全性，而不是（仅）在软件/应用程序级别。
4）坚持目前的架构，并从我们的待办事项列表中删除iptables。
当然，这是一个select，但这是可以接受的业务/项目？