AWS Secrets Manager vs Parameter Store — 무엇을 언제 써야 하나

1. 왜 시크릿을 코드에서 분리해야 하나

DB 접속 정보, API 키, 서드파티 토큰 같은 자격 증명을 다루는 가장 흔한 방식은 셋 중 하나입니다. 소스 코드에 직접 쓰거나, .env 파일로 서버에 배포하거나, CI/CD 파이프라인의 환경 변수에 넣는 것입니다. 세 방식 모두 같은 구조적 결함을 공유합니다 — 누가 언제 그 값을 읽었는지 알 수 없고, 값을 바꾸려면 배포를 다시 해야 하며, 유출되어도 탐지할 방법이 없습니다.

시크릿 관리 서비스를 쓰면 이 네 가지가 한 번에 해결됩니다. 값은 KMS로 암호화되어 저장되고, 모든 읽기 요청은 CloudTrail에 남으며, IAM으로 "누가 어떤 시크릿을 읽을 수 있는지"를 리소스 단위로 통제할 수 있고, 값 교체가 배포와 분리됩니다.

2. 두 서비스 한눈에 보기

AWS는 이 용도로 두 가지 서비스를 제공합니다. 이름은 다르지만 "값을 안전하게 저장하고 API로 꺼내 쓴다"는 기본 동작은 같습니다. 차이는 자동 교체(로테이션)를 서비스가 대신 해주느냐와 비용 구조에서 갈립니다.

3. 기능 비교표

4. Parameter Store 실무

4-1. 파라미터 타입 3가지

4-2. 계층형 네이밍 — 설계의 90%

Parameter Store의 진짜 강점은 경로 기반 계층 구조입니다. /서비스/환경/용도 형태로 이름을 지으면 GetParametersByPath 한 번으로 애플리케이션이 필요한 설정을 통째로 가져올 수 있고, IAM 정책도 경로 와일드카드로 깔끔하게 쓸 수 있습니다.

# 권장 네이밍 — /{서비스}/{환경}/{카테고리}/{키}
/payment-api/prod/db/host          # String
/payment-api/prod/db/port          # String
/payment-api/prod/db/password      # SecureString
/payment-api/prod/feature/new-ui   # String
/payment-api/stage/db/host         # String

# 값 저장 (SecureString + 고객 관리형 KMS 키)
aws ssm put-parameter \
  --name "/payment-api/prod/db/password" \
  --value "$(openssl rand -base64 24)" \
  --type SecureString \
  --key-id "alias/param-store-cmk" \
  --tags "Key=Service,Value=payment-api" "Key=Env,Value=prod"

# 경로 하위 전체를 한 번에 조회 (복호화 포함)
aws ssm get-parameters-by-path \
  --path "/payment-api/prod/" \
  --recursive \
  --with-decryption

4-3. Standard vs Advanced 티어

Standard는 무료지만 4KB, 1만 개 제한이 있고 파라미터 정책을 쓸 수 없습니다. Advanced는 개당 월 $0.05로 8KB, 10만 개까지 늘어나며 파라미터 정책(만료·만료 알림·변경 없음 알림)을 붙일 수 있습니다.

# Advanced 티어 + 정책 — 90일간 변경이 없으면 EventBridge 알림
aws ssm put-parameter \
  --name "/payment-api/prod/thirdparty/api-key" \
  --value "REPLACE_ME" \
  --type SecureString \
  --tier Advanced \
  --policies '[{"Type":"NoChangeNotification","Version":"1.0","Attributes":{"After":"90","Unit":"Days"}}]'

자동 로테이션은 없지만, 이 NoChangeNotification 정책을 EventBridge → SNS로 연결하면 "90일간 교체되지 않은 키" 알림을 받아 수동 교체 주기를 관리할 수 있습니다. 자동 교체가 필요 없고 주기 점검만 요구되는 규정이라면 이 조합으로 Secrets Manager 비용 없이 요건을 맞출 수 있습니다.

5. Secrets Manager 실무

5-1. 자동 로테이션 — 존재 이유 그 자체

