평소의 몇 배로 불어난 AWS 청구서. 해커가 Bedrock을 몰래 쓰면서 생기는 과금 사고는 이제 더 이상 남의 회사 이야기가 아닙니다.

그리고 이런 사고는 대부분 정교한 해킹이 아니라 새어 나간 액세스 키 하나에서 시작됩니다. 다행히 대응도 그만큼 단순합니다. 키는 가능한 한 임시 자격증명으로 쓰고, 새어 나가더라도 빠르게 알아차릴 알림을 걸어두고, 키로 호출할 수 있는 범위를 미리 좁혀두는 것입니다.

최근 Amazon Bedrock 액세스 키가 GitHub 같은 공개 저장소에 노출되면서 생긴 과금 피해 사례가 부쩍 늘고 있습니다. 생성형 AI 서비스는 호출한 만큼 비용이 쌓이는 구조라, 키 하나가 새어 나가면 다른 서비스보다 피해가 훨씬 빠르게 불어나는데요. 담당자가 자리를 비운 사이, 혹은 잠든 사이에도 공격자는 자동화된 스크립트로 쉬지 않고 고비용 모델을 호출합니다. 다음 날 아침이면 이미 감당하기 어려운 청구서가 기다리고 있는 셈이죠.

Bedrock을 쓰고 있다면 우리 회사 계정에서 아래 항목들을 하나씩 확인해 보세요!

Bedrock 접근 키, 어떤 걸 써야 안전할까요?

가장 안전한 건 키를 아예 두지 않는 IAM Role이고, 그다음이 수명이 짧은 단기 Bedrock API 키입니다.

Bedrock에 접근하는 방식은 크게 IAM 액세스 키와 Bedrock 전용으로 발급하는 Bedrock API 키로 나뉩니다. 이름은 비슷해 보여도 연결되는 권한 주체와 위험도는 꽤 다릅니다.

EC2나 Lambda처럼 AWS 리소스에서 직접 Bedrock을 호출한다면, 키를 따로 발급받지 말고 역할을 연결하는 게 가장 안전합니다. 정적 키 자체가 존재하지 않으니 유출될 것도 없죠. 부득이하게 장기 키를 써야 한다면 최소 90일 주기로 교체해서, 유출됐을 때 노출되는 시간 자체를 줄여두시기 바랍니다.

키는 코드가 아니라 환경 변수나 Secrets Manager에 둡니다

액세스 키를 소스 코드나 설정 파일에 하드코딩한 채 공개 저장소에 올리면, 키를 자동으로 수집하는 공격자들의 스캔에 금방 걸립니다. 운영 환경에 영향을 주는 비밀 값은 환경 변수나 AWS Secrets Manager 같은 자격증명 저장소로 관리하는 게 원칙입니다.

.gitignore에 .env 파일을 등록해두는 습관, 커밋 전에 민감 정보를 자동으로 검사하는 pre-commit 훅 하나만 팀 차원에서 갖춰도 실수로 인한 노출은 크게 줄어듭니다.

[참고] Bedrock이 정확히 어떤 서비스인지부터 다시 짚어보고 싶다면?
👉 AWS GenAI 서비스 베드록(Bedrock)이란?

키가 새어 나가도 빨리 알아차리는 방법

그래도 실수는 일어날 수 있습니다. 그래서 두 번째로 챙길 건 알아차리는 속도입니다.

Health Dashboard 알림을 담당자에게 연결합니다

AWS는 공개 저장소에 노출된 액세스 키를 자동으로 탐지하면, 해당 키에 격리 정책을 붙여 추가 피해를 막고 계정에 등록된 연락처와 AWS Health Dashboard로 이 사실을 알려줍니다.

이 기능이 제대로 작동하려면 계정 연락처 정보가 최신이어야 하고, 누군가 Health Dashboard를 실제로 챙겨봐야 합니다. AWS User Notifications로 이 알림을 이메일, 콘솔 모바일 앱 푸시, Teams나 Slack 같은 채팅 채널로 보내두면 훨씬 빨리 인지할 수 있습니다. 여기에 Health 이벤트를 Amazon EventBridge로 전달해 Lambda를 실행하도록 걸어두면, 격리에 더해 해당 키를 즉시 삭제하는 대응까지 자동화할 수 있습니다.

