Похоже, я не могу найти никаких конкретных указаний о том, что является хорошей практикой в отношении использования одного VPC вместо нескольких для хостинга приложений. Этосвязьзатрагивает эту тему, но она довольно старая и не дает реального ответа.
В настоящее время я работаю над миграцией традиционно размещенной среды, которая состоит из примерно 50 приложений и двух ферм баз данных (SQL Server и Oracle) в AWS; общее количество составляет около 250 серверов Windows. В настоящее время каждое приложение по сути находится в своей собственной подсети /24.
Мне дали указание, что каждое приложение и ферма баз данных должны находиться как в собственной учетной записи AWS, так и в VPC, но я не уверен в целесообразности такого подхода, особенно в части отделения приложений от их баз данных.
Счета меня волнуют меньше, так как это больше вопрос выставления счетов. Но что касается VPC, я пытаюсь понять разницу между:
- Репликация всей среды в пределах 1 VPC по сравнению с
- Представляем 50 VPC для размещения такого же количества приложений/серверов.
Что следует учитывать при выборе между (1) и (2) или какой-то компромисс посередине. Я посмотрел документацию AWS и не могу найти никаких четких советов по этой теме.
Ключевые различия, как я вижу, это между сетевым трафиком, который идет внутри VPC и между VPC. Это означает:
- теперь есть дополнительная плата, поскольку трафик между VPC стоит денег, а трафик внутри VPC — нет.
- Дополнительная сложность заключается в необходимости выбора, настройки и управления механизмом Inter-VPC, таким как пиринговые или транзитные шлюзы.
Но ни один из вышеперечисленных факторов не является однозначной причиной поступать так или иначе; хотя 50 VPC — это довольно много, рассматриваемые цифры вполне укладываются в рамки, например, пиринга.
Есть ли что-то еще, что мне следует принять во внимание?
- Каковы характеристики производительности для трафика Intra VPC и Inter VPC и т. д.?
Другие соображения:
- Чтобы избежать конфликтов, необходимо управлять блоками CIDR в рамках VPC.
- Максимальный MTU пиринга составляет 1500 байт.
- По умолчанию трафик Inter-VPC не шифруется.
- Осложнения DNS.
Спасибо за любую помощь.
решение1
Посмотри наЗона посадки AWSиAWS Диспетчерская вышкадля лучшей практики.
Я спроектировал несколько корпоративных сетей AWS, и вот мои общие рекомендации на случай, если у вас много рабочих нагрузок в интересующей вас области (полные рекомендации по проектированию целевой зоны — это двухдневный семинар, который я провожу для клиентов).
- Одна учетная запись на приложение, на каждую среду (например, app1 имеет учетные записи для dev, pre-prod и prod, app2 имеет свои собственные учетные записи и т. д.)
- Все ресурсы для каждого приложения, такие как сервер приложений, сервер базы данных и т. д., идут в этот аккаунт. Разделение сервера приложений и базы данных по аккаунтам увеличивает стоимость без какой-либо реальной выгоды.
- Учетная запись общих служб может использоваться для вещей, которые необходимы большинству приложений — AD,
- Учетная запись безопасности должна владеть навыками охраны, охранных устройств и т. д.
- Транзитный шлюз для коммуникаций, а также локальное подключение (что решает ваши сетевые вопросы)
- Интеграция с сервером каталогов по вашему выбору — локальным, службой AD, Azure AD и т. д.
- Используйте организации AWS с политиками управления сервисами для разрешений высокого уровня и ролями IAM, чтобы разрешить пользователям делать только то, что вам нужно, т. е. не позволяйте им отключать службы безопасности, изменять границы, такие как интернет-шлюз или VPN и т. д.
- Рассмотрите возможность использованияобщие VPCдля снижения расходов на полосу пропускания - но будьте осторожны, это довольно скользкая тема
Это дает вам хорошую изоляцию и снижает радиус вашего взрыва, но вам нужна приличная автоматизация, поскольку у вас будет 150 аккаунтов. Аккаунт — это просто контейнер для выставления счетов и VPC. Да, вы платите больше за пропускную способность.
Альтернатива, чтобы сократить расходы на полосу пропускания, — все в одном VPC. Это делает изоляцию, контроль и радиус взрыва проблемой.
решение2
Кроме того, для моего продукта я использую отдельную, строго защищенную учетную запись для резервного копирования среды prod. (RDS, S3 и т. д.) и в другом регионе, из которого запущен prod. Тестирование аварийного восстановления в защищенной учетной записи происходит каждые 15 дней, чтобы гарантировать работу резервных копий!