Я ищу несколько хороших шаблонов и анти-шаблонов для развертывания зеркальных сред (для простоты скажем, экземпляр EC2, а также корзину RDS и S3, что является довольно распространенной установкой). Допустим, мы должны делать это сотни или даже тысячи раз. Я обдумывал некоторые идеи, например
Несколько учетных записей - одна цель - использовать все регионы
noisy neighbors, Модули TF или шаблоны CloudFormation не будут сложнымиЕдиный счет - многоцелевой
Я ищу другие способы сделать это и почему они будут плохими (техническая задолженность, невозможность обслуживания) или хорошими (легко повторно используемыми и т. Д.)
Бесконечно благодарен
Итак, несколько общих моментов, которые можно сказать по этой довольно сложной теме - это во многом зависит от того, чего вы действительно пытаетесь достичь.
У вас есть три варианта:
Одиночный VPC - единый набор больших подсетей - в вашем примере это будет 4 - 2 «общедоступные» подсети и 2 «частные» подсети. Затем используйте группы безопасности для изоляции «развертываний» - я вижу никаких преимуществ от использования подсетей для разделения, кроме необходимости управлять пространством IP-адресов и множеством подсетей. В конечном счете, единственная разница между подсетями обычно заключается в следующем: AZ / route-table / nacl / dhcp-options - используйте новую подсеть только в случае изменения одной из этих подсетей. Подсеть сама по себе не создает проблем с «шумным соседом». Это не домен уровня 2 в классическом смысле слова «vlan», а исходящий интернет-шлюз масштабируется по горизонтали без ограничений, согласно: Вопросы и ответы по Amazon VPC
Несколько VPC - если у вас была одна учетная запись - у вас может быть несколько VPC в регионе, мягкое ограничение составляет 5 VPC, но жесткое максимальное значение:
Количество VPC в регионе, умноженное на количество групп безопасности на VPC, не может превышать 10000.
Что довольно много, в вашем примере вы могли бы сказать, что может быть 4 группы безопасности (ELB, EC2 ASG, RDS, доступ администратора), то есть теоретически это означает 2500 VPC? Я не слышал, чтобы у кого-то это было, но это может быть вариант.
Тем не менее, еще одна вещь, о которой следует подумать в зависимости от того, насколько автоматически масштабируется ваша платформа, являются ли некоторые ограничения для всей учетной записи, и если вы используете их для одного развертывания, это может повлиять на другое, например просто количество экземпляров определенного типа или ограничения одновременного выполнения Lambda. Итак, это приводит к третьему варианту ...
Несколько учетных записей - теперь вы можете создавать новые учетные записи через API благодаря API AWS Organizations, однако на странице ограничений, к сожалению, неясно, какое это ограничение с точки зрения количества учетных записей. Хотя я слышал о более крупных предприятиях с тысячами счетов. Видеть: Ограничения AWS-организаций и Как использовать AWS Organizations для автоматизации сквозного создания учетных записей
В целом для вашего варианта использования вам понадобится чистый стек CloudFormation, который можно полностью повторно использовать с минимальными вариациями - просто для согласованности развертывания, операций и поддержки. Для меня это указывает либо на VPC как на единицу развертывания, либо на учетную запись как единицу развертывания. Вам нужно будет внимательно следить за ограничениями в обоих случаях. Выполнение этого в VPC, будь то с большими подсетями или разделенными по подсетям, в конечном итоге станет беспорядочным в обслуживании - мое субъективное мнение.