Secrets Manager를 쓰는 유일하고 결정적인 이유는 자동 로테이션입니다. 두 가지 방식이 있습니다.

커스텀 로테이션 Lambda는 createSecret → setSecret → testSecret → finishSecret 네 단계를 구현해야 합니다. 핵심은 스테이징 레이블입니다. 새 값은 먼저 AWSPENDING으로 만들어지고, 검증을 통과한 뒤에야 AWSCURRENT로 승격되며, 직전 값은 AWSPREVIOUS로 남습니다. 이 구조 덕분에 로테이션 중에도 실행 중인 애플리케이션이 끊기지 않습니다.

5-2. 시크릿 저장과 조회

# JSON 구조로 저장 (RDS 통합 시 권장 필드 구성)
aws secretsmanager create-secret \
  --name "payment-api/prod/rds" \
  --description "payment-api 운영 RDS 자격 증명" \
  --kms-key-id "alias/secrets-cmk" \
  --secret-string '{
    "username": "app_user",
    "password": "CHANGE_ME",
    "engine": "postgres",
    "host": "payment-prod.cluster-xxxx.ap-northeast-2.rds.amazonaws.com",
    "port": 5432,
    "dbname": "payment"
  }'

# 30일 주기 자동 로테이션 활성화 (RDS 관리형)
aws secretsmanager rotate-secret \
  --secret-id "payment-api/prod/rds" \
  --rotation-rules '{"AutomaticallyAfterDays": 30}'

# 서울 → 도쿄 복제 (DR 대비)
aws secretsmanager replicate-secret-to-regions \
  --secret-id "payment-api/prod/rds" \
  --add-replica-regions '[{"Region":"ap-northeast-1","KmsKeyId":"alias/secrets-cmk-tokyo"}]'

5-3. Parameter Store에서 Secrets Manager 참조하기

애플리케이션이 이미 SSM만 호출하도록 만들어져 있다면, 코드를 바꾸지 않고도 Secrets Manager 값을 읽을 수 있습니다. /aws/reference/secretsmanager/ 접두사를 붙이면 SSM API가 Secrets Manager로 위임합니다.

# SSM API로 Secrets Manager 시크릿 읽기
aws ssm get-parameter \
  --name "/aws/reference/secretsmanager/payment-api/prod/rds" \
  --with-decryption

# 필요한 IAM 권한은 두 서비스 모두
# ssm:GetParameter + secretsmanager:GetSecretValue

6. 선택 결정 트리

7. ECS · Lambda · EKS 연동

7-1. ECS / Fargate — 태스크 정의에서 직접 주입

애플리케이션 코드에서 SDK를 호출할 필요 없이, ECS 태스크 정의의 secrets 필드에 ARN을 적으면 컨테이너 시작 시 환경 변수로 주입됩니다. 두 서비스 모두 같은 문법을 씁니다.

// ECS 태스크 정의 — 두 서비스 혼용 예시
"secrets": [
  {
    "name": "DB_PASSWORD",
    // Secrets Manager — JSON 내 특정 키만 주입 (:key:: 문법)
    "valueFrom": "arn:aws:secretsmanager:ap-northeast-2:111122223333:secret:payment-api/prod/rds-AbCdEf:password::"
  },
  {
    "name": "THIRDPARTY_KEY",
    // Parameter Store
    "valueFrom": "arn:aws:ssm:ap-northeast-2:111122223333:parameter/payment-api/prod/thirdparty/api-key"
  }
]

7-2. Lambda — Parameters and Secrets 확장

Lambda에서는 매 호출마다 SDK로 시크릿을 조회하면 지연 시간과 API 비용이 함께 늘어납니다. AWS가 제공하는 Parameters and Secrets Lambda Extension 레이어를 붙이면 로컬 캐시를 통해 localhost:2773으로 조회할 수 있어 호출 대부분이 캐시에서 처리됩니다.

# 확장이 노출하는 로컬 HTTP 엔드포인트
GET http://localhost:2773/systemsmanager/parameters/get?name=/payment-api/prod/db/host&withDecryption=true
GET http://localhost:2773/secretsmanager/get?secretId=payment-api/prod/rds

