Назад | Перейти на главную страницу

Критерии определения количества AWS VPC для использования в приложениях? Меж-VPC против трафика внутри-VPC

Кажется, я не могу найти никаких конкретных рекомендаций относительно того, что является хорошей практикой в ​​отношении использования одного VPC по сравнению с несколькими для хостинга приложений. это ссылка на сайт затрагивает эту тему, но довольно стар и не дает ответа.

В настоящее время я работаю над миграцией традиционно размещаемой среды, состоящей из около 50 приложений и двух ферм баз данных (SQL Server и Oracle), на AWS; общее состояние составляет около 250 серверов Windows. В настоящее время каждое приложение находится в своей собственной подсети / 24.

Мне дали указание, что каждое приложение и ферма баз данных должны находиться как в своей собственной учетной записи AWS, так и в VPC, и я не уверен в мудрости такого подхода; особенно часть отделения приложений от их баз данных.

Учетные записи меня меньше беспокоят, поскольку это скорее вопрос о выставлении счетов. Но что касается VPC, я пытаюсь понять разницу между, скажем,:

  1. Репликация всей среды в пределах 1 VPC, vs.
  2. Представляем 50 VPC для размещения такого же количества приложений / серверов.

Что следует учитывать при выборе между (1) и (2), или какой-то компромисс посередине. Я просмотрел документы AWS и не нашел четких советов по этой теме.

На мой взгляд, основные различия заключаются в том, что сетевой трафик является внутри VPC и между VPC. Это означает:

Но ни одно из вышеперечисленного не является явной причиной делать что-то так или иначе; в то время как 50 VPC - это довольно много, например, эти цифры находятся в пределах ограничений пиринга.

Что еще мне следует принять во внимание?

Прочие соображения:

Спасибо за любую помощь.

смотреть на Зона посадки AWS и AWS Control Tower для лучшей практики.

Я разработал несколько корпоративных сетей AWS, и вот мои общие рекомендации, когда у вас много рабочих нагрузок в интересующей вас области (полные рекомендации по проектированию целевой зоны - это двухдневный семинар, который я провожу для клиентов)

  • Одна учетная запись для каждого приложения, для каждой среды (например, app1 имеет учетные записи для разработчиков, pre-prod и prod, app2 имеет свои собственные учетные записи и т. Д.)
  • Все ресурсы для каждого приложения, такие как сервер приложений, сервер базы данных и т. Д., Входят в эту учетную запись. Разделение сервера приложений и базы данных между учетными записями увеличивает стоимость без какой-либо реальной выгоды.
  • Учетная запись общих служб может использоваться для того, что нужно большинству приложений - AD,
  • Учетная запись безопасности должна отвечать за охрану, охранные устройства и т.
  • Транзитный шлюз для связи, а также возможность подключения на месте (для решения ваших сетевых вопросов)
  • Подключитесь к серверу каталогов по вашему выбору - локально, в службе AD, Azure AD и т. Д.
  • Используйте AWS Organizations с политиками управления сервисами для разрешений высокого уровня и ролями IAM, чтобы позволить пользователям делать только то, что вы хотите, т. Е. Не позволять им отключать службы безопасности, изменять границы, такие как интернет-шлюз или VPN, и т. Д.
  • Рассмотрите возможность использования общие VPC для снижения затрат на пропускную способность - но будьте осторожны, это непростая тема

Это дает вам хорошую изоляцию и снижает радиус взрыва, но вам нужна приличная автоматизация, так как у вас будет 150 учетных записей. Учетная запись - это просто контейнер для выставления счетов и VPC. Да, вы платите больше за пропускную способность.

Альтернативный вариант снижения затрат на полосу пропускания - все в одном VPC. Это затрудняет изоляцию, контроль и радиус взрыва.

Кроме того, для своего продукта я использую отдельную учетную запись с высокой степенью защиты для резервного копирования prod env. (RDS, S3 и т. Д.) И в другом регионе, из которого запущен prod. Тестирование аварийного восстановления в заблокированной учетной записи проводится каждые 15 дней, чтобы убедиться, что резервные копии работают!