AWS 10 계정·비용 관리 — Organizations·Control Tower·RAM·Cost Explorer·Budgets·Trusted Advisor·Service Quotas
고친 사람 github-actions[bot]
처음에는 AWS 계정 하나에 개발 서버와 운영 서버를 같이 둡니다. 그러다 누군가 개발 작업을 하다 실수로 운영 DB 를 건드리고, 월말 청구서에서 어느 서비스가 돈을 먹었는지 한참 뒤지고, 새 리전에 서버를 띄우다 「vCPU 한도를 넘었다」는 오류를 만납니다. 그러면 질문이 생깁니다. 계정을 나누면 그 계정들을 어떻게 한꺼번에 다루고, 돈과 한도는 어디서 지켜볼까요?
이 편은 그 질문에 답하는 도구 일곱을 봅니다. 앞의 셋은 계정을 묶고 나누는 쪽입니다. 계정 여럿을 한 조직으로 묶는 Organizations, 그 조직의 기본 틀을 한 번에 세워 주는 Control Tower, 한 계정에서 만든 리소스를 다른 계정과 나누는 Resource Access Manager(RAM)입니다. 뒤의 넷은 지켜보는 쪽입니다. 지난 돈을 쪼개 보는 Cost Explorer, 넘기 전에 알리는 Budgets, 낭비와 빈틈을 점검하는 Trusted Advisor, 한도를 보고 올리는 Service Quotas 입니다. 끝에서는 계정 몇 개를 묶은 작은 팀이 이 도구들에 한 달 얼마를 내는지 셈합니다.
이 일곱 가운데 다수는 추가 요금이 없고, 요금이 있는 것도 요금 페이지에 리전 구분 없이 한 값으로 나옵니다. 값과 한도는 전부 2026-11-13 에 확인했습니다. 같은 날 AWS 수명 단계 페이지(유지보수·종료 예정·완전 종료)에는 일곱 가운데 어느 것도 올라 있지 않았습니다(AWS Lifecycle Changes).
지도
flowchart TD
START["계정이 늘고<br/>청구서가 커진다"] --> Q1{"계정을 다루는 일인가<br/>돈과 한도를 보는 일인가"}
Q1 -- "계정" --> Q2{"무엇을 하려나"}
Q2 -- "묶고 상한을 건다" --> ORG["Organizations"]
Q2 -- "기본 틀을<br/>한 번에 세운다" --> CT["Control Tower"]
Q2 -- "리소스를<br/>계정끼리 나눈다" --> RAM["RAM"]
Q1 -- "돈과 한도" --> Q3{"무엇을 보려나"}
Q3 -- "이미 쓴 돈" --> CE["Cost Explorer"]
Q3 -- "넘을 것 같은 돈" --> BUD["Budgets"]
Q3 -- "낭비와 빈틈" --> TA["Trusted Advisor"]
Q3 -- "다가오는 한도" --> SQ["Service Quotas"]
위쪽 세 갈래는 순서가 있습니다. Control Tower 와, RAM 으로 조직·OU 단위로 나누는 공유는 Organizations 의 조직이 있어야 돌므로, 계정을 나누기로 했다면 Organizations 가 먼저입니다. 아래쪽 넷은 계정이 하나여도 씁니다. 사람의 로그인을 계정마다 나눠 주는 IAM Identity Center 는 05-1편에서 봤고, 조직 전체의 API 기록을 남기는 CloudTrail 과 리소스 설정을 기록하는 Config 는 06편에서 봤습니다.
1. Organizations — 계정 여럿을 한 조직으로 묶는다
왜 계정을 나눌까요? AWS 문서는 계정을 권한·보안·비용·워크로드의 자연스러운 경계라고 부릅니다. 개발 계정의 관리자 권한은 운영 계정에 닿지 않고, 계정마다 청구액이 따로 잡힙니다. 문제는 계정이 늘면 결제 수단, 보안 설정, 누가 무엇을 못 하게 막을지를 계정마다 따로 챙겨야 한다는 점입니다. AWS Organizations 는 이 계정들을 조직(organization) 하나로 묶습니다. 추가 요금은 없습니다(What is AWS Organizations? · AWS Organizations FAQs).
조직을 만든 계정이 관리 계정(management account)이 되고, 초대하거나 새로 만든 계정은 멤버 계정(member account)이 됩니다. 멤버 계정은 OU(organizational unit, 계정을 담는 폴더)로 묶습니다. 「운영」 OU, 「개발」 OU 처럼 묶어 두면 규칙을 OU 단위로 걸 수 있습니다. 조직의 맨 위에는 조직 루트(organization root)라는 그릇이 하나 있고, OU 는 그 아래로 다섯 단계까지 겹칠 수 있습니다. 로그인하는 루트 사용자와는 다른 것입니다.
돈 쪽에서 얻는 것은 통합 결제(consolidated billing)입니다. 관리 계정이 멤버 계정의 요금을 전부 내고 청구서는 한 장으로 옵니다. 사용량도 합쳐 셉니다. S3 처럼 많이 쓸수록 단가가 내려가는 요금 구간과 예약 인스턴스·Savings Plans 할인을 조직 안의 계정들이 나눠 받으므로, 계정마다 따로 낼 때보다 싸질 수 있습니다. 통합 결제도 추가 요금이 없습니다(Consolidating billing for AWS Organizations).
SCP — 계정 전체에 거는 권한 상한
권한 쪽에서 얻는 것은 SCP(service control policy, 서비스 제어 정책)입니다. IAM 정책과 거의 같은 문법으로 쓰지만 권한을 주지는 않습니다. 멤버 계정의 IAM 사용자와 역할이 최대로 할 수 있는 일을 정할 뿐입니다. 예를 들어 「서울과 도쿄 밖의 리전은 쓰지 못한다」는 SCP 를 개발 OU 에 붙이면, 그 OU 의 계정 관리자가 자기 역할에 AdministratorAccess 를 붙여도 다른 리전에는 아무것도 못 띄웁니다. 멤버 계정의 루트 사용자도 SCP 에 묶입니다. 05-1편의 정책 평가 그림에서 「상한 정책」으로 본 것이 이것입니다.
SCP 가 닿지 않는 곳도 있습니다. 관리 계정의 사용자와 역할에는 SCP 가 전혀 걸리지 않고, AWS 서비스가 내 계정에서 일하려고 스스로 만드는 서비스 연결 역할(service-linked role)에도 걸리지 않습니다. 그래서 관리 계정은 결제와 조직 관리만 하고 워크로드는 멤버 계정에 두는 것이 맞습니다. SCP 를 켜면 모든 계정과 OU 에 모든 것을 허용하는 기본 정책 FullAWSAccess 가 붙고, 그 위에 Deny 를 더하는 식으로 씁니다. 이 기본 정책을 대신할 허용 정책 없이 떼면 멤버 계정의 모든 동작이 막힙니다. AWS 는 SCP 를 조직 루트에 바로 붙이지 말고, 시험용 OU 에 계정을 몇 개씩 옮겨 가며 확인하라고 권합니다(Service control policies (SCPs)). 짝이 되는 RCP(resource control policy, 리소스 제어 정책)도 있습니다. SCP 가 내 계정 사람들이 할 수 있는 일을 막는다면, RCP 는 S3 버킷 같은 내 리소스에 누가 들어올 수 있는지를 막습니다(Resource control policies (RCPs)).
조직의 계정 수는 기본 10개이고, Service Quotas(7절)로 늘려 달라고 요청합니다. 새로 만든 조직은 10개보다 낮게 시작할 수도 있습니다(Quotas and service limits for AWS Organizations).
조직에는 기능 집합이 둘 있습니다. 기본값인 모든 기능(all features)이어야 SCP 와 다른 서비스 연동을 쓸 수 있고, 통합 결제 기능만 켠 조직은 청구서를 합치는 일만 합니다. 통합 결제만에서 모든 기능으로는 바꿀 수 있지만 거꾸로는 못 돌립니다(Enabling all features). 또 하나, 가입 때 무료 요금제(Free account plan)를 고른 계정은 조직에 들어가는 순간 유료 요금제로 바뀝니다(Choosing a plan).
조직 자체는 공짜이니, 망설일 이유는 돈이 아니라 관리 계정을 지키는 일과 SCP 를 잘못 걸었을 때의 여파입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 개발·운영을 계정으로 나누고 청구서는 한 장으로 받고 싶을 때 | 계정 하나로 충분하고 나눌 이유가 없을 때 | 관리 계정이 모든 요금을 내므로 그 계정의 접근을 가장 단단히 지켜야 한다 |
| 「이 리전 밖 금지」「CloudTrail 끄기 금지」를 계정 관리자도 못 풀게 걸 때 | 계정 안의 특정 역할 하나만 좁히고 싶을 때(→ IAM 정책·권한 경계) | SCP 를 잘못 걸면 그 아래 계정 전체가 막힌다. 시험용 OU 로 먼저 확인한다 |
| 관리 계정은 결제·조직 관리만 맡길 때 | 관리 계정에서 서버를 돌릴 때 | 관리 계정에는 SCP 가 안 걸려 상한이 없다 |
계정을 새로 만들 때마다 로그 수집, 로그인, 금지 규칙을 같은 모양으로 다시 세워야 한다면 그 일을 묶어 주는 Control Tower 로 넘어갑니다.
2. Control Tower — 조직의 기본 틀을 한 번에 세운다
Organizations 는 계정을 묶는 그릇만 줍니다. 로그를 어느 계정에 모을지, 직원이 어떻게 로그인할지, 어떤 SCP 를 기본으로 걸지는 직접 짜야 합니다. AWS Control Tower 는 이것을 AWS 가 권하는 모양대로 한 번에 세웁니다. Organizations 와 IAM Identity Center 같은 서비스를 엮어 한 시간 안에 랜딩 존(landing zone, 보안·규정 모범 사례대로 짠 여러 계정 환경)을 만들고, 그 뒤에도 계속 지킵니다(What Is AWS Control Tower?).
콘솔로 랜딩 존을 세우면 Security OU 와 선택에 따라 Sandbox OU 가 생깁니다. 랜딩 존 3.3 까지는 로그를 모으는 Log Archive 계정과 감사용 Audit 계정이 Security OU 에 들어갔습니다. 4.0 부터는 Security OU 가 필수가 아니어서 OU 구조를 직접 정합니다. Config·CloudTrail 같은 서비스 연동 계정은 조직 루트 바로 아래의 지정 OU 에 만들거나 들여옵니다. IAM Identity Center 디렉터리도 미리 만든 그룹과 함께 세워집니다(How AWS Control Tower works).
랜딩 존을 지키는 규칙을 컨트롤(control, 예전 이름은 가드레일)이라 부릅니다. 세 가지가 있고, 각각 앞 편에서 본 장치 위에 얹힙니다. 예방 컨트롤은 SCP·RCP 로 동작 자체를 막습니다. 탐지 컨트롤은 Config 규칙으로 어긋난 리소스를 찾아 표시합니다. 사전 컨트롤은 CloudFormation 훅으로 배포 전에 템플릿을 검사해, 규칙에 어긋나면 리소스를 만들지 않습니다(How controls work). 필수 컨트롤은 끌 수 없고, 나머지는 OU 마다 골라 켭니다. 예방 컨트롤은 SCP 와 같은 까닭으로 관리 계정에는 걸리지 않습니다.
그럼 계정을 새로 만들면 어떻게 될까요? Control Tower 에서는 Account Factory(미리 승인한 설정으로 계정을 찍어 내는 틀)로 계정을 만들고, 만들어지는 순간 그 OU 의 컨트롤이 붙습니다.
Control Tower 자체는 돈을 받지 않습니다. 돈은 Control Tower 가 켜 두는 Config, CloudTrail, CloudWatch, SNS, S3 같은 서비스에서 나옵니다(AWS Control Tower pricing). 이 가운데 Config 는 리소스가 바뀔 때마다 구성 항목을 남기므로, 리소스가 자주 생겼다 사라지는 계정에서 값이 커집니다. AWS 요금 페이지의 예시는 계정·리전마다 스팟 인스턴스 100대와 오토 스케일링 리소스 100개가 하루 열 번 늘고 줄면 구성 항목이 하루 4,000개, 계정·리전당 하루 $12, 한 달 $372 가 나온다고 셉니다(예시는 리전을 밝히지 않고, 구성 항목 하나에 $0.003, 한 달을 31일로 셈).
틀을 남이 짜 준다는 것은 그 틀 밖으로 나가기 어렵다는 뜻이기도 합니다. Control Tower 가 만든 리소스를 Control Tower 밖에서 고치거나 지우면 랜딩 존이 알 수 없는 상태가 됩니다. 이미 Config 레코더나 CloudTrail 트레일을 따로 돌리던 계정을 편입하면 그것을 먼저 정리해야 하고, 트레일을 남겨 두면 요금이 두 번 붙을 수 있습니다(Prerequisites).
Control Tower 는 계정 수가 늘어 매번 손으로 세우기 버거워질 때 값을 합니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 계정을 자주 새로 만들고 그때마다 같은 로그·로그인·금지 규칙이 붙어야 할 때 | 계정 두세 개를 오래 그대로 쓸 때(→ Organizations 와 SCP 몇 개면 된다) | Control Tower 가 관리하는 리소스는 Control Tower 를 거쳐서만 고친다 |
| 규정 검사에 「모든 계정의 로그가 한 곳에 모인다」를 보여야 할 때 | 이미 Config·CloudTrail 을 계정마다 자체 구성으로 돌리고 있을 때 | 기존 레코더·트레일을 정리하고 편입해야 한다 |
| 리소스가 오래 사는 워크로드 | 스팟·오토 스케일링으로 리소스가 하루에도 수없이 생겼다 사라지는 계정 | Config 구성 항목 요금이 변화 횟수만큼 는다 |
계정 틀을 CloudFormation·Terraform 으로 직접 짜는 팀도 많습니다. Control Tower 의 컨트롤을 쓰지 않고 SCP 몇 개와 조직 트레일만 둔다면 Organizations 만으로 충분합니다.
3. Resource Access Manager — 만든 리소스를 다른 계정과 나눈다
계정을 나누고 나면 반대 문제가 생깁니다. 네트워크 팀이 공들여 짠 VPC 를 계정마다 똑같이 하나씩 또 만들어야 할까요? AWS Resource Access Manager(RAM)는 한 계정이 가진 리소스를 다른 계정이 쓰게 해 줍니다. 리소스를 리소스 공유(resource share)에 담고, 받을 대상(계정 ID, 조직 전체, OU, 일부 리소스는 IAM 역할·사용자)과 관리형 권한(받는 쪽이 그 리소스로 할 수 있는 일의 상한)을 고릅니다. 받는 계정의 관리자는 그 상한 안에서 다시 IAM 정책으로 자기 사람들에게 나눠 줍니다. 리소스의 주인은 바뀌지 않습니다. RAM 사용과 공유에는 추가 요금이 없고, 리소스 요금은 각 서비스의 규칙을 따릅니다(What is AWS Resource Access Manager?).
S3 버킷 정책처럼 자원 기반 정책으로도 다른 계정에 접근을 열 수 있는데, RAM 을 거치면 세 가지가 다릅니다. 계정 ID 를 일일이 적지 않고 조직이나 OU 단위로 줄 수 있습니다. 받은 쪽 콘솔과 API 에는 그 리소스가 자기 것처럼 보입니다. 주인 쪽에서는 누가 받았는지 한눈에 봅니다. 조직 안에서 공유를 켜 두면 초대 없이 바로 전해지고, 조직 밖 계정에는 초대를 보내 받아들여야 쓸 수 있습니다. 리전 리소스는 같은 리전의 리소스 공유에만 담기므로, 서울 서브넷은 서울의 리소스 공유에 담습니다. 리전이 없는 전역 리소스는 버지니아 북부(us-east-1)의 리소스 공유로 나눕니다(Sharing Regional resources compared to global resources).
가장 흔한 예가 VPC 서브넷 공유입니다. 네트워크 계정이 VPC 를 만들고 서브넷을 같은 조직의 다른 계정들에 나눠 주면, 각 계정은 그 서브넷에 자기 EC2·RDS·Lambda 를 띄웁니다. 받은 계정끼리는 서로의 리소스를 보거나 고치지 못합니다. 다만 서브넷은 조직 밖 계정에는 나눌 수 없고, 같은 조직 안에서만 나눕니다. 요금은 갈라서 냅니다. 받은 계정은 자기 인스턴스와 가용 영역 간 전송료를 내고, VPC 주인은 NAT 게이트웨이·Transit Gateway·VPC 엔드포인트의 시간 요금과 처리 요금, 공인 IPv4 주소 요금을 냅니다(Billing and metering for owner and participants). 서브넷 말고도 Transit Gateway, Route 53 Resolver 규칙, 접두사 목록, Aurora DB 클러스터(다른 계정이 복제해 쓰도록), 사설 인증 기관, VPC Lattice 서비스 네트워크 같은 것을 나눕니다(Shareable AWS resources). 04-1편의 Transit Gateway 를 여러 계정이 같이 쓸 때도 RAM 으로 나눕니다.
RAM 은 같은 것을 계정마다 다시 만들지 않게 해 주는 대신, 그 리소스를 가진 계정 하나에 여럿이 기대게 만듭니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 네트워크 팀이 VPC 하나를 짜고 여러 팀 계정이 그 서브넷에 띄울 때 | 팀마다 네트워크 설계를 따로 해야 할 때 | 공유 서브넷의 NAT·엔드포인트 요금은 VPC 주인 계정이 낸다 |
| Transit Gateway·사설 인증 기관처럼 비싼 것을 조직에 하나만 둘 때 | 서울 리소스를 다른 리전 계정이 그 리전에서 쓰려 할 때 | 리전 리소스는 같은 리전의 리소스 공유에만 담긴다 |
| 조직 전체나 OU 단위로 서브넷을 한꺼번에 열 때 | 조직 밖 계정에 서브넷을 열 때 | 서브넷 공유는 같은 조직 안에서만 된다 |
RAM 이 지원하지 않는 리소스라면 자원 기반 정책이나 다른 계정의 IAM 역할을 맡는 방식(05-1편)으로 엽니다.
4. Cost Explorer — 어디서 돈이 나갔나 본다
월말 청구서는 서비스별 합계만 보여 줍니다. 「지난달보다 EC2 가 왜 30% 늘었지?」에 답하려면 날짜·계정·리전·인스턴스 종류로 쪼개 봐야 합니다. AWS Cost Explorer 는 비용과 사용량을 그래프와 표로 쪼개 보는 도구입니다. 기본으로 지난 13개월을 보고(다년 데이터를 켜면 월 단위로 38개월까지), 앞으로 18개월의 지출을 예측합니다. 처음 켜면 이번 달 데이터는 24시간쯤 뒤에, 나머지는 며칠 더 지나 나타납니다. 그 뒤로는 적어도 24시간에 한 번 새로 고칩니다. 한 번 켜면 끌 수 없습니다(Analyzing your costs and usage with AWS Cost Explorer · Multi-year data at monthly granularity).
서비스·계정 말고 「주문 서비스가 쓴 돈」처럼 내 기준으로 쪼개려면 리소스에 태그를 붙이고 그 태그를 비용 할당 태그(cost allocation tag)로 켜야 합니다. 켜는 것은 조직의 관리 계정이나 조직에 속하지 않은 단독 계정만 할 수 있고, 켠 태그가 결제 콘솔에 나타나기까지 24시간까지 걸립니다(Organizing and tracking costs using AWS cost allocation tags). 태그는 처음부터 붙여 두는 편이 낫습니다.
콘솔에서 보는 것은 무료입니다. 값이 붙는 것은 두 가지입니다. 스크립트나 대시보드가 API 로 비용을 가져가면 요청마다 받습니다. 한 시간 단위로 쪼개 보는 기능을 켜면 지난 14일치 시간 단위 사용량 기록을 보관하는 값을 날마다 받습니다. 기록 하나는 리소스 하나의 사용량 종류 하나를 한 시간 단위로 적은 줄입니다(AWS Cost Explorer Pricing).
Cost Explorer · 리전 구분 없음 · 2026-11-13
콘솔 화면 무료
API 기본 결제 보기로 페이지 하나 요청당 $0.01
시간 단위 보기 보관 중인 기록 하나에 하루 $0.00000033
(기록 1,000개를 한 달 두면 약 $0.01)
EC2 한 대를 한 달 내내 켜 둘 때
24시간 × 14일 = 기록 336개를 늘 보관
336 × $0.00000033 × 30일 ≈ $0.003
API 결과가 여러 페이지로 나뉘면 페이지마다 한 번입니다. 여러 결제 보기를 합친 사용자 지정 결제 보기로 부르면 합친 원천 하나당 $0.01 이라, 원천이 다섯이면 한 번에 $0.05 입니다.
Cost Explorer 는 지난 돈을 쪼개 보여 줄 뿐 알리거나 막지는 않습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 「지난달보다 왜 늘었나」를 서비스·계정·태그로 쪼개 찾을 때 | 오늘 오후에 생긴 지출을 바로 알아야 할 때 | 데이터는 하루에 한 번쯤 새로 고쳐진다 |
| 팀·기능별 비용을 태그로 나눠 볼 때 | 태그를 안 붙인 채로 지난 비용을 팀별로 쪼개려 할 때 | 비용 할당 태그를 관리 계정에서 켜고 리소스에 붙여 둬야 한다 |
| 사내 대시보드가 하루 몇 번 비용을 가져갈 때 | 몇 분마다 API 를 두드리는 감시 도구 | API 페이지 하나에 $0.01 |
넘기 전에 알림을 받고 싶다면 Cost Explorer 를 들여다보는 대신 Budgets 를 겁니다.
5. Budgets — 넘기 전에 알린다
Cost Explorer 는 이미 나간 돈을 보여 줍니다. 그럼 선을 넘기 전에는 누가 알려 줄까요? AWS Budgets 는 「이번 달 $500」 같은 비용의 선을 정해 두고, 실제 지출이 선을 넘거나 넘을 것으로 예측되면 알립니다. 금액 대신 어느 서비스의 사용량에 선을 그을 수도 있습니다. 알림은 이메일과 SNS 토픽으로 보냅니다. 그 SNS 토픽을 Amazon Q Developer in chat applications(옛 AWS Chatbot)에 이으면 슬랙으로도 받습니다. 예산을 만들고 알림을 받는 데에는 요금이 없습니다(Managing your costs with AWS Budgets · Receiving budget alerts in chat applications).
알아 둘 것은 알림이 늦다는 점입니다. 예산 정보는 하루 최대 세 번, 보통 앞 갱신에서 8~12시간 뒤에 바뀝니다. 리소스를 쓴 때와 그 사용이 요금으로 잡히는 때 사이에도 틈이 있어서, 알림이 오기 전에 이미 선을 넘을 수 있습니다. 그래서 실제 지출 알림만 걸지 말고 예측 알림을 같이 겁니다.
알림만으로 부족하면 예산 작업(budget action)을 붙입니다. 선을 넘을 때 IAM 정책을 붙여 새 리소스를 못 만들게 하거나, 관리 계정이라면 SCP 를 붙이거나, 지정한 EC2·RDS 인스턴스를 멈춥니다. 바로 실행할지 사람의 승인을 받고 실행할지 고릅니다. 인스턴스를 멈추는 작업은 예산을 만든 계정 안의 인스턴스에만 걸 수 있습니다(Configuring budget actions). 다만 알림이 늦게 오니 예산 작업도 늦게 돕니다. 정해 둔 금액에서 지출이 칼같이 멈추는 장치는 아닙니다.
요금은 예산 작업과 보고서에만 붙습니다(AWS Budgets Pricing).
Budgets · 리전 구분 없음 · 2026-11-13
예산 만들기·알림 무료
예산 작업이 붙은 예산 처음 2개 무료
3번째부터 예산 하나에 하루 $0.10
예산 보고서(메일로 받는 것) 보내는 한 번에 $0.01
계정을 만들면 월 예산 하나와 예측 알림부터 걸어 둡니다. 알림과 예산 작업 두 개까지는 요금이 붙지 않습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 월 예산을 정하고 80%·예측 초과에서 알림을 받을 때 | 몇 분 안에 폭주를 잡아야 할 때(→ CloudWatch 지표 알람) | 갱신이 하루 최대 세 번이라 알림이 몇 시간 늦을 수 있다 |
| 시험용 계정에서 선을 넘으면 새 리소스 생성을 막을 때 | 정한 금액에서 지출이 정확히 멈춰야 할 때 | 막는 동작도 늦은 알림을 따라 늦게 돈다 |
몇 시간 늦는 알림으로는 부족한 일, 예컨대 액세스 키가 새서 누가 인스턴스를 잔뜩 띄우는 경우는 Budgets 하나에 맡기지 않습니다. 인스턴스 수 같은 지표에 거는 CloudWatch 알람과, GuardDuty 같은 위협 탐지 서비스(09편)를 같이 둡니다.
6. Trusted Advisor — 낭비와 빈틈을 점검표로 본다
Budgets 가 「얼마 썼나」를 본다면, AWS Trusted Advisor 는 「잘 쓰고 있나」를 봅니다. 계정을 모범 사례 점검표에 대어 보고 어긋난 곳을 알려 줍니다. 점검은 비용 최적화, 성능, 복원력, 보안, 운영 우수성, 서비스 한도 여섯 갈래입니다. S3 버킷이 밖에 열려 있는지, 루트 사용자에 MFA(multi-factor authentication, 다중 인증)가 걸려 있는지, 한도에 다가간 리소스가 있는지 같은 것을 짚습니다(AWS Trusted Advisor).
무엇을 보여 주는지는 AWS 지원 플랜이 정합니다. 모든 계정이 받는 Basic 지원에서는 서비스 한도 점검 전부와 보안·복원력 점검 일부, 모두 56개를 콘솔에서 봅니다. 보안 점검은 자동으로 갱신되지 않아서 직접 새로 고침을 눌러야 합니다. 나머지 426개(모두 482개)와 매주 자동 갱신은 Business Support+ 이상에서 열립니다(AWS Trusted Advisor). Trusted Advisor API 와 EventBridge 로 결과를 받는 기능도 같은 플랜부터입니다.
조직의 모든 계정 결과를 모아 보는 조직 보기(organizational view)는 관리 계정에 Business Support+ 이상이 있어야 켜집니다. 다만 계정마다 보이는 점검은 그 계정의 플랜을 따릅니다. 멤버 계정이 Basic 이면 보고서에도 Basic 점검만 실리고, 그 계정에 사람이 직접 들어가 새로 고쳐야 합니다(Organizational view for AWS Trusted Advisor). Business Support+ 는 계정당 월 $29 부터 시작합니다(AWS Trusted Advisor 사용자 가이드 · Business Support+). 지원 플랜 자체도 바뀌는 중입니다. 기존 Developer 지원과 Business 지원은 2027-01-01 에 끝나고(GovCloud(US) 제외), 그 전에 Business Support+ 로 옮기라고 안내합니다(Developer, Business, and Enterprise On-Ramp end of support).
Trusted Advisor 의 값은 점검표가 아니라 지원 플랜에 붙어 있습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 처음 계정을 넘겨받아 한도·기초 보안 상태를 한 번 훑을 때(Basic) | Basic 에서 비용 절감 점검까지 받으려 할 때 | 비용 최적화 점검 대부분은 Business Support+ 이상이다 |
| 지원 플랜이 있어 점검 결과를 API·EventBridge 로 받아 자동 처리할 때 | 점검 하나 보려고 지원 플랜을 들 때 | 계정당 월 $29 부터 |
| 여러 계정의 점검 결과를 관리 계정에서 보고서로 모을 때(조직 보기) | 위협 탐지나 계속 도는 규정 검사가 필요할 때 | 멤버 계정 점검은 그 계정의 플랜만큼만 실리고, 점검은 상태 사진이지 실시간 감시가 아니다 |
계속 도는 감시가 필요하면 Config 규칙(06편)과 GuardDuty 같은 위협 탐지 서비스(09편)로 갑니다.
7. Service Quotas — 한도를 보고 올린다
서문에서 만난 「vCPU 한도를 넘었다」 오류로 돌아가 봅니다. 그 한도는 어디서 보고 어떻게 올릴까요? EC2 는 리전마다 온디맨드 인스턴스에 쓸 수 있는 vCPU 수에 상한을 두고, 이를 넘기는 실행 요청은 실패시킵니다(Amazon EC2 service quotas).
이런 할당량(quota, 예전에는 limit 이라 불렀습니다)은 AWS 의 거의 모든 리소스와 API 에 있습니다. 계정당 IAM 역할 수처럼 계정에 걸린 것도 있고, 리전당 VPC 수처럼 리전마다 따로 걸린 것도 있습니다. 대부분은 AWS 가 정한 기본값으로 시작하고, 일부는 늘려 달라고 요청할 수 있습니다. Service Quotas 는 이 값들을 한 콘솔에서 보고, 늘릴 수 있는 것은 그 화면에서 증가를 요청하는 서비스입니다. 요청은 지원팀이 검토해 승인하거나, 일부만 승인하거나, 거절합니다. 시간이 걸리므로 출시 직전이 아니라 미리 합니다(What is Service Quotas?). 모든 리전에 같이 걸리는 전역 할당량은 버지니아 북부(us-east-1)에서 요청합니다. Organizations 의 계정 수 한도(1절)도 이렇게 늘립니다. 서비스 자체는 추가 요금이 없습니다(Introducing Service Quotas).
한도에 닿기 전에 알아야 하니, 사용량을 지켜보는 방법이 둘 있습니다. 할당량마다 CloudWatch 알람을 거는 오래된 방법과, 2025-10-07 에 나온 자동 관리(Automatic Management)입니다. 자동 관리를 켜면 AWS 가 지원하는 할당량의 사용률을 지켜보다 80%·95% 에서 AWS Health 대시보드, 이메일, 슬랙, 콘솔 모바일 애플리케이션으로 알립니다. 2025-11-25 부터는 알림에 더해 증가 요청까지 대신 넣는 「알림과 자동 조정」 방식이 생겼습니다. 다만 자동 조정이 되는 할당량은 일부뿐입니다. 자동 요청은 수동 요청보다 기준이 빡빡할 수 있고, 거절 이유도 알려 주지 않습니다. 자동 관리에도 요금이 붙지 않습니다(Service Quotas Automatic Management · 자동 조정 발표).
조직이 있으면 할당량 요청 템플릿도 씁니다. 늘릴 할당량을 열 개까지 적어 두면 조직에서 새 계정을 만들 때마다 그 증가 요청이 자동으로 들어갑니다. 이미 있는 계정에는 적용되지 않고, 조직이 모든 기능을 켜 둬야 합니다(Using Service Quotas request templates).
요청 템플릿과 자동 조정은 둘 다 사람이 잊기 전에 증가 요청을 넣어 두는 장치입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 출시·행사 전에 vCPU·탄력적 IP 같은 한도를 미리 올려 둘 때 | 한도에 걸린 그 순간 바로 풀어야 할 때 | 요청은 검토를 거치고, 거절되거나 일부만 승인될 수 있다 |
| 한도에 다가가는 것을 미리 알림으로 받을 때(자동 관리) | 모든 할당량을 자동으로 늘려 주길 바랄 때 | 자동 조정은 지원하는 할당량에만 되고 거절 이유를 안 준다 |
| 조직에서 새 계정을 자주 만들고 같은 한도가 필요할 때(요청 템플릿) | 이미 있는 계정의 한도를 한꺼번에 바꿀 때 | 템플릿은 새 계정에만 적용되고 할당량 열 개까지다 |
증가가 거절되거나 늘린 한도로도 모자라면 워크로드를 다른 리전이나 계정으로 나눕니다. 리전에 걸린 할당량은 리전마다, 계정에 걸린 할당량은 계정마다 따로 세기 때문입니다.
8. 계정 몇 개를 묶은 작은 팀은 한 달 얼마를 내나
개발과 운영 계정 둘을 Organizations 로 묶고, Control Tower 로 랜딩 존을 세운 작은 팀을 생각해 봅니다. 한 리전만 쓰고, 업무 계정마다 리소스가 50개쯤이며 리소스 하나가 한 달에 열 번 바뀐다고 둡니다. 비용 대시보드는 하루 다섯 번 Cost Explorer API 를 부르고, 예산 작업이 붙은 예산을 셋 둡니다. Config 의 구성 항목 값 $0.003 은 06편에서 본 서울 값입니다.
셈에는 업무 계정 둘의 Config 구성 항목만 넣었습니다. Control Tower 가 만드는 Log Archive·Audit 계정의 기록, 탐지 컨트롤이 쓰는 Config 규칙 평가, 로그를 보관하는 S3 요금은 뺐습니다. 규칙 평가가 얼마나 붙는지는 AWS 요금 페이지의 예시 2가 보여 줍니다. 버지니아 북부에서 멤버 10계정에 리소스 다섯씩 두고 탐지 컨트롤 다섯을 켜면, 한 달 구성 항목 $1.50 에 규칙 평가 1,250회 $1.25 가 더 붙습니다(AWS Control Tower pricing).
작은 팀 · 서울 · 2026-11-13 · 한 달 30일
Organizations · Control Tower · RAM $0.00
IAM Identity Center · Service Quotas $0.00
Budgets 알림 $0.00
Trusted Advisor (Basic) $0.00
Config 구성 항목 (Control Tower 가 켬)
2계정 × 50개 × 10번 = 1,000개
1,000 × $0.003 = $3.00
※ 규칙 평가·공유 계정 기록·로그 S3 는 셈에서 뺐다
Budgets 예산 작업 3개 (2개 무료)
1개 × $0.10 × 30일 = $3.00
Cost Explorer API
하루 5번 × 30일 = 150 요청
150 × $0.01 = $1.50
합계 (업무 계정 Config 구성 항목까지) $7.50
계정을 묶고 지켜보는 도구들 자체는 거의 공짜이고, 돈은 Control Tower 가 켜 두는 Config 기록에서 납니다. 같은 Config 가 리소스가 하루에도 수없이 생겼다 사라지는 계정에서는 2절의 AWS 예시처럼 계정·리전당 한 달 $372 까지 갑니다. 이 셈에서 가장 크게 움직이는 값은 계정 수가 아니라 리소스가 바뀌는 횟수입니다. Trusted Advisor 점검을 다 받으려면 지원 플랜 요금이 계정당 월 $29 부터 따로 붙습니다.
이럴 땐 무엇
| 상황 | 서비스 | 이유 |
|---|---|---|
| 개발·운영을 계정으로 나누고 청구서는 한 장으로 | Organizations | 통합 결제, 추가 요금 없음 |
| 개발 계정에서 허락한 리전 밖을 아무도 못 쓰게 | Organizations SCP | 계정 관리자·루트도 넘지 못하는 상한. 관리 계정에는 안 걸린다 |
| 새 계정마다 로그 수집·로그인·금지 규칙이 같은 모양으로 붙게 | Control Tower | 랜딩 존과 컨트롤, Account Factory. 돈은 Config 기록에서 난다 |
| 네트워크 계정의 VPC 서브넷을 여러 팀 계정이 같이 쓴다 | RAM | 조직 안에서 초대 없이 공유, NAT 요금은 VPC 주인이 낸다 |
| 지난달 비용이 왜 늘었는지 팀별로 쪼개 본다 | Cost Explorer + 비용 할당 태그 | 콘솔은 무료, 태그는 관리 계정에서 켠다 |
| 월 예산을 넘을 것 같으면 미리 알림 | Budgets | 예측 알림까지 무료. 알림은 몇 시간 늦을 수 있다 |
| 시험 계정이 예산을 넘으면 새 리소스 생성을 막는다 | Budgets 예산 작업 | IAM 정책·SCP 를 붙인다. 두 개까지 무료 |
| 계정을 넘겨받아 한도와 기초 보안을 한 번 훑는다 | Trusted Advisor(Basic) | 무료 점검 56개 |
| 출시 전에 vCPU 한도를 올려 둔다 | Service Quotas | 검토 시간이 있으니 미리. 자동 관리로 80%·95% 알림 |
자주 붙는 서비스는 IAM Identity Center(계정마다 로그인, 05-1편), CloudTrail·Config(조직 단위 기록, 06편), SNS(예산 알림), CloudWatch(한도·지출 알람), CloudFormation StackSets(여러 계정에 같은 리소스 배포), GuardDuty 같은 위협 탐지 서비스(09편)입니다. 엮이는 방식은 조합 편(28 여러 계정 운영)에서 봅니다.
한 장 요약
계정을 나누면 Organizations 로 묶어 청구서를 합치고 SCP 로 상한을 겁니다. 관리 계정에는 SCP 가 안 걸리니 워크로드를 두지 않습니다. 돈은 Cost Explorer 로 지난 것을 쪼개 보고 Budgets 로 미리 알림을 받되, 알림은 몇 시간 늦습니다. 이 도구들 자체는 거의 무료이고, 작은 팀이라면 도구 자체와 업무 계정의 Config 구성 항목만 쳐서 한 달 $7.50 이고, 규칙 평가와 로그 보관 요금은 따로 붙습니다.
관련 항목
계정과 돈을 다루는 같은 갈래
AWS Organizations · AWS Control Tower · AWS Resource Access Manager · AWS Cost Explorer · AWS Budgets · AWS Trusted Advisor · Service Quotas · AWS Billing and Cost Management
조직을 이루는 단위
관리 계정 · 멤버 계정 · 조직 단위 · 통합 결제 · 모든 기능 모드 · 멀티 계정 전략
계정 전체에 거는 상한과 규칙
서비스 제어 정책 · 리소스 제어 정책 · 권한 경계 · IAM 정책 · 서비스 연결 역할 · 루트 사용자 · 최소 권한
Control Tower 가 세우고 지키는 것
랜딩 존 · 가드레일 · Account Factory · AWS Config · Config 규칙 · CloudFormation 훅 · CloudFormation StackSets · AWS IAM Identity Center
계정 사이에 리소스를 나누는 방식
리소스 공유 · VPC 공유 · 서브넷 · AWS Transit Gateway · 자원 기반 정책 · NAT 게이트웨이 · AWS Private CA
비용을 쪼개 보고 미리 막는 장치
비용 할당 태그 · 태그 · 예산 작업 · 비용 예측 · 예약 인스턴스 · Savings Plans · AWS 프리 티어 · AWS Cost and Usage Report
한도와 점검
서비스 할당량 · 할당량 요청 템플릿 · AWS Health · CloudWatch · AWS Support 플랜 · Amazon EventBridge
이 편과 맞물리는 앞 편
AWS 05-1 누가 무엇을 할 수 있나 — IAM·IAM Identity Center·Cognito·Verified Permissions · AWS 06 관측·운영 — CloudWatch·CloudTrail·Systems Manager·AppConfig·X-Ray·Config·Health · AWS 04-1 내 망 안쪽 — VPC·NAT Gateway·PrivateLink·Transit Gateway·Network Firewall·VPC Lattice·Cloud Map