# 헤더에 Lambda 런타임 API 토큰 필요
X-Aws-Parameters-Secrets-Token: $AWS_SESSION_TOKEN

# 주요 환경 변수
SSM_PARAMETER_STORE_TTL=300              # 파라미터 캐시 TTL(초)
SECRETS_MANAGER_TTL=300                  # 시크릿 캐시 TTL(초)
PARAMETERS_SECRETS_EXTENSION_CACHE_SIZE=500

7-3. EKS — Secrets Store CSI Driver

쿠버네티스에서는 Secrets Store CSI Driver + AWS Provider를 설치하면 시크릿을 볼륨으로 파드에 마운트할 수 있습니다. 필요하면 쿠버네티스 네이티브 Secret으로 동기화도 가능합니다. 파드는 IRSA(IAM Roles for Service Accounts)로 발급된 역할을 사용하므로 노드 전체가 아닌 파드 단위 최소 권한이 적용됩니다.

7-4. 애플리케이션 코드 (Python)

import boto3, json, os
from functools import lru_cache

ssm = boto3.client("ssm")
sm  = boto3.client("secretsmanager")

# 콜드 스타트 시 1회만 조회되도록 캐싱 — API 비용·지연 절감
@lru_cache(maxsize=32)
def get_config(path: str) -> dict:
    """경로 하위 파라미터를 한 번에 조회해 dict로 변환"""
    paginator = ssm.get_paginator("get_parameters_by_path")
    out = {}
    for page in paginator.paginate(Path=path, Recursive=True, WithDecryption=True):
        for p in page["Parameters"]:
            out[p["Name"].rsplit("/", 1)[-1]] = p["Value"]
    return out

@lru_cache(maxsize=8)
def get_secret(secret_id: str) -> dict:
    return json.loads(sm.get_secret_value(SecretId=secret_id)["SecretString"])

cfg  = get_config("/payment-api/prod/db/")
cred = get_secret("payment-api/prod/rds")
dsn  = f"postgresql://{cred['username']}:{cred['password']}@{cfg['host']}:{cfg['port']}/payment"

8. 비용 시뮬레이션

운영 중인 마이크로서비스 20개, 서비스당 시크릿 5개(총 100개), 설정값 400개를 가정하고 애플리케이션이 5분 TTL 캐시를 사용해 월 100만 건을 조회하는 경우를 계산해 보겠습니다. (서울 리전 기준, 2026년 9월 공개 요금)

9. 보안 설계 원칙

9-1. 고객 관리형 KMS 키(CMK)를 쓰세요

두 서비스 모두 기본적으로 AWS 관리형 키(aws/ssm, aws/secretsmanager)를 씁니다. 무료지만 키 정책을 제어할 수 없습니다. CMK를 쓰면 "이 시크릿은 결제팀 역할만 복호화할 수 있다"를 키 정책 레벨에서 이중으로 강제할 수 있습니다. IAM 정책이 잘못 열려도 KMS 키 정책이 2차 방어선이 됩니다.

9-2. IAM 최소 권한 — 리소스와 조건을 함께

