클라우드보안 비용 2026, Security Hub·GuardDuty·Defender 견적 기준

클라우드보안 비용 산정을 위한 보안 운영 회의와 클라우드 대시보드 장면 — 클라우드보안 예산은 도구 이름보다 자산 수, 로그량, 런타임 보호 범위, 내부 운영 책임에서 갈린다.

클라우드보안 비용을 검색하는 팀은 대개 Security Hub, GuardDuty, Defender for Cloud, SCC, CNAPP, SASE 견적을 한 표에 넣다가 막힌다.

문제는 제품명이 아니라 과금 축이다.

자산 단위, 이벤트 단위, 로그 GB, 런타임 vCPU, 스캔 GB, 사용자 좌석, 관리형 대응 범위가 섞이면 가장 싼 견적이 실제로는 비쌀 수 있다.

결론부터 말하면 클라우드보안 예산은 “어떤 제품을 살까”보다 “어떤 위험을 어떤 신호로 닫을까”를 먼저 고정해야 맞다.

이 글은 기존 CNAPP 선택 글과 달리 AWS Security Hub, Amazon GuardDuty, Microsoft Defender for Cloud, Google Security Command Center처럼 공식 가격 축이 보이는 항목을 예산표로 분해한다.

핵심 요약

클라우드보안 비용은 CSPM 구독료 하나가 아니라 자산, 이벤트, 로그, 런타임, 스캔, 운영 인력의 합산값이다.
AWS Security Hub는 resource unit과 add-on 구조를 먼저 보고, GuardDuty는 CloudTrail·EKS·vCPU·스캔 GB 단가를 따로 본다.
Microsoft Defender for Cloud는 무료 Foundational CSPM, 30일 체험, workload protection plan, Commit Unit 할인 구조를 구분해야 한다.
SASE와 CNAPP는 같은 클라우드보안 예산에 들어가도 구매 owner와 과금 단위가 다르므로 한 계약으로 묶기 전에 책임 경계를 나눠야 한다.

이 글이 필요한 사람

멀티클라우드 보안 예산을 처음 편성해야 하는 보안팀과 플랫폼팀
CNAPP, CSPM, GuardDuty, Security Hub, SASE 견적을 같은 표로 비교해야 하는 구매 담당자
월별 클라우드보안 비용이 로그량과 오토스케일링 때문에 흔들리는 FinOps 담당자
감사 대응을 위해 misconfiguration, runtime finding, malware scan, identity finding 증거를 남겨야 하는 컴플라이언스 담당자
도구를 이미 샀지만 finding owner와 remediation SLA가 없어 비용 대비 효과를 설명하지 못하는 CISO

클라우드보안 비용은 네 묶음으로 나눠야 한다

첫 묶음은 CSPM과 자산 인벤토리다.

여기서는 VM, 컨테이너 이미지, 서버리스 함수, IAM 사용자나 역할처럼 보안 평가 대상이 되는 리소스 수가 비용 축이 된다.

두 번째 묶음은 위협 탐지다.

GuardDuty 같은 탐지 항목은 CloudTrail 이벤트, S3 데이터 이벤트, DNS, VPC Flow Logs, EKS audit log, Lambda network activity처럼 이벤트와 로그량이 비용을 만든다.

세 번째 묶음은 런타임과 악성코드 스캔이다.

컨테이너와 EC2 런타임 보호는 vCPU 월 단위가 붙고, S3나 EBS 악성코드 검사는 스캔 GB와 객체 요청 수가 붙는다.

네 번째 묶음은 사용자·접근·엣지 보안이다.

SASE, Zero Trust, CASB, 브라우저 보안, DLP는 사용자 좌석이나 계약별 패키지로 가는 경우가 많아 cloud workload 단가와 직접 비교하면 안 된다.

비용 묶음	대표 공식 가격 축	숨어 있는 비용	먼저 물을 질문
CSPM·자산	resource unit, workload, serverless ratio	태그 정리, owner 매핑, 예외 승인	과금 대상 리소스와 무료 평가 대상이 어떻게 다른가
위협 탐지	million events, GB logs, finding ingestion	로그 보존, 중복 경보, SOC triage	CloudTrail·EKS·DNS·VPC 중 무엇을 켤 것인가
런타임·스캔	vCPU month, scanned GB, object requests	오토스케일링, 스냅샷, 격리 워크플로	피크 시간 vCPU와 업로드 GB를 누가 예측하는가
SASE·접근	user/month 또는 계약별 quote	디바이스 등록, 정책 운영, 네트워크 예외	클라우드 계정 보안과 사용자 접속 보안을 같은 owner가 볼 수 있는가
관리형 운영	case, workload, server, retainer	내부 조치 승인과 evidence 정리	도구가 finding을 만들면 누가 닫는가

