지원 플랜은 통신사 요금제와 같은 구조다. 위 등급일수록 응답이 빠르고 도움이 깊어지며, 값도 올라간다.
네 단계 서열: Basic(무료) → Developer → Business → Enterprise. 문항의 단서 강도를 따라 올라가면 답이 나온다.
TAM은 사람(전담 기술 자문, Enterprise 전용), Trusted Advisor는 도구(자동 점검). 이 둘을 섞지 않아야 한다.
Trusted Advisor의 전체 다섯 범주 점검은 Business 이상에서 열린다. 하위 플랜은 일부만 제공된다.
시험의 정답은 "가장 좋은 플랜"이 아니라 "요구사항을 딱 채우는 가장 낮은 플랜"이다.
비용을 잘 보고 잘 막아도, 막상 서비스가 멈추거나 설계가 막히면 누군가의 도움이 필요하다. AWS는 고객마다 필요한 도움의 수준이 다르다는 걸 알고, 여러 단계의 지원 플랜(Support Plan)을 제공한다. 오늘은 Basic부터 Enterprise까지 네 단계의 차이, 전담 지원 인력 TAM, 그리고 누구나 쓸 수 있는 자동 점검 도구 Trusted Advisor를 정리한다.
핵심 질문은 하나다: "이 조직은 얼마나 빠른 응답과 얼마나 깊은 도움이 필요한가?" 그 답이 적절한 플랜을 정한다.
처음 배우는 사람이 가장 어색해하는 지점이 여기다. "돈 내고 서비스를 쓰는데, 도와주는 것도 또 돈을 내야 해?"
이 질문에 답하려면 클라우드 이전으로 가 보면 된다. 회사가 서버를 직접 사서 쓰던 시절, 장비값과 별도로 반드시 따라붙던 계약이 있었다. 유지보수 계약이다. 장비가 고장 나면 언제까지 사람이 오는지, 야간·주말에도 오는지, 부품을 얼마나 빨리 갈아주는지에 따라 계약 금액이 달랐다. "평일 낮에만 방문"과 "24시간 상주"의 값이 같을 수는 없었다.
클라우드도 똑같은 구조를 물려받았다. 다만 대상이 바뀌었을 뿐이다.
온프레미스 시절
클라우드
장비값
사용한 자원의 요금
유지보수 계약
지원 플랜
"몇 시간 안에 기사님이 오나"
"몇 시간 안에 답변이 오나"
그리고 클라우드에는 이유가 하나 더 있다. 클라우드의 기본 전제는 셀프서비스다. 콘솔에서 직접 만들고, 직접 설정하고, 직접 고치는 게 원칙이다. 문서와 온라인 자료는 누구에게나 무료로 열려 있다. 그런데 현실에서는 스스로 해결할 수 없는 순간이 온다.
새벽에 서비스가 멈췄는데 원인이 우리 코드인지 AWS 쪽인지 판단이 안 될 때
설계를 시작하기 전에 "이 방향이 맞는지" 경험자에게 확인받고 싶을 때
대규모 행사를 앞두고 우리 구성이 트래픽을 견딜지 미리 점검받고 싶을 때
지원 플랜은 이런 순간에 AWS 쪽 사람을 얼마나 빨리, 얼마나 깊이 부를 수 있는가를 사는 것이다. 모든 회사가 그 정도의 도움이 필요하지는 않기 때문에, 하나로 묶어 팔지 않고 단계로 나눠 놓은 것이다.
지원 플랜은 AWS 계정 단위로 가입한다. 서비스별로 따로 사는 게 아니라 그 계정 전체에 적용된다. 그래서 계정이 여러 개인 조직에서는 "어느 계정에 어떤 플랜을 붙일지"가 실제 의사결정 항목이 된다. 개발용 계정은 낮은 등급, 운영 계정은 높은 등급으로 가져가는 식이다.
Basic: 모든 계정에 무료로 제공. 기술 지원 케이스는 안 되고, 계정·청구 문의와 문서·포럼·일부 Trusted Advisor 점검만 가능.
Developer: 저렴한 유료 플랜. 이메일로 기술 문의 가능(업무 시간 기준). 개발·테스트 단계에 적합.
Business: 연중무휴 24/7 기술 지원(전화·채팅·이메일), 전체 Trusted Advisor 점검 제공. 운영 중인 프로덕션 워크로드에 적합.
Enterprise: 최고 수준. 24/7 지원에 더해 가장 빠른 응답(긴급 시 15분 목표), 전담 인력 TAM, 컨시어지 청구 지원 등을 제공. 대규모·미션 크리티컬 환경용.
플랜
비용
기술 지원
대표 특징
Basic
무료
없음(케이스 불가)
문서·포럼·청구 문의, 제한된 Trusted Advisor
Developer
유료(저)
이메일(업무 시간)
개발/테스트 단계
Business
유료(중)
24/7 전화·채팅·이메일
전체 Trusted Advisor, 프로덕션용
Enterprise
유료(고)
24/7 + 최단 응답
TAM, 컨시어지, 미션 크리티컬
비유하자면 통신사 요금제, 혹은 놀이공원 이용권 등급이다. 같은 놀이공원에 들어가도 일반 입장권과 우선 탑승권의 대기 시간이 다르듯, 같은 AWS를 쓰더라도 지원 플랜에 따라 줄 서는 위치가 달라진다. 서비스 자체의 성능이나 기능이 달라지는 게 아니라는 점이 중요하다.
네 등급이 실제로 무엇을 가르는지는 세 가지 축으로 보면 깔끔하다.
축
아래 등급
위 등급
누구에게 물어보나
문서·온라인 자료만
문서 + AWS 엔지니어에게 케이스 접수
어떻게·언제 물어보나
이메일, 업무 시간
전화·채팅까지, 연중무휴
얼마나 깊이 도와주나
질문에 답변
우리 환경을 아는 전담 인력이 먼저 제안
이 표를 왼쪽에서 오른쪽으로 걸어가면 그대로 Basic → Developer → Business → Enterprise가 된다. 외울 게 네 개가 아니라 하나의 방향이라고 생각하면 훨씬 쉽다.
각 등급이 실제로 어떤 회사에 어울리는지도 그려 둔다.
Basic — 이제 막 계정을 만들어 혼자 공부하는 사람, 개인 실습, 아직 아무것도 서비스하지 않는 단계.
Developer — 아직 고객이 없는 개발·테스트 환경. 막히면 이메일로 물어보고 다음 날 답을 받아도 괜찮은 상황.
Business — 실제 고객이 쓰는 서비스를 운영하는 단계. 새벽에 장애가 나면 그때 바로 사람을 불러야 하므로 연중무휴 지원이 필수가 된다.
Enterprise — 멈추면 회사의 매출·신뢰가 즉시 흔들리는 미션 크리티컬 환경. 사고가 난 뒤의 대응뿐 아니라 사고가 나지 않도록 미리 함께 준비하는 것까지를 산다.
같은 회사 안에서도 플랜이 갈리는 게 자연스럽다. 어느 이커머스 기업이 계정을 세 개로 나눠 쓴다고 해본다. 개발자들이 자유롭게 실험하는 개발 계정, 출시 전 검증하는 스테이징 계정, 실제 주문이 들어오는 운영 계정. 개발 계정이 잠깐 멈춰도 손해는 개발자 몇 명의 시간이지만, 운영 계정이 멈추면 그 시간 동안 주문이 들어오지 않는다. 그래서 이 회사는 개발 계정은 낮은 등급으로 두고 운영 계정만 상위 플랜으로 올렸다. 지원 플랜을 고르는 실제 기준은 "회사의 크기"가 아니라 "이 계정이 멈추면 무엇을 잃는가"다.
⚠️ 함정: 시험에서 요구사항을 모두 만족하는 플랜이 여러 개일 때, 정답은 가장 좋은 플랜이 아니라 가장 낮은(= 가장 저렴한) 플랜이다. "24/7 지원과 전체 Trusted Advisor가 필요하다"까지만 적혀 있으면 Business가 답이고, 여기서 Enterprise를 고르면 요구사항을 넘어선 과잉 지출이라 오답 처리된다. 반대로 "전담 기술 자문", "미션 크리티컬"이라는 단어가 나오면 그때는 Enterprise다. 문항이 요구한 것보다 한 칸 위를 고르지 않는 것이 이 유형의 핵심 기술이다.
"무료 기본 지원"=Basic, "이메일 기술 지원·개발 단계"=Developer, "24/7 지원·전체 Trusted Advisor·프로덕션"=Business, "TAM·가장 빠른 응답·미션 크리티컬"=Enterprise. 단서의 강도 순서대로 올라간다고 기억하면 쉽다.
TAM(Technical Account Manager)은 Enterprise Support에서 제공되는 전담 기술 자문 인력이다. 고객의 환경을 지속적으로 파악하고, 아키텍처 검토·운영 모범 사례·비용 최적화·중요한 출시 대비 등을 옆에서 도와준다. 케이스가 생길 때만 응대하는 일반 지원과 달리, 고객을 꾸준히 따라붙는 사람이라는 점이 핵심이다.
비유하자면 응급실과 주치의의 차이다. 일반 지원은 응급실에 가깝다. 아플 때 가면 진료해 주지만, 내가 평소 무엇을 먹는지, 작년에 무슨 수술을 했는지는 모른다. 매번 처음부터 설명해야 한다. TAM은 주치의에 가깝다. 우리 환경을 이미 알고 있는 사람이라 설명이 짧고, 무엇보다 아프기 전에 먼저 이야기를 꺼낸다 — "다음 달에 그 행사 있다고 하셨죠, 그 구성으로 견딜지 미리 보시죠" 같은 식이다.
이 차이를 표로 두면 헷갈리지 않는다.
일반 기술 지원
TAM
언제 만나나
케이스를 열었을 때만
평소에 계속
우리 환경을 아나
매번 설명해야 함
이미 알고 있음
방향
우리가 물으면 답한다
먼저 제안하기도 한다
어느 플랜
유료 플랜 전반
Enterprise 전용
정리하면 TAM이 파는 것은 속도가 아니라 맥락이다. 빠른 응답은 상위 플랜이면 따라오지만, "우리 회사 사정을 아는 사람"은 전담 인력이 아니면 만들어지지 않는다.
"전담 기술 자문", "지속적으로 우리 환경을 봐주는 담당자"가 보이면 TAM이고, 이는 Enterprise 플랜 전용이다. Business 이하에는 TAM이 없다.
AWS Trusted Advisor는 고객의 환경을 자동으로 점검해 모범 사례 대비 개선점을 알려주는 서비스다. 점검은 다섯 범주로 나뉜다.
비용 최적화 — 안 쓰는 리소스, 저활용 인스턴스 등
성능 — 처리량·구성 개선점
보안 — 열린 보안 그룹, MFA 미설정, 노출된 액세스 키 등
내결함성(Fault Tolerance) — 백업·다중화 부족
서비스 한도(Service Quotas) — 한도 임박 경고
중요한 건 플랜에 따라 점검 범위가 다르다는 점이다. Basic/Developer는 핵심 보안·서비스 한도 점검만 제공되고, 전체 5범주 점검은 Business·Enterprise에서 열린다.
비유하자면 자동차 정기 점검이나 건강검진이다. 아무 증상이 없어도 정비소에 가면 "브레이크 패드가 얼마 안 남았다", "타이어 공기압이 낮다"고 알려준다. 고장이 난 뒤가 아니라 고장 나기 전에 알려주는 게 핵심이다. Trusted Advisor가 클라우드 환경에 대해 하는 일이 정확히 그것이다. 사람이 매일 계정을 뒤지며 "혹시 열려 있는 포트 없나, 안 쓰는 서버 없나" 확인할 수는 없으니, 도구가 대신 훑고 목록을 내밀어 준다.
다섯 범주가 각각 어떤 잔소리를 하는지 감을 잡아 두면 외우기 쉽다.
범주
이런 걸 짚어준다
한 줄 요약
비용 최적화
붙어 있지 않은 저장 볼륨, 거의 안 쓰는 인스턴스
"돈이 새고 있어요"
성능
사양이 부족하거나 구성이 비효율적인 지점
"느려질 수 있어요"
보안
지나치게 열린 방화벽 규칙, MFA 미설정
"위험해요"
내결함성
백업 없음, 한 곳에만 몰린 구성
"하나 죽으면 다 죽어요"
서비스 한도
계정에 걸린 한도에 근접한 항목
"곧 더 못 만들어요"
시험에서 묻는 것은 "이 다섯 가지를 다 받으려면 어느 플랜이어야 하는가"다. 답은 Business 이상이다. 무료 플랜에서도 Trusted Advisor 자체는 만날 수 있지만 보여주는 범위가 제한된다는 점만 기억하면 된다.
"환경을 자동 점검해 보안·비용·성능 개선 권고"가 보이면 Trusted Advisor다. "전체 점검을 받으려면" 어떤 플랜? → Business 이상. 누가 점검하느냐(사람 TAM)와 무엇이 점검하느냐(도구 Trusted Advisor)를 헷갈리지 않아야 한다.
⚠️ 함정: "Trusted Advisor는 유료 플랜에서만 쓸 수 있다"는 보기는 틀렸다. 무료 Basic에서도 일부 점검은 제공된다. 정확한 표현은 "전체 점검은 Business 이상에서 열린다"이다. 이런 문항은 제공 여부와 제공 범위를 바꿔치기해서 오답을 만드니, 보기의 서술이 "쓸 수 없다"인지 "일부만 된다"인지를 꼼꼼히 읽는다.
한 줄로 정리하면 이렇다. 케이스는 우리가 부르는 것, TAM은 곁에 있는 사람, Trusted Advisor는 알아서 도는 점검기.
필요한 응답 속도와 도움의 깊이가 곧 플랜의 등급이다. 무료 Basic으로 시작해, 개발 단계면 Developer, 프로덕션을 24/7로 지키려면 Business, 전담 인력(TAM)과 최단 응답이 필요한 미션 크리티컬이면 Enterprise로 올라간다. 지원 플랜은 보험에 가깝다. 아무 일도 안 일어나면 아깝게 느껴지지만, 새벽에 서비스가 멈춘 그 한 번에 값을 한다. 그래서 "지금 우리에게 필요한가"가 아니라 "멈췄을 때 우리가 무엇을 잃는가"로 판단한다.