실무에서 비밀번호 교체 직후 배치 작업은 DB에 접속하지 못하는데, 이미 실행 중인 웹 서비스에서는 조회가 계속되는 상황을 자주 마주할 수 있습니다. 이때 먼저 볼 것은 실패한 요청이 DB에 새로 로그인했는지입니다. 기존 연결을 재사용한 조회는 새 비밀번호로 인증이 되는지 보여주지 못합니다. 새 연결에서 인증이 실패했다면 Secrets Manager의 현재 버전, DB가 받는 자격 증명, 앱이 실제로 사용한 값 순서로 범위를 좁혀 보세요.
현재 버전으로 DB에 새로 접속해 보기
먼저 실패한 앱 설정에서 참조하는 시크릿 ARN과 리전, DB 엔드포인트, 접속 계정을 확인합니다. GetSecretValue 요청에 버전 ID와 단계 레이블을 모두 생략하면 Secrets Manager는 AWSCURRENT가 붙은 버전을 돌려줍니다. 이 레이블은 서비스가 반환할 현재 버전을 가리킵니다. 해당 값으로 DB에 로그인할 수 있는지는 별도로 확인해야 합니다.
앱과 같은 DB 엔드포인트를 대상으로, 가능한 한 같은 네트워크 경로에서 현재 버전을 읽어 기존 풀을 거치지 않는 새 연결을 한 번 열어 봅니다. 비밀번호는 테스트 프로세스 안에서만 사용하고 기록에는 버전 ID, 테스트 시각, 성공 여부와 오류 유형만 남깁니다. 연결 시간이 초과되거나 TLS 협상이 실패했다면 네트워크나 TLS 설정부터 확인합니다. DB가 인증을 거부한 경우에는 계정·엔드포인트·비밀번호가 일치하는지 확인합니다.
AWS Secrets Manager GetSecretValue API
테스트 결과에는 ‘현재 버전으로 만든 새 연결’인지 표시해 두면 운영 앱의 결과와 비교하기 쉽습니다.
DB와 시크릿 중 어디까지 변경됐는지 확인
운영자가 시크릿 값만 수동으로 바꿨다면 DB 계정에도 같은 비밀번호를 적용했는지 확인합니다. 반대로 DB에서 먼저 변경했다면 시크릿에 이전 값이 남아 있을 수 있습니다. 두 경우 모두 앱을 재배포하기 전에 어느 쪽의 변경이 끝났는지부터 확인해야 합니다.
Lambda로 자동 교체하는 구성이라면 CloudWatch 로그에서 createSecret, setSecret, testSecret, finishSecret 중 마지막으로 완료된 단계를 찾습니다. 예를 들어 setSecret이 DB 비밀번호를 바꾼 뒤 finishSecret에 도달하지 못하면, DB는 새 값을 요구하는데 AWSCURRENT는 이전 버전을 가리킬 수 있습니다. AWSPENDING은 후보 버전을 나타내므로 레이블만 보고 DB 반영 여부를 판단하기 어렵습니다.
이전 버전으로 되돌릴 때도 DB가 그 값을 받아들이는지 확인해야 합니다. AWSPREVIOUS를 기준으로 저장소의 레이블을 되돌리는 작업은 DB 계정의 비밀번호 변경과 별개입니다.
AWS Secrets Manager Lambda 교체 함수의 네 단계 · AWS Secrets Manager 비밀정보 교체 문제 해결
교체 로그의 마지막 완료 단계와 현재 버전의 새 접속 결과를 함께 보면 복구해야 할 지점을 좁힐 수 있습니다.
실행 중인 앱이 새 값을 받아오는 시점 확인
현재 버전으로는 로그인되는데 기존 앱의 새 연결만 실패한다면 앱이 비밀번호를 언제 읽는지 봅니다. 런타임에 조회하더라도 클라이언트 캐시나 앱 시작 시 만들어진 연결 풀 설정에 이전 값이 남을 수 있습니다. AWS의 Python 캐싱 컴포넌트는 기본 갱신 주기가 1시간입니다. 이 컴포넌트를 쓰는 경우에도 실제 설정과 풀에 새 자격 증명을 적용하는 시점은 따로 확인합니다.
Amazon ECS에서 시크릿을 시작 시점에 환경 변수로 주입했다면 기존 태스크는 새 값을 자동으로 받지 않습니다. 태스크 정의가 이전 버전 ID나 단계 레이블을 명시적으로 참조하는지 먼저 확인합니다. 올바른 시크릿 버전을 가리키면 새 태스크를 시작하거나 서비스에서 새 배포를 시작해 교체합니다. 태스크가 실행 상태가 된 뒤 앱이 새 DB 연결을 열고 가벼운 읽기 쿼리까지 성공하는지 봅니다.
AWS Secrets Manager Python 클라이언트 캐시 · Amazon ECS의 Secrets Manager 환경 변수 주입
새 태스크의 DB 연결을 먼저 검증하면 교체 범위를 넓힐 근거가 생깁니다.
오류 유형별 점검표
| 관찰한 결과 | 우선 확인할 지점 |
|---|---|
| 현재 버전으로 새 연결을 열어도 DB가 인증을 거부함 | 대상 DB·계정이 맞는지 확인하고, 수동 변경 이력 또는 Lambda 교체 단계 확인 |
| 현재 버전 테스트는 성공하지만 기존 앱에서 새 연결이 실패함 | 시크릿 버전 고정, 캐시 갱신 시점, 시작 시 주입된 환경 변수, 풀 설정 확인 |
시크릿 조회에서 AccessDeniedException이 발생함 |
조회 주체의 secretsmanager:GetSecretValue 권한과 고객 관리형 키 사용 시 kms:Decrypt 권한 확인. ECS 환경 변수 주입은 태스크 실행 역할 확인 |
| 기존 풀의 조회만 성공하고 새 연결 결과는 없음 | 같은 DB 엔드포인트에 풀을 우회한 새 연결을 열어 인증부터 검증 |
AWS Secrets Manager GetSecretValue API · Amazon ECS의 Secrets Manager 환경 변수 주입
결론
복구 기준은 현재 시크릿 버전이 바뀐 시점보다 애플리케이션에서 새 DB 연결이 성공한 시점에 두는 편이 좋습니다. 변경 기록에 시크릿 버전 ID와 교체된 앱 인스턴스나 태스크, 새 연결의 인증·쿼리 결과를 같이 남겨 두세요. 다음 교체 때 같은 세 가지 항목으로 어느 단계에서 값이 어긋났는지 확인할 수 있습니다.