我们有IP地址的，这是很难管理的单一安全组一个长长的清单。 AWS使它成为感觉像你可以有嵌套组，但你不能。我对吗？
背景
我没有与配置和使用安全组的任何问题。问题更加细微，这确定了背景。
我们有安全组配置为白名单获得发展实例/服务。由于我们的配置模式是白名单，我们不断必须随时添加新的IP地址，具体取决于团队成员的工作地点。而蹩脚的ISP没有静态IP地址。
这不是问题所在。但是，描绘出越来越多的IP地址。
问题
有时候我们想删掉这个白名单（因为蹩脚的互联网服务供应商），并确保该IP地址是相关的，跟上时代的，仍然应该是在白名单。
我们发现自己不愿意这样做，因为目前白名单是斌的唯一途径，有效地“清洁”，并开始了。
AWS似乎并没有出现在安全组规则或者标签记录一个整洁的方式，或允许嵌套安全组。
当前变通
有单独的安全组的很多（可能几百个），并确保这些总是连接到相关的服务。
优点：易于标记/识别IP地址（例如Bob的家庭IPS）所以Bob可以删除旧的IP地址，并与他更换新的。
缺点：每个安全组必须连接到相关的实例，这个名单可以变得很长。
保持一个独立的IP /查找列表，并有一个安全组
临：意味着你只需要一个安全组。
缺点：由于必须保持两个列表上最新的，不是很实用，你会得到错误的结果。
某种自动化。构建定期检查安全组的服务，并将这些IP与一些基本的geo-ip/ISP信息一起存储在DynamoDB中。用作参考。
专业：喜欢＃2，但自动化。由于geo-ip查找永远不会100％准确。对于感觉应该已经存在的东西，必须编写和维护该实用程序。
充满希望的解决方案
子/嵌套安全组。 AWS配置界面实际上意味着您可以执行此操作 - 但不能按预期工作。 EG主要安全组具有允许来自其他安全组的入站流量的规则 - 这些规则又将IP地址逻辑分组在一起。
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
当您指定一个安全组作为源的规则，这使得与源安全组相关的实例访问安全组中的实例。 （请注意，这不会将源安全组中的规则添加到此安全组中。）
我发现该文档有点矛盾。从实验中，它不起作用。
标记每条记录。这显然不存在，并且会成为AWS的功能请求。
我错过了什么吗？其他人如何管理大型安全组织？