웹 및 모바일 애플리케이션 개발자와 협력하는 개발자 옹호자로서 저는 리전별 서비스 중단이 발생할 경우 예상치 못한 상황에서도 일관된 사용자 인증을 유지해야 한다는 이야기를 자주 들었습니다. 에이전틱 AI, 마이크로서비스, 자동화, 서비스 계정의 사용이 증가하면서 시스템 간 인증에도 유사한 필요성이 대두되었습니다. 오늘은 Amazon Cognito에 대한 두 가지 중요한 업데이트를 알려드리게 되어 기쁩니다. 하나는 복원력 향상을 위한 다중 […] ||
웹 및 모바일 애플리케이션 개발자와 협력하는 개발자 옹호자로서 저는 리전별 서비스 중단이 발생할 경우 예상치 못한 상황에서도 일관된 사용자 인증을 유지해야 한다는 이야기를 자주 들었습니다. 에이전틱 AI, 마이크로서비스, 자동화, 서비스 계정의 사용이 증가하면서 시스템 간 인증에도 유사한 필요성이 대두되었습니다. 오늘은 Amazon Cognito에 대한 두 가지 중요한 업데이트를 알려드리게 되어 기쁩니다. 하나는 복원력 향상을 위한 다중 리전 복제이고 다른 하나는 암호화 제어 강화를 위한 고객 관리형 키 지원입니다.
많은 애플리케이션이 Amazon Cognito를 사용하여 사용자-시스템 간 인증을 처리하고 사용자 프로필을 관리합니다. 고가용성을 목표로 구축할 때는 여러 AWS 리전에 걸쳐 일관된 데이터를 보유하는 것이 핵심 접근 방식이었는데, 지금까지는 이러한 일관성을 유지하는 데 상당한 어려움이 있었습니다. 엔지니어링 팀은 리전 간에 구성을 동기화하기 위해 사용자 지정 복제 솔루션을 구축하고 유지 관리하는 데 상당한 시간을 할애했습니다. 리전 간에 사용자 데이터를 수동으로 내보내고 가져오면 잠재적 데이터 노출로 인한 보안 위험이 발생하고 데이터 불일치가 발생할 수 있습니다. 최종 사용자는 리전 전환 과정에서 강제 암호 재설정 및 재인증과 같은 혼란을 겪었습니다. 시스템 간 통신의 경우, 팀은 세컨더리 리전에서 새 앱 클라이언트를 생성해야 했습니다. 즉, 새 리전 발급자가 발급한 액세스 토큰을 수락하도록 애플리케이션을 재구성하고 OAuth로 보호되는 리소스를 업데이트해야 했습니다. 이러한 문제로 인해 여러 전체에서 중단 없는 운영을 유지하기가 어려웠습니다.
다중 리전 복제를 통해 Amazon Cognito는 사용자가 선택한 세컨더리 AWS 리전에 사용자 데이터 및 시스템 비밀의 동기화된 사본을 자동으로 유지 관리합니다. 복제는 프라이머리 리전에서 세컨더리 리전으로 단방향으로 진행됩니다. 여기에는 사용자 프로필, 자격 증명, 풀 구성이 포함됩니다. 세컨더리 리전은 인증 기능 유지에 중점을 두고 읽기 전용 모드로 작동합니다. 기존 세션은 중단되지 않고 계속됩니다.
트래픽을 세컨더리 리전으로 보내야 하는 경우 기존 사용자는 중단 없이 기존 자격 증명으로 계속 로그인할 수 있으며, 두 리전 모두 어느 한 리전에서 발급한 액세스 토큰을 인식하므로 현재 로그인한 사용자는 인증 상태로 유지됩니다. 다중 리전 복제는 소셜 공급자(Amazon, Google, Apple, Facebook)를 통한 페더레이션 로그인, SAML(Security Assertion Markup Language), OIDC(OpenID Connect) 통합을 비롯한 모든 인증 방법 및 API 권한 부여 흐름을 지원합니다. 이 접근 방식은 백엔드 서비스의 고객 대면 애플리케이션과 시스템 간 통신 모두의 가용성을 유지합니다. 인증은 중단 없이 계속되지만 장애 조치 중에는 새 사용자 등록, 프로필 업데이트와 같은 작업을 수행할 수 없습니다.
다중 리전 복제를 구성하기 전에 AWS Key Management Service(AWS KMS)에 저장된 다중 리전 고객 관리형 키를 구성하여 사용자 저장 데이터를 암호화해야 합니다. 이러한 키는 여러 리전에서 일관된 암호화를 제공하는 동시에 암호화 전략을 제어할 수 있게 합니다.
실제 작동 방식
이 데모는 us-west-2(오리건) 리전의 기존 Cognito 사용자 풀에서 시작합니다. us-east-1(버지니아 북부)에 대한 복제를 구성하고 싶습니다. 고객 관리형