이 조건이면 클라우드보안 비용을 긍정적으로 검토할 만하다.

프로덕션 계정이 여러 개이고 공개 노출, 관리자 권한, 컨테이너 취약점, S3 업로드 악성코드가 매월 반복 점검 대상인 경우다.

이 경우는 보류가 맞다.

계정 목록, 자산 태그, owner, 환경 구분이 없어서 어떤 finding이 실제 위험인지 판단할 수 없는 경우다.

공식 가격표 핵심 숫자부터 예산표에 넣는다

AWS Security Hub 가격표는 Essentials plan을 기본 범위로 설명하고, EC2 또는 Azure VM 1개를 1 resource unit으로 둔다.

같은 문서에서 Lambda 또는 Azure Function App 12개는 1 resource unit, ECR 또는 Azure container image 18개는 1 resource unit, IAM 사용자나 역할 125개는 1 resource unit으로 계산한다고 안내한다.

Security Hub Extended Plan의 cloud category 예시에는 Upwind Cloud Security가 리소스당 월 3.75달러, Upwind Sensors가 7.00달러, Upwind Shift Left가 5.25달러로 표시된다.

Amazon GuardDuty 가격표는 기능별 단가가 더 직접적이다.

공식 항목	공개 숫자	비용 의미	실무 해석
Security Hub resource unit	EC2 1개=1, Lambda 12개=1, ECR image 18개=1, IAM 125개=1	서로 다른 자산을 과금 단위로 환산	작은 서버리스와 IAM도 합치면 비용 축이 된다
Security Hub Extended Cloud	Upwind Cloud $3.75/resource/mo, Sensors $7.00, Shift Left $5.25	파트너 add-on은 별도 사용량 과금	CSPM 기본료와 런타임 센서를 분리해 본다
GuardDuty S3 data events	첫 500M은 $0.80/1M, 다음 500M은 $0.40/1M 예시	S3 데이터 이벤트가 많은 서비스는 이벤트 비용이 커짐	업로드·다운로드 많은 버킷부터 샘플링한다
GuardDuty EKS audit logs	첫 100M은 $1.60/1M, 다음 100M은 $0.80/1M 예시	Kubernetes audit log 양이 비용 변동 요인	클러스터별 이벤트 예측이 필요하다
GuardDuty Runtime Monitoring	첫 500 vCPU는 $1.50/vCPU, 다음 4,500 vCPU는 $0.75/vCPU 예시	런타임 보호는 오토스케일링과 연결	피크가 아니라 월간 vCPU 기준으로 본다
GuardDuty Malware Protection	S3 scan $0.09/GB, object $0.215/1K, EBS scan $0.03/GB 예시	파일 업로드 서비스는 스캔 GB와 요청이 같이 증가	무료 1,000 requests와 1GB 후 초과를 본다
GuardDuty RDS Protection	Aurora/RDS $1.00/vCPU, Aurora Serverless v2 $0.25/ACU 예시	DB 보호는 compute capacity와 연결	DB 증설 계획을 보안 예산에 넣는다

Microsoft Defender for Cloud 가격표는 첫 30일 무료 이후 plan별 과금으로 전환된다고 설명한다.

같은 가격표에서 Foundational CSPM은 Free로 표시되고, serverless resource는 함수 또는 web app 8개를 1 billable resource로 본다.

Defender for Containers는 Kubernetes worker node vCore 기준이며 월 20회 vulnerability assessment가 charged vCore마다 포함된다는 설명도 예산표에 넣어야 한다.

Microsoft는 1년 pre-purchase Commit Unit에서 tier에 따라 10%부터 최대 22% 할인을 제시한다.

Defender Experts for Servers 예시는 월 총 uptime hours를 해당 월 총시간으로 나눠 billable server count를 계산한다.

Defender, Security Hub, SCC는 같은 이름의 보안센터가 아니다

Microsoft Defender for Cloud는 CNAPP 관점에서 CSPM, DevOps security, workload protection을 한 포털 안에서 묶는다.

AWS Security Hub는 risk analytics, vulnerability management, posture management, response management를 Security Hub 중심으로 통합하고 GuardDuty와 Inspector 같은 신호를 연결한다.

