일본 기업의 AWS 비용 관리에서 흔한 7가지 실수

북미 시장을 겨냥해 쓰인 AWS 비용 관리 모범 사례가 일본 기업에 늘 깔끔하게 적용되지는 않습니다. 품의(稟議) 결재 문화, 4월에서 3월로 도는 연도 예산, 여름에 맞춰지는 인사 순환, 그리고 엔화 표시 사내 예산과 달러 표시 청구서의 조합. 이것들이 맞물리면서 기술적으로는 옳은 최적화가 조직적으로는 실행 불가능해지는 상황이 자주 생깁니다. 이 글은 제가 지난 10년 동안 거듭 보아 온 일곱 가지 실수 형태를 다룹니다.

1. 예약 인스턴스를 살 수 없다

기술적으로 보면 예약 인스턴스(RI)와 Savings Plans(SP)는 가장 즉효성 있는 비용 절감책입니다. 1년 약정이면 대략 30%, 3년이면 50% 정도 할인됩니다. 그런데도 일본 기업의 현장에서는 "살 수 없는" 경우가 빈발합니다.

이유는 기술이 아니라 절차입니다. 선결제는 보통 자본 지출(CAPEX)로 분류되는데, 이는 연도 예산에서 항목별 승인을 요구합니다. 예산이 RI 구매를 예상해 두지 않았다면 품의로 승인할 수 없습니다. 이 굴레를 이겨 내는 기업은, 월별 온디맨드 비용 데이터를 근거로 다음 연도에 RI 예산 항목을 명시적으로 신청하고, 주기가 시작되기 한참 전에 결재를 돌리는 곳입니다.

대처 — 전액 선결제(All Upfront) 대신 부분 선결제(Partial Upfront)나 무선결제(No Upfront)를 골라 CAPEX 분류를 통째로 피할 수 있습니다. SP는 RI보다 유연하고 승인을 통과시키기도 쉬우므로, RI를 고집할 합리적 이유가 없다면 SP를 중심으로 절감 전략을 짜세요.

2. 온프레미스 감각으로 예산을 세운다

온프레미스 시절의 용량 계획 습관, 즉 "월 얼마"라는 고정 배정이 그대로 AWS 예산 설계로 넘어옵니다. 클라우드 요금은 사용량에 따라 오르내리므로, 월 예산을 평탄하게 잡는 순간부터 실태와의 차이가 누적되기 시작합니다. 연도 말이 되면 그 차이가 "예산을 초과해 죄송합니다"라는, 해마다 반복되는 대화에 이릅니다.

대처 — 연도 예산은 분기별 허용 변동 폭을 명시해 승인받고, 월 예산은 전월 실적에 Cost Explorer의 예측(Forecast) 기능을 더해 미끄러지듯 조정합니다. AWS Budgets 알림을 절대 금액 임계값에서 예산 소진율 임계값으로 바꾸세요. 초과와 미달이 모두 더 빨리 보이게 됩니다.

3. 개발·검증 환경을 24시간 켜 둔다

평일 오전 9시부터 오후 6시까지만 쓰는 개발 환경을 밤에도 주말에도 EC2를 띄운 채 두는 ── 이 또한 드물지 않은 구도입니다. 이유는 단순합니다. "중지 스크립트를 누가 쓸 것인가"가 정해지지 않기 때문입니다. 인프라 담당이 쓰면 운영, 앱 담당이 쓰면 개발이라며 서로 떠넘깁니다.

대처 — AWS Instance Scheduler를 도입하거나, Lambda + EventBridge로 시작·중지 일정을 짭니다. 주말과 야간에 멈추기만 해도 한 주 시간의 약 67%를 줄일 수 있고, 개발 환경 EC2 비용은 거의 그 비율대로 줄어듭니다. 신규 워크로드라면 Aurora Serverless v2와 Fargate Spot을 조합해 중지조차 필요 없는 구성을 짤 수 있습니다.

4. 로그를 영구 보관한다

CloudWatch Logs에 무엇이든 다 흘려보내고 보존 기간을 "영구"로 설정해 둔 경우를 자주 봅니다. 요금 구조는 직관에 어긋납니다. 취득($0.50/GB)이 보관($0.03/GB-월)의 열 배가 넘습니다. 팀은 보존 기간만 신경 쓰고 취득량은 무시합니다.

