AWS 프리 티어 요금 초과 방지: CloudWatch 결제 알람 설정 완전 가이드

AWS 계정을 처음 만들고 프리 티어로 실습하다가 월말에 예상치 못한 청구서를 받는 경우가 생각보다 많다. EC2 인스턴스를 종료하지 않고 잠들었거나, 실수로 프리 티어 한도를 초과하는 서비스를 켜둔 경우다. CloudWatch 결제 알람(Billing Alarm)을 미리 설정해두면 요금이 임계값을 넘는 순간 이메일로 알림을 받을 수 있어, 프리 티어 초과를 조기에 차단할 수 있다.

TL;DR — CloudWatch 결제 알람 설정 요약

단계작업핵심 포인트
1결제 알람 활성화루트 계정 또는 결제 권한 보유 IAM 사용자로 Billing 콘솔에서 활성화 필요
2SNS 주제 생성us-east-1 리전에서만 생성 — 결제 지표는 이 리전에만 존재
3이메일 구독 추가 및 확인구독 확인 이메일의 링크를 클릭해야 알림이 실제로 전송됨
4CloudWatch 알람 생성EstimatedCharges 지표, USD 5 임계값 설정
5동작 확인알람 상태 및 SNS 구독 상태 검증

결제 알람이 작동하는 방식 — 설정 전에 반드시 알아야 할 구조

CloudWatch 결제 알람은 일반 CloudWatch 알람과 동일한 메커니즘으로 동작하지만, 몇 가지 중요한 제약이 있다. AWS/Billing 네임스페이스의 EstimatedCharges 지표는 us-east-1 리전에서만 게시된다. 다른 리전에서 알람을 만들려고 해도 이 지표를 찾을 수 없다. 또한 이 지표는 약 6시간마다 업데이트되므로, 실시간 요금 감시 도구가 아니라 누적 요금 경보 도구로 이해해야 한다.

알람이 트리거되면 CloudWatch는 SNS(Simple Notification Service) 주제로 메시지를 발행하고, SNS는 구독된 이메일 주소로 알림을 전달한다. 이 흐름에서 SNS 구독 확인이 완료되지 않으면 알람이 울려도 이메일이 오지 않는다 — 가장 흔한 실수다.

graph LR A["AWS Billing 약 6시간 주기 집계"] -->|EstimatedCharges 지표 게시| B["CloudWatch us-east-1"] B -->|임계값 초과 감지| C["알람 상태 ALARMED"] C -->|메시지 발행| D["SNS 주제 billing-alert-topic"] D -->|구독 확인 완료 시| E["이메일 수신"] D -->|구독 미확인 시| F["전달 안 됨 PendingConfirmation"]
  1. AWS Billing: 약 6시간 주기로 계정 전체 추정 요금을 집계하여 EstimatedCharges 지표를 us-east-1에 게시
  2. CloudWatch 알람: 지표값이 설정한 임계값(예: $5)을 초과하면 ALARM 상태로 전환
  3. SNS 주제: 알람 상태 변경 이벤트를 수신하여 구독자에게 전달
  4. 이메일 구독자: SNS가 최종적으로 이메일을 발송 — 구독 확인이 완료된 경우에만 동작

사전 조건: 결제 알람 활성화 (루트 계정 필수)

CloudWatch에서 결제 지표를 사용하려면 먼저 AWS 계정 수준에서 결제 알람을 활성화해야 한다. 이 설정은 루트 계정 또는 결제 콘솔 접근 권한을 가진 IAM 사용자만 변경할 수 있다.

AWS Management Console에서 우측 상단 계정 이름 클릭 → 결제 대시보드(Billing Dashboard) → 좌측 메뉴 결제 기본 설정(Billing Preferences) → '결제 알람 수신(Receive Billing Alerts)' 체크박스를 활성화하고 저장한다.

이 설정을 건너뛰면 CloudWatch에서 EstimatedCharges 지표 자체가 보이지 않는다. 지표가 없으니 알람도 만들 수 없다.

CloudWatch 결제 알람 설정 — 단계별 가이드

1단계: SNS 주제 생성 (us-east-1 리전)