Google Cloud Security Command Center는 vulnerability detection, threat detection, postures and policies, compliance, data export를 중심으로 Standard, Premium, Enterprise tier를 나눈다.

이 세 제품은 모두 클라우드보안 범주에 들어가지만, 과금과 운영 책임은 다르다.

제품 축	먼저 보는 범위	비용 확인 포인트	중복 주의
Defender for Cloud	Azure·multicloud CSPM과 workload plan	무료 CSPM, 30일 trial, vCore, serverless ratio, Commit Unit	기존 EDR·Defender XDR 계약과 범위 확인
AWS Security Hub	AWS와 Azure resource unit 기반 통합 보안	Essentials, Threat Analytics, Extended Plan, partner add-on	Inspector·GuardDuty가 consolidated 되는 부분과 별도 과금 구분
Amazon GuardDuty	CloudTrail·DNS·VPC·EKS·RDS·S3 위협 탐지	event million, GB, vCPU, ACU, object request	모든 계정에 한 번에 켜면 이벤트 비용 급증
Google SCC	Google Cloud posture, threat, compliance, export	tier, activation level, BigQuery·Pub/Sub export 운영	SIEM 전송 비용과 finding triage 중복
SASE·Zero Trust	사용자 접속, 사설 앱, 브라우저, 데이터 통제	user/month 또는 sales quote, 네트워크 패키징	workload 보안과 사용자 접속 보안을 같은 지표로 비교 금지

이 조건이면 Defender for Cloud나 Security Hub 중심으로 시작한다.

워크로드 보호, posture drift, 취약점, storage exposure처럼 cloud account 안의 위험을 먼저 줄여야 하는 경우다.

이 조건이면 SASE 예산을 따로 세운다.

재택·협력사·사설 앱 접속·브라우저 보안이 핵심이고, cloud workload posture보다 사용자 접속 통제가 급한 경우다.

클라우드보안 도입 순서는 계정 등록보다 owner 정리다

도구를 먼저 켜면 finding은 바로 늘지만 닫히는 속도는 그대로일 수 있다.

그래서 첫 작업은 계정과 프로젝트 등록이 아니라 remediation owner를 정하는 것이다.

프로덕션, 스테이징, 개발, 샌드박스 계정을 분리하고 비용 태그와 보안 owner 태그를 맞춘다.
인터넷 공개 자산, 관리자 권한, 민감 데이터 저장소, 컨테이너 런타임을 critical asset으로 표시한다.
CSPM은 read-only 평가부터 켜고, 자동 remediation은 변경 승인 절차가 생긴 뒤에 켠다.
GuardDuty나 threat analytics는 한두 production 계정에서 이벤트 비용을 2주간 관찰한 뒤 전체 계정으로 넓힌다.
런타임 보호는 오토스케일링이 큰 서비스보다 고정 규모의 핵심 서비스부터 켜서 vCPU 월비용을 확인한다.
S3나 파일 업로드 서비스는 malware scan GB와 object request 기준을 별도 알림으로 잡는다.
월간 리뷰에는 총비용, 고위험 finding, 미해결 owner, false positive, 예외 정책 만료일을 함께 올린다.
SIEM이나 SOAR로 finding을 내보낼 때는 중복 경보와 저장 비용을 다시 산정한다.

이 순서를 지키면 클라우드보안 도구가 비용만 늘리는 대시보드로 남지 않는다.

반대로 owner 없이 모든 계정에 기능을 켜면 finding도 비용도 늘지만 보안 리스크는 잘 줄지 않는다.

실무 시나리오 1: AWS 중심 SaaS 회사의 Security Hub와 GuardDuty

직원 180명 SaaS 회사가 AWS 계정 14개, EKS 클러스터 6개, S3 업로드 버킷 18개를 운영한다고 가정하자.

이 경우 클라우드보안 비용은 Security Hub Essentials만 보면 부족하다.

S3 data event, EKS audit log, runtime vCPU, malware scan GB가 트래픽과 배포량에 따라 같이 흔들린다.

첫 달에는 모든 계정에 runtime monitoring을 켜기보다 결제, 인증, 고객 파일 업로드 서비스부터 범위를 잡는 편이 안전하다.

이 조건이면 GuardDuty usage page에서 data source별 비용을 보고 월간 기준선을 만든 뒤 예산 알림을 설정한다.

실무 시나리오 2: Azure 기반 제조사의 Defender for Cloud

제조사는 Azure VM, SQL, Storage, 온프레미스 서버, 일부 AWS 계정이 섞이는 경우가 많다.

