AWS CLI: InvalidClientTokenId — 요청의 security token이 유효하지 않음

안녕하세요, BlueByte입니다. 분명 되어야 할 명령에 AWS CLI가 An error occurred (InvalidClientTokenId) ... The security token included in the request is invalid로 답한다면, 계정이 망가진 게 아닙니다 — AWS가 요청에 실린 자격 증명을 보고 거부한 것입니다. 오늘은 이 메시지가 뜻하는 것, AWS가 토큰을 거부하는 몇 가지 원인, CLI가 실제로 집어 든 자격 증명을 확인하는 법, 원인별 해결, 그리고 예방까지 하나씩 짚어보겠습니다.

"The security token included in the request is invalid"가 뜻하는 것

InvalidClientTokenId는 자격 증명 인증 실패로, AWS가 권한을 확인하기도 전에 돌려주는 오류입니다. 어떤 서비스 호출에서도 나타날 수 있어서 — AWS 문서는 aws s3 ls(ListBuckets 작업)에서의 예를 보여줍니다 — 메시지에 적힌 작업 이름이 원인은 아닙니다:

$ aws s3 ls
An error occurred (InvalidClientTokenId) when calling the ListBuckets operation:
The security token included in the request is invalid.

"security token"은 access key ID와, 임시 자격 증명이라면 함께 다니는 session token을 아우릅니다. AWS는 보낸 값을 살아 있는 자격 증명으로 매핑할 수 없다고 말하는 것입니다. 권한 확인 단계에는 도달조차 못 했으니 이건 access-denied가 아닙니다.

AWS가 토큰을 거부하는 몇 가지 원인

대개 다음 중 하나입니다.

• 설정 이후 access key가 IAM에서 삭제·비활성화됨.
• 만료된 임시 자격 증명 — assumed role, aws sso login, 또는 직접 붙여 넣은 session token에서 온 STS 세션은 수명이 짧아, 만료되면 토큰이 무효가 됨.
• 오래된 환경 변수(AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN)가 셸에 남아 있고, 환경 변수가 자격 증명 파일보다 우선순위가 높기 때문에 쓰려던 프로필을 덮어씀.
• key가 엔드포인트와 다른 파티션 소속임 — 표준 파티션 key로 GovCloud(aws-us-gov)나 중국(aws-cn) 엔드포인트를 부르면 인식되지 않음.
• access key ID를 잘못 복사함 — 잘리거나 자리가 뒤바뀜.

먼저, CLI가 실제로 쓰는 자격 증명을 확인하기

어떤 자격 증명이 나갔는지 추측하지 말고 CLI에 물어보면 됩니다. aws configure list는 해석된 값과, 무엇보다 각 값이 어디서 왔는지를 보여줍니다:

aws configure list

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************ABCD              env    AWS_ACCESS_KEY_ID
secret_key     ****************wXyZ              env    AWS_SECRET_ACCESS_KEY
    region                us-east-1              env    AWS_DEFAULT_REGION

Location 열이 이런 실패의 대부분을 설명해 줍니다. ~/.aws/credentials를 기대했는데 env라고 나오면 환경 변수가 이기고 있는 것입니다. 신원을 끝까지 확인하려면:

aws sts get-caller-identity

여기서도 같은 InvalidClientTokenId가 나오면 문제는 한 명령이 아니라 자격 증명 자체입니다. 무엇이 로드됐는지 전체 흐름을 보려면 --debug로 다시 실행해 Looking for credentials via: 줄을 읽어 보세요.

원인별 해결: 오래된 env 변수·만료된 세션·삭제된 key

1. 오래된 환경 변수 — 지우고 프로필이 나서게 합니다:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
aws sts get-caller-identity

2. 만료된 임시 자격 증명 — 다시 인증합니다. IAM Identity Center / SSO는 aws sso login --profile my-sso. assumed role은 aws sts assume-role를 다시 실행해 내보낸 값을 교체합니다.

3. 삭제·비활성화된 key — 상태를 확인하고 교체합니다:

aws iam list-access-keys --user-name my-user

key가 Inactive거나 없으면 새로 만들고 aws configure로 저장합니다.

4. 잘못된 파티션 — 맞는 파티션을 대상으로 하고(예: --region us-gov-west-1), 그 파티션에서 발급한 key를 씁니다.

실제 사례: 남아 있던 AWS_SESSION_TOKEN

어제까지 잘 돌던 배포 스크립트가 aws s3 cp에서 InvalidClientTokenId로 실패하기 시작했습니다. aws configure list를 보니 access_key ... Location env AWS_ACCESS_KEY_ID였는데, 이 프로젝트는 named profile을 씁니다. 누군가 관련 없는 테스트를 하려고 그 셸에 임시 자격 증명을 export해 뒀고, 그중 AWS_SESSION_TOKEN이 그새 만료됐던 것입니다. env 변수가 프로필보다 우선이라 모든 명령이 죽은 토큰을 실어 나른 것이죠. unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN 뒤 aws sts get-caller-identity가 프로필의 기대 ARN을 돌려줬고, 배포가 통과했습니다.

고친 뒤 확인하고 재발을 막기

aws sts get-caller-identity로 확인합니다 — Account·UserId·Arn이 담긴 JSON이 나오면 자격 증명이 살아 있는 것입니다. 재발을 막으려면: 오래된 key가 남지 않도록 장기 key보다 단기 자격 증명(SSO나 assumed role)을 쓰고, 일회성 작업에 자격 증명을 셸에 export하지 말고 --profile로 넘기며, CI의 첫 단계로 aws sts get-caller-identity를 넣어 잘못된 자격 증명이 배포 깊숙이 아니라 작업 맨 앞에서 요란하게 실패하게 하세요.

InvalidAccessKeyId·SignatureDoesNotMatch와 어떻게 다른가

InvalidClientTokenId는 key ID나 session token이 AWS가 아는 살아 있는 자격 증명이 아니라는 뜻입니다. InvalidAccessKeyId는 비슷하지만 다릅니다 — "The AWS Access Key Id you provided does not exist in our records" — AWS에 그 key 기록이 아예 없는 경우로, 대개 오타이거나 다른 계정의 key입니다. SignatureDoesNotMatch는 또 다릅니다: key는 인식하지만 요청 서명이 검증되지 않은 경우로, 시계가 몇 분 이상 어긋났거나(date로 확인) secret key가 특수문자로 깨진 것이 흔한 원인입니다. 그리고 이 셋 중 무엇도 AccessDenied는 아닙니다 — 그건 자격 증명은 유효하나 해당 작업 권한이 없는 경우입니다.