결제 지표가 us-east-1에만 존재하므로, SNS 주제도 같은 리전에 만들어야 한다. 리전이 다르면 CloudWatch 알람에서 해당 SNS 주제를 액션 대상으로 연결할 수 없다.

# 리전을 명시적으로 us-east-1로 지정
aws sns create-topic \
  --name billing-alert-topic \
  --region us-east-1

명령 실행 후 반환되는 TopicArn을 기록해둔다. 이후 단계에서 사용한다.

# 출력 예시
{
    "TopicArn": "arn:aws:sns:us-east-1:123456789012:billing-alert-topic"
}

2단계: 이메일 구독 추가

SNS 주제에 알림을 받을 이메일 주소를 구독자로 등록한다. 명령 실행 직후 해당 이메일로 확인 요청 메일이 발송된다.

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:billing-alert-topic \
  --protocol email \
  --notification-endpoint your-email@example.com \
  --region us-east-1

이메일 받은 편지함에서 'AWS Notification - Subscription Confirmation' 메일을 찾아 'Confirm subscription' 링크를 클릭한다. 이 단계를 완료하지 않으면 구독 상태가 PendingConfirmation으로 남아 알림이 전달되지 않는다.

3단계: 구독 확인 상태 검증

알람을 만들기 전에 구독이 실제로 확인되었는지 확인한다. 이 검증을 건너뛰면 알람이 울려도 이메일이 오지 않는 상황을 나중에야 발견하게 된다.

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:billing-alert-topic \
  --region us-east-1

SubscriptionArn 필드가 PendingConfirmation이 아닌 실제 ARN 값으로 표시되어야 정상이다.

4단계: CloudWatch 결제 알람 생성

이제 실제 알람을 만든다. EstimatedCharges 지표는 Currency 디멘션으로 통화를 구분하며, USD를 지정해야 한다. 임계값 5는 $5를 의미한다.

aws cloudwatch put-metric-alarm \
  --alarm-name "FreeTier-Billing-Alert" \
  --alarm-description "Estimated charges exceeded $5" \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum \
  --period 86400 \
  --threshold 5 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --dimensions Name=Currency,Value=USD \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:billing-alert-topic \
  --treat-missing-data notBreaching \
  --region us-east-1

파라미터별 의미를 짚어두면 나중에 수정할 때 편하다:

  • --statistic Maximum: 결제 지표는 누적값이므로 Maximum이 적합하다
  • --period 86400: 86400초 = 24시간 단위로 평가
  • --evaluation-periods 1: 1개 기간 동안 조건이 충족되면 즉시 알람
  • --treat-missing-data notBreaching: 데이터가 없는 경우(신규 계정 초기 등) 알람 상태로 전환하지 않음

5단계: 알람 상태 확인

알람이 정상적으로 생성되었는지, 현재 상태가 무엇인지 확인한다. 방금 만든 알람은 데이터가 충분히 수집되기 전까지 INSUFFICIENT_DATA 상태일 수 있다 — 이것은 정상이다.

aws cloudwatch describe-alarms \
  --alarm-names "FreeTier-Billing-Alert" \
  --region us-east-1

출력에서 StateValue가 OK 또는 INSUFFICIENT_DATA이면 알람이 정상적으로 생성된 것이다. ALARM이면 이미 $5를 초과한 상태다.

실제 운영에서 마주치는 문제 — 증상, 오진, 실제 원인

알람을 설정했는데 요금이 초과됐음에도 이메일이 오지 않았다는 경우가 있다. 처음에는 CloudWatch 알람 설정이 잘못됐다고 생각하고 알람을 지우고 다시 만드는 작업을 반복한다. 알람 상태는 분명히 ALARM으로 바뀌었는데 이메일이 없다.

실제 원인은 SNS 구독 확인을 완료하지 않은 것이다. 구독 확인 이메일이 스팸 폴더로 들어간 경우가 많다. CloudWatch 알람은 정상적으로 SNS에 메시지를 발행했지만, SNS는 PendingConfirmation 상태의 구독자에게는 메시지를 전달하지 않는다.