이 조건이면 Defender for Cloud의 Foundational CSPM과 workload protection plan을 구분해서 봐야 한다.

무료 CSPM 추천과 유료 plan의 threat protection을 같은 효과로 보고 예산을 줄이면 실제 침해 탐지 범위가 빈다.

Kubernetes worker node vCore, storage transaction, serverless ratio, Defender Experts billable server count를 별도 표로 빼야 견적 논쟁이 줄어든다.

보안팀은 공장망과 레거시 서버가 Arc로 연결되는지, 연결하지 못하는 자산은 어떤 보완 통제로 볼지 먼저 정해야 한다.

실무 시나리오 3: 멀티클라우드와 SASE를 한 번에 사려는 조직

멀티클라우드 조직은 CNAPP와 SASE를 한 벤더 제안서로 받는 일이 많다.

이 경우 계약은 묶을 수 있어도 운영 KPI는 나눠야 한다.

CNAPP의 KPI는 공개 노출, 과다 권한, 이미지 취약점, runtime finding, remediation 시간이다.

SASE의 KPI는 사용자 접속 성공률, 사설 앱 정책, 피싱 차단, 브라우저 제어, 데이터 반출 통제다.

이 조건이면 한 견적서 안에서도 cloud workload budget과 user access budget을 나눠 승인받는 편이 낫다.

견적 비교표는 단가보다 범위 누락을 잡아야 한다

보안 도구 견적서는 제품별 표현이 달라 단순 월액 비교가 잘 맞지 않는다.

Security Hub resource unit, GuardDuty 이벤트, Defender workload plan, SCC tier, Cloudflare SASE package, Wiz modular license를 한 줄 단가로만 놓으면 누락이 생긴다.

비교 질문	예산에 넣을 값	빠지면 생기는 리스크	판단 기준
모든 production 계정이 포함됐나	계정 수, 프로젝트 수, subscription 수	어둠의 계정에서 사고가 난다	계정 등록률 100% 전까지 자동화 보류
과금 대상 resource unit은 무엇인가	VM, function, image, identity 환산	서버리스와 IAM이 비용표 밖에 남는다	월별 리소스 인벤토리와 대조
이벤트와 로그량은 얼마나 변하나	CloudTrail, EKS, VPC, DNS, S3 event	트래픽 이벤트가 보안 과금으로 전환된다	2주 샘플 후 예산 알림 설정
런타임 보호가 필요한가	vCPU month, sensor, workload count	컨테이너 침해는 늦게 보인다	핵심 서비스부터 단계 적용
finding을 누가 닫나	보안팀, 플랫폼팀, 서비스 owner 시간	비용은 발생하지만 위험이 닫히지 않는다	SLA와 owner 표 없으면 구매 보류

이 조건이면 비싼 견적도 선택할 수 있다.

고위험 finding을 줄이고, 자동 owner routing이 되며, 감사 증거가 한 달 단위로 남는 경우다.

이 조건이면 싼 견적을 고르는 편이 낫다.

클라우드 계정 수가 적고 내부 보안팀이 이미 finding triage와 remediation을 잘 닫는 경우다.

실무 스켈레톤: 클라우드보안 비용 구조 YAML

아래 YAML은 견적서를 받기 전에 내부 자산과 비용 동인을 정리하기 위한 출발점이다.

# cloud-security-cost-model.yaml
# 목적: 클라우드보안 비용을 자산, 로그, 런타임, 데이터, 운영 인력으로 분리한다.
# 실제 금액은 공식 가격표, 리전, 계약, 환율, 프로모션, 사용량에 맞춰 다시 계산한다.

company_profile:
  cloud_accounts:
    aws: 14
    azure: 5
    google_cloud: 3
  production_workloads:
    virtual_machines: 260
    containers: 780
    serverless_functions: 420
    databases: 48
    storage_buckets: 190
  compliance:
    - personal_data
    - financial_audit
    - customer_contracts

coverage_scope:
  posture_management:
    include: [cspm, asset_inventory, misconfiguration, compliance_mapping]
    owner: security-platform
  workload_protection:
    include: [runtime_monitoring, malware_scan, container_vulnerability, database_threat]
    owner: cloud-platform
  threat_detection:
    include: [cloudtrail, dns, vpc_flow, eks_audit, identity_activity]
    owner: soc
  edge_and_access:
    include: [sase, private_access, browser_isolation, data_loss_control]
    owner: it-security

