Я разрабатываю архитектуру для системы (построенной на AWS), которая будет иметь несколько различных производственных сред в разных зонах.
Первоначально я подумал, что было бы неплохо использовать 1 VPC для каждой среды, а другой VPC для эксплуатации и обслуживания (OAM), предоставляющий хост-бастион и используемый для ssh-подключений к VPC среды (которые затем могут блокировать весь входящий ssh-трафик от общедоступный Интернет). Каждая среда (env) VPC будет иметь одноранговую связь VPC с OAM VPC.
Проблема с этим подходом заключается в том, что если я хочу получить доступ ко всем VPC env из OAM VPC, каждый из них должен иметь разные диапазоны CIDR. Это имеет два значения:
Альтернативный подход состоит в том, чтобы все VPC окружения были полностью изолированы друг от друга, что означает, что каждый из них может иметь одинаковые диапазоны CIDR. Мне это кажется преимуществом, потому что идентичная среда означает более простое обслуживание и меньшее количество человеческих ошибок. Кроме того, мы можем разместить больше вещей в каждой среде. Но для доступа к ним мне пришлось бы добавить хост-бастион в каждый из них, что а) менее безопасно и б) расточительно.
Есть ли лучший способ согласования этих двух противоречащих друг другу требований (безопасности и соответствия)?
Не используйте перекрывающиеся блоки CIDR, так как это ограничивает ваши возможности подключения - транзитный шлюз и пиринг VPC не будут работать с перекрывающимися диапазонами. Вы усложните себе жизнь.
Пространства частных адресов практически не ограничены. Назначьте каждой учетной записи блок / 16, назначьте каждому VPC блок / 8 или все, что им нужно. Это не сработает, если вам нужно интегрироваться с локальными диапазонами CIDR. Если вам нужен публичный доступ, это все еще работает. Я храню информацию CIDR, записанную в документе Word, который содержит мой дизайн AWS, но вы можете использовать электронную таблицу.
AWS VPC могут иметь добавлены дополнительные диапазоны CIDR если у вас закончится место.
Вам следует изучить использование AWS Control Tower и среды с несколькими учетными записями, а не с несколькими VPC. Узнайте о преимуществах, но ключевыми факторами являются управляемость и радиус взрыва. Для автоматизации потребуется больше работы, но она будет хорошо масштабироваться.
Обычно у меня есть одна учетная запись AWS для каждого приложения в каждой среде, поэтому, если у меня есть три приложения и четыре среды (dev, test, pre-prod, prod), у меня будет 12 учетных записей. Я также использую учетные записи для сетей, безопасности, ведения журналов, аудита и песочницы платформы. Вы защищаете его с помощью Guard Duty, AWS Config, Security Hub, а лучше всего создавать с помощью CloudFormation и какого-либо конвейера.