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

Как организовать проекты в AWS?

В нашей команде мы используем AWS в качестве основного поставщика облачных услуг, и в настоящее время у нас есть 3 проекта, размещенных на их платформе.

В ближайшие недели у нас будет еще 2 проекта, но сначала мы хотим организовать наши проекты, потому что наша нынешняя организация немного неупорядочена.

Мы хотим, чтобы наши проекты были организованы по следующим правилам:

Итак, можно ли организовывать проекты в AWS по ранее упомянутым правилам?

Ваши основные варианты логической организации:

  • Все, одна учетная запись / один VPC с разделением по тегам или подсетям (не идеально)
  • Одна учетная запись / один VPC для каждого приложения в каждой среде (лучше)
  • Одна учетная запись для каждого приложения на среду (IMHO лучше всего подходит для крупных организаций, но имеет некоторые накладные расходы для небольших организаций)

Основные соображения:

  • Легкость включения или предотвращения доступа, особенно если ваши учетные записи интегрированы с AD. Удобно просто добавить кого-то в группу AD, чтобы предоставить им доступ, и удалить их, чтобы отозвать его, они просто принимают на себя роль с политикой, которую вы хотите, чтобы они имели
  • Изоляция между рабочими нагрузками
  • Уменьшение радиуса взрыва
  • Избегайте ограничений API AWS, установленных для каждой учетной записи.
  • Распределение затрат, которое подходит для тегов, но проще для учетных записей (кроме полосы пропускания, если вы используете центральную учетную запись для связи или обратный рейс к локальной сети)
  • Мониторинг
  • Сложность - управлять большим количеством учетных записей может быть труднее, но изоляция приложений также помогает снизить сложность
  • Соответствие требованиям - соблюдение требований PCI может быть проще с отдельными учетными записями, так как вы можете легче продемонстрировать изоляцию

Зона посадки AWS является лучшей практикой AWS в этой области, вам следует ознакомиться с ней. Он использует AWS Organizations, которые действительно полезны для консолидированного выставления счетов и использования политик управления услугами. Транзитный шлюз полезен, если вам нужно настроить связь между учетными записями. Вы не можете просто запустить сценарии зоны посадки и назвать это достаточно хорошим, вам все равно нужно поработать над сетью, безопасностью и управлением пользователями, но это хорошее начало.

Я потратил много времени на обдумывание этого вопроса, это всего лишь краткий ответ. Если вам нужна дополнительная информация, прокомментируйте, и я сделаю все возможное, чтобы расширить свой ответ.