cost_drivers:
  resource_units:
    basis: vm_container_image_lambda_identity_equivalent
    risk: small_assets_can_turn_into_billable_units
  event_volume:
    basis: million_events_gb_logs_retention_days
    risk: audit_log_growth_changes_monthly_bill
  runtime_vcpu:
    basis: protected_vcpu_month
    risk: autoscaling_changes_security_cost
  malware_scan:
    basis: scanned_gb_and_object_requests
    risk: upload_service_can_create_spend_spikes
  managed_operation:
    basis: triage_hours_case_review_policy_tuning
    risk: tool_subscription_does_not_remove_internal_owner

acceptance_metrics:
  - coverage_percent_by_critical_asset
  - monthly_findings_closed_with_owner
  - high_risk_public_exposure_mttd
  - guardrail_false_positive_rate
  - monthly_security_spend_per_production_service

핵심은 CSPM, workload protection, threat detection, SASE를 한 줄로 합치지 않는 것이다.

각 비용 축의 owner가 달라야 월말 사용료와 실제 위험 감소를 함께 설명할 수 있다.

GuardDuty 월비용 점검 스크립트 예시

아래 Python 예시는 공식 가격표의 공개 예시 단가를 내부 계산표에 옮기는 방식만 보여주는 검증용 스켈레톤이다.

#!/usr/bin/env python3
# guardduty_monthly_cost_check.py
# 목적: 클라우드보안 견적을 리소스 수, 이벤트, vCPU, 스캔 GB 기준으로 나눠 본다.
# 공식 가격표의 리전별 단가를 최신 값으로 교체한 뒤 내부 검토용으로만 사용한다.

from dataclasses import dataclass

@dataclass
class AwsSecurityInput:
    s3_data_events_million_first_tier: float
    s3_data_events_million_second_tier: float
    eks_events_million_first_tier: float
    eks_events_million_second_tier: float
    runtime_vcpu_first_tier: int
    runtime_vcpu_second_tier: int
    s3_malware_scan_gb: float
    s3_object_thousand: float
    ebs_scan_gb: float
    rds_vcpu: int


def estimate_guardduty_us_east(i: AwsSecurityInput) -> float:
    return round(
        i.s3_data_events_million_first_tier * 0.80
        + i.s3_data_events_million_second_tier * 0.40
        + i.eks_events_million_first_tier * 1.60
        + i.eks_events_million_second_tier * 0.80
        + i.runtime_vcpu_first_tier * 1.50
        + i.runtime_vcpu_second_tier * 0.75
        + i.s3_malware_scan_gb * 0.09
        + i.s3_object_thousand * 0.215
        + i.ebs_scan_gb * 0.03
        + i.rds_vcpu * 1.00,
        2,
    )

sample = AwsSecurityInput(
    s3_data_events_million_first_tier=120,
    s3_data_events_million_second_tier=0,
    eks_events_million_first_tier=40,
    eks_events_million_second_tier=0,
    runtime_vcpu_first_tier=180,
    runtime_vcpu_second_tier=0,
    s3_malware_scan_gb=250,
    s3_object_thousand=8,
    ebs_scan_gb=180,
    rds_vcpu=64,
)

print('estimated_monthly_usd', estimate_guardduty_us_east(sample))

실제 적용 전에는 리전, 날짜, 계정별 volume tier, 무료 사용량, 계약 할인을 다시 확인해야 한다.

그래도 이런 스크립트를 두면 S3 이벤트나 EKS audit log가 늘 때 보안비가 왜 늘었는지 설명하기 쉽다.

수용 기준 정책 JSON 예시

아래 JSON은 도구 설정이 아니라 구매 승인 전 보안팀과 플랫폼팀이 합의할 수용 기준 예시다.

{
  "cloud_security_acceptance_gate": {
    "coverage": {
      "critical_accounts": "100_percent_registered",
      "production_assets": "owner_and_environment_tag_required",
      "public_exposure": "daily_review_required"
    },
    "cost_control": {
      "monthly_budget_owner": "security-platform-lead",
      "event_volume_alarm": "80_percent_of_expected_monthly_events",
      "runtime_monitoring_rollout": "start_with_production_then_expand"
    },
    "response": {
      "severity_1": "soc_call_plus_ticket",
      "severity_2": "ticket_with_asset_owner",
      "false_positive_review": "weekly_until_stable"
    }
  }
}

정책 파일은 예산 통제를 회계팀에만 넘기지 않기 위한 장치다.

보안팀이 어떤 finding을 닫아야 하는지와 플랫폼팀이 어떤 자동화까지 허용하는지가 같이 적혀 있어야 한다.