비용 알림은 걸되, 실시간이 아니라는 점을 기억합니다

가장 기본은 AWS Budgets로 월 예산을 정하고 임계치를 넘으면 이메일이나 SNS로 알림을 받는 방법입니다. Cost Anomaly Detection을 함께 켜두면 예산을 넘지 않았더라도 평소와 다른 지출 패턴이 보일 때 따로 알려줍니다.

다만 두 가지 모두 실시간은 아닙니다. AWS 공식 문서에 따르면 비용 데이터는 최소 24시간마다 한 번 갱신되고, 그보다 늦게 반영되는 경우도 있습니다. 하루 만에 비용이 폭증하는 사고라면 알림이 오기 전에 이미 피해가 쌓여 있을 수 있죠.

호출 가능한 모델 자체를 좁혀 둡니다

그래서 더 효과적인 방법은 실제로 쓰는 모델만 남기고 나머지는 IAM 정책으로 막아두는 것입니다. 키가 새어 나가더라도 공격자가 호출할 수 있는 모델이 제한되니 피해 규모도 함께 줄어듭니다. 여기에 CloudWatch의 Metric Math 기능으로 Bedrock 토큰 사용량 지표를 비용으로 환산해 알람을 걸어두면, 청구 데이터보다 빠르게 이상 징후를 잡을 수 있습니다.

[참고] 이상 징후를 Slack·전화로 바로 통보받는 방법이 궁금하다면?
👉 상주 관제 없이 하는 AWS 운영, 월 5만 원부터 가능한 이유

계정 기본 보안까지 챙겨야 하는 이유는?

Bedrock 키를 아무리 잘 관리해도, 계정 자체가 뚫리면 소용이 없기 때문입니다.

특히 개발 실무를 수월하게 하기 위해 담당자 계정에 Admin 권한을 그대로 주는 경우가 적지 않은데요. 이런 계정의 접속 정보나 키가 유출되면 공격자는 비용 알림 수신자부터 지워 감지를 피한 뒤, 고비용 리소스를 무단으로 만들고 호출할 수 있습니다. 앞에서 걸어둔 알림까지 함께 무력화되는 셈이죠.

그래서 Bedrock 보안은 계정 기본 보안 위에서 완성됩니다. 루트와 IAM 사용자 모두에 다중 인증(MFA)을 걸고, 권한은 필요한 만큼만 주고, Root·IAM 비밀번호는 담당자가 바뀌거나 유출이 의심될 때 바로 교체해두세요.

[참고] 루트 MFA부터 최소 권한까지, 계정 기본 보안을 하나씩 점검하고 싶다면?
👉 AWS 계정 보안, 4가지 질문으로 점검하는 기본 체크리스트

Bedrock 계정 보안 체크리스트

바로 답하기 망설여지는 항목이 있다면, 그 지점이 지금 가장 먼저 채워야 할 빈틈입니다.

1. 장기 키 대신 IAM 역할이나 단기 키를 우선 쓰고, 장기 키는 90일 이내로 교체하고 있나요?
   2. 코드 저장소에 키가 하드코딩된 곳은 없는지 확인하셨나요?
   3. 계정 연락처 정보가 최신이고, Health Dashboard 알림을 담당자가 받고 있나요?
   4. 예산 알림이나 비용 이상 탐지가 켜져 있나요?
   5. 실제로 쓰지 않는 Bedrock 모델은 IAM 정책으로 막아두셨나요?
   6. 루트 계정과 IAM 사용자 모두 MFA가 켜져 있나요?
   7. 실무자나 장기 자격증명용 IAM 사용자에게 필요 이상의 권한이 들어가 있지 않나요?

7가지 항목을 하나씩 확인하고 빈 곳을 직접 채우는 일은 생각보다 시간이 많이 듭니다. 키와 권한, 알림이 서로 맞물려 있어 한 곳만 고쳐서는 효과가 잘 나지 않기 때문이죠.

파이브클라우드는 AWS 환경에서 Bedrock을 안전하게 도입할 수 있도록 키·권한 관리 체계를 함께 설계합니다. 이상 징후가 감지되면 Slack과 전화로 바로 알려주는 알림팩도 함께 지원해, 사고가 나더라도 인지 시점을 앞당길 수 있습니다.