// 결제팀 애플리케이션 역할 — 운영 파라미터 읽기 전용
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOwnServiceParams",
      "Effect": "Allow",
      "Action": ["ssm:GetParameter", "ssm:GetParameters", "ssm:GetParametersByPath"],
      "Resource": "arn:aws:ssm:ap-northeast-2:111122223333:parameter/payment-api/prod/*"
    },
    {
      "Sid": "DecryptOnlyViaSSM",
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "arn:aws:kms:ap-northeast-2:111122223333:key/xxxx-xxxx",
      "Condition": {
        // KMS 키를 SSM 경유로만 사용 — 직접 Decrypt 호출 차단
        "StringEquals": { "kms:ViaService": "ssm.ap-northeast-2.amazonaws.com" }
      }
    },
    {
      "Sid": "ReadRdsSecret",
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:ap-northeast-2:111122223333:secret:payment-api/prod/*",
      "Condition": {
        // 현재 버전만 조회 허용 — 과거 값 열람 차단
        "ForAnyValue:StringEquals": { "secretsmanager:VersionStage": "AWSCURRENT" }
      }
    }
  ]
}

kms:ViaService 조건은 실무에서 특히 유용합니다. 이 조건이 없으면 역할이 KMS를 직접 호출해 다른 경로로 암호화된 임의의 데이터까지 복호화할 수 있습니다.

9-3. VPC 엔드포인트로 인터넷 경유 차단

프라이빗 서브넷의 애플리케이션이 시크릿을 읽으려면 기본적으로 NAT 게이트웨이를 거쳐 퍼블릭 엔드포인트로 나갑니다. 인터페이스 VPC 엔드포인트를 만들면 트래픽이 AWS 백본 안에 머물고, NAT 데이터 처리 비용도 줄어듭니다.

# 필요한 인터페이스 엔드포인트
com.amazonaws.ap-northeast-2.ssm
com.amazonaws.ap-northeast-2.secretsmanager
com.amazonaws.ap-northeast-2.kms

# 엔드포인트 정책으로 조직 계정 외 접근 차단
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
  }
}

9-4. 감사 — 누가 읽었는지 추적

두 서비스의 모든 읽기 요청은 CloudTrail 관리 이벤트로 기록됩니다(별도 데이터 이벤트 설정 불필요). 운영 시크릿에 대해서는 다음 감지 규칙을 걸어두는 것을 권장합니다.

9-5. 소스 코드 유출 방지

시크릿 저장소를 도입해도, 기존에 커밋된 자격 증명은 그대로 남아 있습니다. 다음 두 가지를 함께 적용하세요.

• 기존 값 전량 교체 — Git 히스토리에 한 번이라도 올라간 값은 이미 유출된 것으로 간주하고 무효화합니다.
• 사전 커밋 스캔 — git-secrets, gitleaks, 또는 CodeGuru Security를 CI에 넣어 새 유출을 막습니다. Amazon GuardDuty는 유출된 IAM 자격 증명이 외부에서 사용될 때 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration 유형으로 탐지합니다.

10. 컴플라이언스 대응

국내 인증 심사에서 자격 증명 관리는 거의 예외 없이 확인 항목에 포함됩니다. 두 서비스를 어떻게 구성하면 어떤 요건이 충족되는지 정리하면 다음과 같습니다.

도입 체크리스트

• 소스 코드·CI 변수·.env에 남아 있는 자격 증명 전수 조사 (gitleaks 스캔)
• 발견된 값 전량 교체 — 히스토리에 남은 값은 유출로 간주
• 네이밍 규칙 확정: /{서비스}/{환경}/{카테고리}/{키}
• 자격 증명은 Secrets Manager, 비민감 설정은 Parameter Store로 분류
• 모든 SecureString·시크릿에 고객 관리형 KMS 키(CMK) 적용
• KMS 키 정책에 kms:ViaService 조건 추가
• IAM 정책을 경로 와일드카드 + 읽기 전용으로 최소화
• RDS·Aurora 자격 증명에 관리형 로테이션(30일) 활성화
• 운영 DB는 alternating users 방식으로 무중단 교체 구성
• 애플리케이션에 TTL 캐시 적용 (Lambda는 Parameters and Secrets 확장)
• ECS 사용 시 로테이션 이벤트 → 서비스 재배포 자동화 연결
• SSM · Secrets Manager · KMS 인터페이스 VPC 엔드포인트 생성
• VPC 엔드포인트 정책에 aws:PrincipalOrgID 제한 적용
• DR 대상 시크릿은 크로스 리전 복제 설정
• SCP로 운영 계정의 삭제 권한을 브레이크글래스 역할로 제한
• CloudTrail 기반 이상 조회·삭제·정책 변경 알림 구성
• AWS Config 로테이션 관련 규칙 4종 활성화
• 분기별 조회 로그 검토 및 미사용 시크릿 정리 절차 수립

마무리

결론은 단순합니다. 자동으로 교체해야 하는 값은 Secrets Manager, 나머지는 Parameter Store입니다. 둘 중 하나를 고르는 문제가 아니라, 값의 성격에 따라 배치하는 문제입니다.