AWS Secrets Manager 비용구조 이해하기
“DB 비밀번호, 코드에 하드코딩하지 않고 관리하는 쉬운 방법이 뭘까?”
대부분의 개발자는 한번쯤 이런 고민을 해봤을 것입니다. AWS Secrets Manager는 키 관리의 복잡함을 해결해주는 서비스입니다. 민감 정보를 안전하게 보관하고, 자동으로 비밀번호를 바꾸고, 필요할 때만 꺼내 쓸 수 있게 해줍니다.
하지만 단순히 ‘보안 강화’를 위해 도입했다가 매달 수십 달러의 추가 요금을 보고 놀라는 경우도 많습니다.
Secret 수 증가, API 호출 폭증, 로테이션 오버헤드, 방치된 테스트 리소스…
이 모든 게 은근하게 비용을 부풀리는 보이지 않는 요인들입니다.
이번 글에서는 Secrets Manager에 대해 알아보고, 비용이 발생하는 주요 포인트들을 짚어보도록 하겠습니다.
Secrets Manager란 무엇인가?
AWS Secrets Manager는 클라우드 애플리케이션에서 필요한 민감 정보(Secrets)를 안전하게 저장하고 관리할 수 있도록 제공되는 관리형 서비스입니다. Secrets의 예로는 데이터베이스 자격증명(DB 사용자명 및 비밀번호), API 키, OAuth 토큰, TLS 인증서 등이 있으며, 이 정보들을 안전하게 암호화해 저장하고, 필요할 때 애플리케이션에서 쉽게 호출할 수 있도록 지원합니다.
Secrets Manager는 단순한 저장소 기능을 넘어, 데이터베이스, API, 애플리케이션과의 통합 기능을 제공하여 보안성을 강화합니다. 예를 들면 MySQL, PostgreSQL, MongoDB와 같은 데이터베이스의 자격증명을 자동으로 로테이션(주기적 교체)하고, Lambda, ECS, EC2 인스턴스에서 코드 내 직접 입력 대신 API 호출로 필요한 Secret을 안전하게 로드합니다.
필요에 따라 IAM 정책과 연계해 세분화된 접근 권한을 설정하여, 애플리케이션별로 필요한 최소한의 권한만 부여할 수 있도록 지원합니다. 결과적으로 AWS Secrets Manager는 민감 정보를 안전하게 보호하면서도, 운영과 관리의 복잡성을 줄여주는 핵심 보안 인프라 역할을 수행하며, 보안 모범 사례를 준수한 클라우드 환경을 구축하는 데 중요한 도구입니다.
AWS Secrets Manager는 단순히 민감 정보를 저장하는 데 그치지 않고, 데이터베이스, API, 애플리케이션과의 통합을 통해 보안성을 강화하고, 운영의 자동화 및 효율성을 높이는 데 중요한 역할을 합니다.
데이터베이스 관리
Secrets Manager는 RDS(MySQL, PostgreSQL, MariaDB 등) 및 Amazon DocumentDB와 연계해, 데이터베이스 자격증명의 자동 로테이션 기능을 제공합니다. 관리자는 주기적인 비밀번호 변경 업무를 자동화해 보안성을 강화할 수 있으며, 애플리케이션 측에서는 Secret ID를 통해 항상 최신 자격증명을 안전하게 불러올 수 있습니다.
API 및 애플리케이션 관리
Lambda 함수, ECS, EC2, 서버리스 애플리케이션 등 다양한 서비스에서 Secrets Manager API를 호출해 필요한 Secret을 안전하게 가져올 수 있습니다. 이를 통해 코드 내 민감 정보를 직접 포함하지 않아도 되고, 런타임에 최신 값을 안전하게 로드할 수 있어 보안 리스크를 최소화할 수 있습니다.
자동화된 접근 관리
IAM과 연동하여 애플리케이션 또는 서비스 계정별로 최소 권한 원칙(Least Privilege)을 적용해 Secret 접근을 엄격히 제어할 수 있으며, 필요한 서비스만 Secret을 조회할 수 있도록 설정해 보안 위협을 차단합니다.
이러한 통합 관리 기능을 통해 Secrets Manager는 단순한 저장소를 넘어 운영 자동화, 접근 제어, 비밀번호 교체 및 보안 모범 사례 준수를 위한 강력한 보안 관리 플랫폼으로 활용됩니다.
비밀번호 변경 자동화
Secrets Manager의 로테이션(rotation)은 비밀번호를 주기적으로 바꾸는 자동화 작업을 말합니다.
운영 중인 MySQL의 DB 계정 비밀번호가 있다고 가정해 보겠습니다. 3개월에 한 번씩 보안상 이유로 비밀번호를 바꿔야 합니다. 이때마다 콘솔에 접속해서 DB 비밀번호를 변경하고, 애플리케이션 코드나 설정 파일에서 그 새 비밀번호로 갱신해야 합니다. 이 과정은 번거롭고 사람이 실수할 가능성이 있습니다.
Secrets Manager의 자동 로테이션은 비밀번호를 일정 주기로 안전하게 바꿔줍니다. 바뀐 비밀번호는 Secrets Manager에 자동으로 저장되고, 애플리케이션은 비밀번호를 하드코딩하지 않고 Secret ID로 불러오기 때문에, 항상 최신 비밀번호를 자동으로 사용합니다. 당신은 아무것도 손대지 않아도 보안이 유지됩니다.
과금 모델 이해
Secrets Manager의 과금 체계는 아래 링크를 통해 자세하게 확인할 수 있습니다.
Secrets 개수
AWS Secrets Manager는 저장되는 Secret의 개수 기준으로 요금을 부과합니다. Secret 1개당 월 $0.40의 고정 요금이 청구되며, Secret의 크기는 최대 64KB까지 포함됩니다. 즉, 크기가 64KB를 초과하지 않는 한 추가 저장 요금은 발생하지 않으며, Secret 개수만큼 요금이 청구됩니다.
예를 들어, 10개의 Secret을 보관 중인 경우, 별도의 API 호출 없이 저장만 하는 상태에서도 10개 × $0.40 = 월 $4.00의 비용이 기본적으로 발생합니다. Secret 개수는 작은 단위로 관리되는 경우 불필요하게 증가할 수 있으므로, 비슷한 목적의 Secret은 통합 관리하거나, 환경별로 과도하게 Secret을 분리하지 않도록 주의하는 것이 비용 최적화의 핵심 전략입니다.
API 호출
AWS Secrets Manager에서는 Secret을 저장하는 요금과 별개로, Secret을 조회하는 횟수(GetSecretValue 호출)에 따라 별도의 API 호출 요금이 부과됩니다. 요금은 Secret 조회 요청 10,000건당 $0.05이며, 조회 횟수가 많아질수록 비용이 누적됩니다.
예를 들어 애플리케이션에서 하루 1,000회의 Secret 조회 요청이 발생한다면, 한 달(30일 기준) 약 30,000회 조회합니다. 비용은 월 $0.15 발생하게 됩니다.
주요 특징
Secret 생성(CreateSecret), 삭제(DeleteSecret), 업데이트(UpdateSecret) 등의 관리 요청은 무료
조회 요청(GetSecretValue 호출)에만 과금 발생
API 호출 요금은 소액이지만, Secret을 자주 조회하는 애플리케이션에서는 누적 호출로 인해 비용이 예상보다 높아질 수 있으므로, 애플리케이션 측 캐싱을 통한 호출 빈도 최소화가 중요합니다.
Secrets 생성, 저장, 로테이션 주기 등의 사용량에 따라 요금 부과
AWS Secrets Manager의 요금 체계는 단순히 Secret 저장 요금과 API 호출 요금뿐만 아니라, 로테이션 주기 등의 사용 방식에 따라 비용이 달라질 수 있고 KMS 연동에 따른 간접 비용도 있습니다.
로테이션 주기 관리 Secrets Manager는 Secret의 자동 로테이션 기능을 제공하며, 로테이션 주기 자체는 무료이지만, 로테이션 수행 중 발생하는 API 호출(특히 GetSecretValue 호출)이 요금 부과 대상이 됩니다. 예를 들어, 매일 로테이션을 수행하면 매일 최소 1회의 GetSecretValue 호출이 발생하고, 로테이션 주기가 짧을수록 호출 횟수가 늘어나기 때문에, API 호출 요금이 함께 증가할 수 있습니다.
KMS 연동에 따른 추가 요금 Secrets Manager는 KMS(Key Management Service)를 사용해 Secret을 암호화합니다. Secret을 저장하거나 조회할 때 KMS 키를 호출하는데, KMS 호출 자체(예: Decrypt 요청)는 별도의 요금(1,000건당 약 $0.03)이 발생할 수 있으므로, KMS 비용도 간접적인 요금 요소로 고려해야 합니다.
결과적으로 Secret의 개수, 조회 빈도, 로테이션 주기, 그리고 KMS 사용량이 전체 Secrets Manager 비용에 영향을 미치는 핵심 요소이며, 이를 종합적으로 관리하고 최적화하는 것이 비용 절감의 핵심 전략입니다.
비용 발생 포인트
Secrets 개수 관리
AWS Secrets Manager는 Secret 하나당 월 $0.40의 고정 요금이 발생하기 때문에, 동일한 성격의 자격 증명이 여러 개의 Secret으로 중복 저장되어 있을 경우 불필요한 비용이 누적될 수 있습니다.
예를 들어, 하나의 데이터베이스에 접근하는 사용자 자격 증명을 환경(dev, staging, prod)이나 팀별로 별도 Secret으로 저장하는 사례가 종종 발생합니다. 하지만 자격 증명이 동일하거나 유사하다면, 하나의 Secret을 파라미터로 구분하거나 통합해서 관리하는 것이 보다 경제적입니다.
또한, 동일한 인증 정보를 사용하는 애플리케이션 여러 개가 각각 Secret을 별도로 생성해 사용하는 경우, 이는 불필요한 비용뿐 아니라 관리 복잡도도 증가시킵니다. 이런 경우에는 공통된 Secret을 중앙에서 관리하고, 필요한 IAM 권한만 분리하여 접근 제어하는 방식이 더욱 효과적입니다.
따라서 Secret 생성 시점에 “정말 별도로 관리해야 하는 민감 정보인가?“를 판단하고, 재사용 가능한 Secret은 통합해 관리함으로써 월별 과금 대상인 Secret 개수를 최소화하는 것이 비용 절감의 첫걸음입니다.
API 호출 빈도 관리
AWS Secrets Manager는 Secret을 조회할 때마다 GetSecretValue API가 호출되며, 1만 건당 $0.05의 추가 비용이 발생합니다. 단위 비용은 적지만, Secret을 자주 조회하는 애플리케이션 환경에서는 호출 횟수가 쉽게 수백만 건을 넘어 비용이 눈덩이처럼 불어날 수 있습니다.
예를 들어, EC2 인스턴스나 Lambda 함수가 매 요청마다 Secrets Manager에서 자격 증명을 실시간 조회한다면, 성능 저하뿐 아니라 비효율적인 과금이 발생합니다. 이 문제를 해결하기 위해서는 다음과 같은 캐싱 전략 적용이 필수적입니다.
메모리 캐싱: 애플리케이션이 Secret을 최초 조회한 후 메모리에 일정 시간 보관하여 재사용
환경 변수 활용: 초기 기동 시 Secret을 불러와 환경 변수로 저장하고, 런타임에 참조
보안 민감도에 따른 Secret 관리 전략
클라우드 환경에서 애플리케이션의 보안을 유지하는 것은 매우 중요하며, 특히 민감한 정보(Secret)를 어떻게 관리하고 접근하느냐에 따라 전체 시스템의 보안 수준이 결정됩니다. 모든 Secret을 동일한 방식으로 관리하는 것은 비효율적이거나 과도한 보안 비용을 초래할 수 있습니다. 따라서 Secret의 보안 민감도와 변경 빈도에 따라 적절한 관리 및 접근 정책을 선택하는 것이 중요합니다. 이는 보안과 성능, 그리고 운영 효율성 사이의 현명한 절충안을 찾는 과정입니다.
다음은 보안 민감도에 따른 Secret 관리 및 접근 정책에 대한 상세 설명입니다.
민감도가 낮은 값 - 환경 변수 (Environment Variables)
설명: API 엔드포인트와 같이 공개되어도 시스템 전체의 보안에 치명적인 영향을 주지 않거나, 이미 공개된 정보에 가까운 Secret은 가장 낮은 민감도를 가집니다. 이러한 값들은 애플리케이션이 실행되는 환경의 **환경 변수(Environment Variables)**에 직접 저장하여 사용하는 것을 고려할 수 있습니다.
장점: 구현이 매우 간단하고, 애플리케이션 코드 내에 직접 하드코딩하는 것보다 유연성이 높습니다. 개발 및 배포 과정에서 Secret을 쉽게 변경할 수 있습니다.
주의사항: 환경 변수는 해당 시스템에 접근 권한이 있는 사용자나 프로세스에 의해 쉽게 노출될 수 있으므로, 절대 민감한 자격 증명(비밀번호, API 키 등)을 저장해서는 안 됩니다. 오직 민감도가 극히 낮은 정보에만 제한적으로 사용해야 합니다. 메모리나 프로세스 목록을 통해 노출될 위험이 존재합니다.
자주 변경되지 않는 Secret - 캐싱 (메모리 + TTL)
설명: 데이터베이스 연결 문자열, 외부 서비스 API 키 등 비교적 민감하지만 자주 변경될 필요가 없는 Secret의 경우, 캐싱(Caching) 전략을 활용하여 성능과 보안을 절충할 수 있습니다. Secrets Manager와 같은 중앙 집중식 Secret 관리 서비스에서 Secret을 한 번 불러온 후, 애플리케이션 메모리 내에 일정 시간 동안 보관(캐싱)하고 재사용하는 방식입니다.
TTL (Time-To-Live) 적용: 캐시된 Secret은 TTL(유효 시간)을 설정하여 일정 시간이 지나면 자동으로 만료되고 다시 Secrets Manager에서 최신 값을 불러오도록 합니다. 이는 Secret이 노출되더라도 그 유효 기간을 제한하여 위험을 줄이는 동시에, 매번 Secrets Manager에 API 호출을 하는 오버헤드를 줄여 성능을 향상시킵니다.
장점: API 호출 비용을 절감하고, Secret 검색 지연 시간을 줄여 애플리케이션 성능을 향상시킵니다.
주의사항: 캐싱된 Secret은 메모리에 복호화된 상태로 존재하므로, 메모리 덤프나 특정 공격에 취약할 수 있습니다. 캐시된 Secret에 대한 접근 권한을 최소화하고, 캐시 만료 시간을 적절히 설정하여 보안 위험을 최소화해야 합니다.
민감한 자격 증명 - 애플리케이션 계층 암호화 + 짧은 TTL 캐싱
설명: 데이터베이스 자격 증명, OAuth 토큰, 민감한 API 키 등 시스템의 핵심 자원에 접근하는 데 사용되는 Secret은 매우 높은 민감도를 가집니다. 이러한 Secret은 단순히 캐싱하는 것을 넘어, 애플리케이션 계층에서 한 번 더 암호화(Application Layer Encryption)하는 것을 고려할 수 있습니다.
암호화 방식: Secrets Manager에서 Secret을 불러온 후, 애플리케이션 내부에서 다시 한 번 암호화하여 메모리에 저장합니다. 이때 암호화 키는 Secrets Manager에서 별도로 관리하거나, KMS(Key Management Service)와 같은 다른 키 관리 서비스에서 동적으로 가져와 사용할 수 있습니다.
짧은 TTL 캐싱: 암호화된 상태로 캐싱하더라도, 만약의 사태에 대비하여 캐시 만료 시간(TTL)을 매우 짧게 설정하여 Secret이 메모리에 머무는 시간을 최소화합니다.
장점: Secret이 메모리에 존재하더라도 암호화된 상태이므로, 메모리 덤프와 같은 공격으로부터 추가적인 보호 계층을 제공합니다.
주의사항: 애플리케이션 계층 암호화는 구현 복잡도가 증가하고, 암호화/복호화 과정에서 약간의 성능 오버헤드가 발생할 수 있습니다. 암호화 키 관리 또한 중요한 보안 고려사항이 됩니다.
강한 보안이 필요한 환경 - Secrets Manager 호출 후 즉시 사용, 캐싱 최소화
설명: 금융 정보, 개인 식별 정보(PII)에 접근하는 Secret, 또는 규제 준수(Compliance) 요구사항이 매우 엄격한 환경에서는 최대한의 보안을 우선시해야 합니다. 이 경우, Secret은 Secrets Manager에서 필요한 시점에 직접 호출하여 사용하고, 사용 후에는 즉시 메모리에서 제거하며, 캐싱을 최소화하거나 아예 사용하지 않는 전략을 택합니다.
작동 방식: 애플리케이션이 Secret이 필요할 때마다 Secrets Manager API를 호출하여 Secret을 가져오고, 작업을 완료한 후에는 해당 Secret을 메모리에서 즉시 지웁니다.
장점: Secret이 메모리에 복호화된 상태로 머무는 시간을 극도로 최소화하여 보안 위험을 가장 낮출 수 있습니다. 이는 가장 강력한 보안 정책입니다.
주의사항: 매번 API 호출이 발생하므로 API 호출 비용이 증가하고, 네트워크 지연으로 인한 성능 오버헤드가 가장 큽니다. 따라서 성능에 민감하지 않거나, 극도의 보안이 요구되는 특정 작업(예: 일회성 관리 작업, 민감 데이터 암호화 키 접근)에 주로 적용됩니다.
공통적인 보안 원칙
어떤 Secret 관리 정책을 선택하든, 가장 중요한 것은 메모리나 환경 변수에 접근할 수 있는 권한을 최소화(Least Privilege)하는 것입니다. 애플리케이션이나 사용자에게 필요한 최소한의 권한만 부여하여, Secret에 대한 불필요한 접근을 원천적으로 차단해야 합니다. 이는 Secret 관리 전략의 기본이자 핵심입니다.
또한, 호출 빈도가 낮아도 자주 변하지 않는 설정 정보(예: API 키, 정적 구성 값)는 Secrets Manager보다 Systems Manager Parameter Store(Simple Tier)를 활용하는 것이 더 저렴할 수 있습니다.
Secrets 보관 정책 미흡
AWS Secrets Manager에서는 각 Secret 객체에 대해 매월 $0.40의 저장 비용이 부과됩니다. 이는 실제로 사용 중인 Secret이든, 더 이상 사용되지 않는 Secret이든 삭제하지 않는 한 지속적으로 과금된다는 의미입니다.
예를 들어, 테스트 환경에서 생성된 DB 비밀번호, 만료된 API 키, 프로젝트 종료 후 더 이상 쓰이지 않는 토큰 등이 삭제되지 않고 남아 있다면, 의미 없는 리소스에 대해 매달 불필요한 비용이 계속 쌓이게 됩니다.
일반적인 실수
CI/CD 파이프라인 테스트 중 임시로 생성된 Secrets를 방치
Secret Rotation 후 이전 버전 Secret을 수동으로 관리하지 않고 그대로 둠
사용이 종료된 프로젝트의 Secrets를 정리하지 않음
대응 전략
정기 점검 스크립트 자동화: AWS CLI 또는 SDK를 활용하여 LastAccessedDate, RotationEnabled 등을 기준으로 30일 이상 미사용된 Secret을 탐지합니다.
만료 태그 관리: Secret 생성 시 ExpiresAt, Owner, Environment 등의 태그를 부여하여 분류 및 자동 정리 기준을 마련합니다.
사용 종료 시 명시적 삭제 절차 포함: 프로젝트 종료 또는 배포 종료 시점에 Secrets 삭제를 포함한 운영 절차를 수립합니다.
Secrets 자동 로테이션 설정 주의
AWS Secrets Manager의 자동 로테이션 기능은 보안 강화를 위해 매우 유용하지만, 로테이션 주기를 과도하게 짧게 설정하면 오히려 비용 증가의 원인이 됩니다.
Secrets Manager는 로테이션 주기마다 다음 작업을 수행합니다.
새로운 자격증명 생성 (예: 새로운 DB 비밀번호)
대상 리소스(예: RDS)에 적용
Secret 값 갱신 및 테스트
애플리케이션과의 동기화
이 모든 작업은 Lambda 함수를 통해 수행되며, API 호출 비용이 발생합니다. 로테이션 주기가 너무 짧으면 비용은 기하급수적으로 증가할 수 있습니다.
30일 주기 로테이션 (권장): 월 1회 Lambda 실행, API 호출도 최소화
1일 주기 로테이션: 월 30회 실행 → 불필요한 API 호출, Lambda 실행 비용 증가
1시간 주기처럼 과도한 설정 → 시스템 과부하 발생 가능
결론
Secrets Manager는 분명 보안 강화를 위한 핵심 도구입니다. 하지만 비용이 Secret 개수, 조회 빈도, 로테이션 주기, KMS 연동 등 복합 요소로 구성되기 때문에, 단순히 저장만 해도 비용이 지속적으로 발생합니다.
실제로 운영 환경에서 가장 흔한 비용 누수는 다음과 같습니다.
테스트 Secret을 삭제하지 않고 방치
자주 쓰는 Secret을 캐싱 없이 매번 실시간 조회
민감도가 낮은 값을 굳이 Secrets Manager에 저장
과도하게 짧은 로테이션 주기로 Lambda·API 호출 비용 급증
비용 최적화는 보안을 포기하는 일이 아닙니다. 오히려 보안 민감도에 따라 관리 전략을 나누고, Secret 사용 습관을 설계함으로써 비용도, 리스크도 함께 줄일 수 있습니다.