대처 — 취득 단계에서 샘플링하거나 필터링하세요. 장기 보관이 필요한 로그는 Kinesis Firehose를 거쳐 S3에 직접 쓰고, S3 Intelligent-Tiering과 수명 주기 정책으로 차가운 데이터를 Glacier Deep Archive로 옮깁니다. CloudWatch Logs는 운영 조회용으로 최근 30일치에 한정하는 것이 표준적인 구성입니다.

5. 데이터 전송 요금을 놓친다

도쿄 리전(ap-northeast-1)의 데이터 전송 요금은, 특히 인터넷 방향 egress와 다른 리전으로의 전송이 청구서의 몇 %에서 10%를 차지하곤 합니다. AZ 간 통신($0.01/GB × 양방향)도 똑같이 흔한 맹점입니다. 영역 인식 라우팅 없이 배포된 서비스 메시는 아키텍처의 나머지에 견줘 터무니없이 큰 전송 요금을 만들어 냅니다.

대처 — S3, DynamoDB, ECR, CloudWatch 등 주요 AWS 서비스에 VPC 엔드포인트를 붙이면 해당 흐름의 NAT 게이트웨이 데이터 처리 요금($0.045/GB)이 사라집니다. AZ 간 통신은 토폴로지 인식 라우팅으로 억제하세요. 쿠버네티스라면 topology.kubernetes.io/zone 레이블, 서비스 메시라면 지역성 인식(locality-aware) 설정입니다.

6. 태그 통제가 이뤄지지 않는다

부서별로 비용을 배분하거나 리소스 담당자를 특정해야 할 때, 태그가 정비되어 있지 않으면 어떤 배분도 불가능합니다. 일본 조직은 정보 시스템 부문·각 사업부·자회사의 3층 구조인 경우가 많아, 누가 낼지를 나중에 정하려다 막혀 버리는 것이 전형적입니다.

대처 — AWS Organizations의 SCP(Service Control Policy)로 필수 태그 없는 리소스 생성을 막습니다. 최소한 Environment·Owner· CostCenter 세 가지만 필수로 걸어도 Cost Explorer의 배분이 작동합니다. 레거시로 돌고 있는 기존 리소스는 Resource Groups와 AWS Config를 조합해 재고 조사를 하고, 반년 정도에 걸쳐 100% 태그 부여로 끌고 갑니다.

7. 엔저 시 달러 표시 청구 리스크

청구는 미국 달러로 표시되어 월말에 확정되고, 각 회사의 회계 처리 시점 환율로 엔화 환산됩니다. 2022년 이후 달러-엔 환율의 진폭(115엔 → 150엔)의 영향으로, 기술적으로는 비용이 줄었는데도 엔화로는 늘어나는 현상이 현장에서 자주 관찰됩니다.

대처 — 환율 리스크는 기술 쪽에서 흡수할 수 없으므로 재무 쪽과의 연계가 필요합니다. Compute Savings Plans의 상한액을 달러로 합의한 뒤, 연말에 환율 변동에 대한 예산 재조정을 경리와 합의하는 방식이 일반적입니다. 규모가 작다면 법인 카드로 선결제해 구매 시점 환율로 고정하는 방법도 있습니다.

종합

일곱 가지 중 순수하게 기술로 해결할 수 있는 것은 3(환경 중지)·4(로그)· 5(데이터 전송) 셋입니다. 1(RI 품의)·2(월 예산)·6(태그 통제)·7(환율)은 조직 쪽 움직임이 따라오지 않으면 효과가 나지 않습니다. 개별 최적화보다, 분기에 한 번 재무와 현장이 함께 청구서를 보는 리뷰 틀을 만드는 편이 장기적으로 더 효과적입니다.

일상적인 비용 분석에는, Cost Explorer의 CSV를 직접 읽어 들여 주요 패턴을 추출하는 AWS Billing Analyzer를 활용하세요. 파일은 브라우저 안에서만 처리되므로, 계정 ID와 리소스 ARN을 포함한 청구 데이터를 외부로 보내지 않고 분석할 수 있습니다.