SNS 구독 확인은 우편 주소 등록과 비슷하다. 주소를 적어놨다고 편지가 가는 게 아니라, 수신자가 '이 주소 맞아요'라고 확인해줘야 실제로 배달이 시작된다.

진단은 간단하다. list-subscriptions-by-topic 명령으로 구독 상태를 확인하고, PendingConfirmation이면 SNS 콘솔에서 확인 요청 이메일을 재발송하거나 구독을 삭제하고 다시 추가한다.

IAM 권한 — 최소 권한으로 알람 관리

루트 계정 대신 IAM 사용자로 이 작업을 수행한다면, 아래 권한이 필요하다. 결제 알람 활성화는 루트 계정 또는 결제 콘솔 접근이 허용된 IAM 사용자만 가능하며, 이는 IAM 정책으로 제어되는 별도 설정이다.

🔽 IAM 정책 예시 (클릭하여 펼치기) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchBillingAlarm",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricAlarm",
        "cloudwatch:DescribeAlarms",
        "cloudwatch:DeleteAlarms"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SNSBillingTopic",
      "Effect": "Allow",
      "Action": [
        "sns:CreateTopic",
        "sns:Subscribe",
        "sns:ListSubscriptionsByTopic"
      ],
      "Resource": "arn:aws:sns:us-east-1:123456789012:billing-alert-topic"
    }
  ]
}

cloudwatch:PutMetricAlarm과 cloudwatch:DescribeAlarms는 리소스 수준 제한을 지원하지 않아 "Resource": "*"가 필요하다. AWS Service Authorization Reference에서 확인할 수 있다.

추가 권장 설정 — 프리 티어 초과 알림

결제 알람 외에도 AWS는 프리 티어 사용량 자체를 추적하는 별도 기능을 제공한다. Billing 콘솔 → 프리 티어(Free Tier) 메뉴에서 서비스별 프리 티어 사용률을 확인할 수 있으며, 프리 티어 사용 알림(Free Tier Usage Alerts)을 활성화하면 프리 티어 한도의 85%에 도달했을 때 이메일을 받을 수 있다. 이 두 가지를 함께 사용하면 요금이 발생하기 전에 미리 경고를 받고, 요금이 발생한 후에도 CloudWatch 알람으로 이중 방어가 가능하다.

마무리 및 다음 단계 — CloudWatch 결제 알람으로 프리 티어 보호

CloudWatch 결제 알람 설정은 5분이면 완료되지만, 설정하지 않으면 월말에 예상치 못한 청구서를 받을 수 있다. 핵심은 세 가지다: us-east-1 리전 고정, SNS 구독 확인 완료, 결제 알람 사전 활성화.

다음 단계로 고려할 수 있는 작업:

  • AWS Budgets를 사용하면 서비스별, 연결 계정별 더 세밀한 예산 알람 설정이 가능하다 — AWS Budgets 공식 문서
  • AWS Cost Explorer로 서비스별 비용 분석 및 이상 감지 설정
  • 여러 AWS 계정을 운영한다면 AWS Organizations의 통합 결제(Consolidated Billing) 검토

요금 관련 공식 문서: Monitoring estimated charges with CloudWatch

용어 정리

용어설명
EstimatedChargesAWS/Billing 네임스페이스의 CloudWatch 지표. 계정 전체 또는 서비스별 추정 요금을 나타내며 약 6시간 주기로 업데이트됨
SNS 주제(Topic)메시지 발행-구독 채널. CloudWatch 알람이 메시지를 발행하면 구독자(이메일 등)에게 전달
구독 확인(Subscription Confirmation)SNS가 이메일 구독자에게 실제로 메시지를 전달하기 위해 필요한 수신자 동의 절차
INSUFFICIENT_DATACloudWatch 알람이 평가에 필요한 데이터 포인트를 아직 충분히 수집하지 못한 초기 상태
프리 티어(Free Tier)AWS 신규 계정에 제공되는 서비스별 무료 사용 한도. 서비스마다 한도 기준(시간, 요청 수, 용량 등)이 다름

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...
자세한 내용 보기

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

IAM User vs IAM Role 차이점 완전 정리 — EC2에서 S3 접근 시 무엇을 써야 하는가

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...
자세한 내용 보기