Разделение сред в AWS - PullRequest
Новая
       45

Разделение сред в AWS

1 голос
/ 21 марта 2019

Есть ли передовая практика по разделению сред в AWS?

У меня есть решение, которое использует следующие сервисы:

  • Lambda
  • SNS
  • SQS
  • DyanmoDB
  • API-шлюз
  • S3
  • IAM

Мы еще не живы, но мы приближаемся. К тому времени, когда мы начнем работать, мне бы хотелось иметь надлежащую среду для производства, тестирования и разработки с «разумной» степенью изоляции между ними.

  1. Отдельная учетная запись для среды
  2. Одна учетная запись и отдельный VPC на среду

Я прочитал статью СЕТЬ AWS, ОКРУЖАЮЩАЯ СРЕДА И ВЫ от Charity Majors. У меня плохая сегментация через VPC, но я не знаю, что все сервисы в моем стеке имеют объем VPC? Вот некоторые из моих требований:

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

Я использую организацию AWS.

P.S. Извиняюсь, если это не тот форум, на котором стоит вопрос. Если есть что-то лучше, просто дайте мне знать, и я перееду.

1 Ответ

4 голосов
/ 21 марта 2019

Я рекомендую одну учетную запись AWS для каждой среды. Причины, в произвольном порядке:

  1. безопасность : управлять сложными политиками IAM для создания границ в рамках одной учетной записи действительно сложно; и наоборот, одна учетная запись на среду устанавливает границы по умолчанию: вы можете разрешить кросс-учетный доступ, но вы должны быть очень преднамеренным
  2. аудит доступ к различным средам затрудняется, когда все действия выполняются в одной учетной записи
  3. производительность : некоторые сервисы не имеют одинаковых характеристик производительности при работе в VPC по сравнению с не-VPC (т. Е. Лямбда при холодном запуске увеличивает задержку при работе в VPC)
  4. naming : вместо того, чтобы использовать идентификатор учетной записи AWS для определения среды, в которой вы работаете, вы должны добавить префиксы или суффиксы ко всем ресурсам в учетной записи - это вопрос предпочтения, но тем не менее ..
  5. соответствие : если вам когда-либо понадобится придерживаться какого-либо стандарта соответствия, такого как HIPAA, который налагает строгие ограничения на то, как долго вы можете хранить данные и кто может получить доступ к данным, становится действительно трудно доказать, какой данные являются производственными и какие данные проверяются и т. д. (это относится к № 1 и № 2 выше)
  6. контроль затрат : в средах разработки, тестирования и промежуточного хранения вы можете предоставить людям довольно широкие разрешения для раскрутки новых ресурсов, но ограничить расходы, чтобы предотвратить случайные всплески использования; наоборот, в производственном аккаунте вам понадобится ограниченная способность раскручивать ресурсы, но более высокие ограничения расходов; легко применять через отдельный аккаунт - не так много в одном аккаунте

Я что-то пропустил? Возможно! Но это причины, по которым я бы использовал отдельные учетные записи.

Кстати - я НЕ выступаю против использования VPC. Они существуют по определенной причине, и вы обязательно должны использовать VPC для изоляции сети. Я пытаюсь утверждать, что любой, кто также использует другие сервисы, такие как DynamoDb, Lambda, SQS, S3 и т. Д. - VPC на самом деле не способ изолировать ресурсы, IMO.

Недостатки одной учетной записи на каждом этапе, о которых я могу думать, в основном связаны с непрерывным развертыванием, если вы используете инструменты, недостаточно гибкие для развертывания на разных учетных записях.

Наконец, некоторые люди любят называть биллинг возможной проблемой, но разве вы не хотите знать, сколько денег вы тратите на производство против постановки против развития?!

...