Как изолировать среду в AWS?

Question

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

1) Front End - React. js

2) Backend - Java (весенняя загрузка)

3) Архитектура - Микросервисы

4) Инфра - AWS

5 CI - Jenkins

Мы разделили разработку на три этапа

Этап 1 - Создание AWS инфра, внешнего сервиса и нескольких внутренних служб с использованием Spring Boot и Весеннее Облако. Сохраняйте использование служб AWS на минимально возможном уровне

Фаза 2 - Создайте дополнительные бэкэнд-сервисы и докеризируйте все

Фаза 3 - Организовать предыдущий этап с использованием Kubernetes и использовать больше AWS сервисов, если требуется

Я на этапе 1 и после прохождения большого количества ресурсов и учебных материалов, мне нужна помощь в создании архитектуры производственного уровня и среды AWS. Есть много отдельных ресурсов, но не нашли много о том, как должна выглядеть реальная система, когда она жива.

как изолировать среды?

Мое понимание - создать организацию, которая будет иметь 5 учетных записей - root, безопасность, shared-services, prod и non-prod aws учетные записи. Непроизводительный может иметь несколько сред при необходимости, таких как тест, этап.

Как-то так

Это хороший подход? вызовет ли это какие-либо проблемы / сложности в развертывании или других действиях с несколькими учетными записями?

Подробная информация о том, чего я пытаюсь достичь, упоминается в вопросе: Архитектура микросервисов производственного уровня в AWS

Я не уверен, есть ли в сети какие-либо ресурсы, на которые я могу сослаться, что объясняет это. если у кого-то есть, я был бы рад go через них.

Answer 1

Да, в моей работе мы используем один и тот же механизм, где все пользователи хранятся в учетных записях AWS. Каждый продукт имеет свои собственные вспомогательные учетные записи Dev, Staging и prod AWS. Разработчики принимают роли в своих собственных учетных записях.

Мы занимаемся этим последние 3 года.

Преимущества, которые я могу себе представить,

1. простота добавления или удаления разработчиков и предоставления учетных записей для указанных c учетных записей
2. Ресурсы изолированы средой
3. Вы можете избежать конфликтов имен, например, мы можем назвать лямбду Pricing-calculate во всех трех средах

Единственная трудность, которую я могу вспомнить с этой настройкой, это когда мы используем некоторые Такие команды, как serverless, каждый раз запрашивали код MFA. Мне пришлось установить переменные окружения для учетных данных в текущей оболочке терминала, чтобы избежать этого вместо использования профилей.

Надеюсь, это поможет.