Поддерживает ли AWS Cognito перенос пользователей в новый пул пользователей для предотвращения блокировки шаблона формирования облака?

Question

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

Кто-нибудь знает, как это обрабатывается? Допустим, в будущем я буду разрабатывать новое приложение, в котором будет использоваться другой шаблон формирования облаков. Как заставить новое приложение использовать существующий шаблон формирования облаков? Кроме того, как вы можете разрушить шаблон формирования облака, но сохранить там пул пользователей Cognito, чтобы не потерять пароли и регистрацию пользователей?

Я не ожидаю здесь примера кода, но мне просто интересно - у нас есть резервные копии и восстановление из экземпляров RDS и ec2, что делает такие вещи абсолютно беспрепятственными для конечного пользователя. Существует ли эквивалентный процесс предотвращения блокировки в пуле пользователей на протяжении всей жизни вашей компании, не заставляя их заново создавать свои пароли в новом пуле пользователей?

Answer 1

Вы можете указать DeletionPolicy of Retain для ресурсов, которые должны сохраняться после удаления стека CloudFormation. Обязательно проверьте, работает ли он так, как вам нужно, прежде чем приступить к его использованию.

Обратите внимание, что CloudFormation теперь поддерживает импорт некоторых существующих ресурсов в стек, поэтому вы можете потенциально удалить стек № 1 с сохранением ресурса, а затем импортировать этот ресурс в стек № 2.

Кроме того, существуют ситуации, в которых создаются важные долговременные постоянные хранилища данных (например, сегменты S3, базы данных RDS, Cognito). пользовательские пулы и т. д. c.) лучше выполнять вне стека CloudFormation вашего приложения, например, в их собственном выделенном стеке CloudFormation.