AWS를 떠나는 이유
핵심 요약
이 글은 초기 AWS 지지자가 오랜 시간 누적된 불만 끝에 AWS를 떠났고, 잠시 다시 돌아왔다가 왜 떠났는지 다시 확인했다는 경험담이다.
핵심 문제는 단일 서비스의 결함이 아니라 플랫폼 전체의 운영 리스크다.
- 과금 구조가 복잡하고 예측하기 어렵다.
- 데이터 전송과 내부 이동 비용이 비싸다.
- IAM, Lambda, DynamoDB 등 주요 서비스의 복잡성이 높다.
- 벤더 락인이 실제 마이그레이션 비용으로 돌아온다.
- 계정 제한이 걸리면 관련 서비스가 한꺼번에 중단될 수 있다.
- 무료 지원 플랜에서는 복구 지연이 비즈니스 리스크가 된다.
초기 AWS의 매력
초기 AWS는 SQS, S3, EC2, SimpleDB 정도의 상대적으로 단순한 플랫폼이었다. 클라우드의 매력은 명확했다.
- 스타트업이 데이터센터를 직접 운영하지 않아도 됐다.
- 서버 구매, 랙 설치, 네트워크 구성 없이 몇 분 만에 컴퓨팅을 확보할 수 있었다.
- 초기 자본 지출을 운영 비용으로 전환할 수 있었다.
- 작은 팀도 대규모 인프라 실험을 할 수 있었다.
이 시기의 AWS는 복잡한 엔터프라이즈 플랫폼이라기보다, 개발자와 스타트업에게 컴퓨팅 자유도를 주는 도구에 가까웠다.
누적된 불만
클라이언트 라이브러리와 생태계 책임
초기 AWS는 자체 클라이언트 라이브러리를 충분히 제공하지 않았고, 여러 언어의 SDK와 도구를 커뮤니티가 메우는 기간이 길었다. 글쓴이는 이를 AWS가 무료 노동에 의존한 것으로 받아들인다.
Python 2에서 Python 3로 넘어가는 과정도 느렸고, 이 역시 플랫폼 신뢰를 깎은 요소로 언급된다.
DynamoDB 비용 경험
DynamoDB는 확장성과 관리형이라는 장점이 있지만, 사용량과 과금 모델을 정확히 이해하지 못하면 예상보다 큰 비용이 빠르게 발생할 수 있다.
글쓴이는 첫날 75달러 청구를 경험했고, 비용뿐 아니라 사용 경험 자체도 나쁘게 평가했다.
데이터 전송 비용
AWS의 이그레스 비용은 과거 GB당 20센트, 이후 GB당 9센트 수준까지 내려왔지만 여전히 비싸다고 본다.
특히 문제는 단순 인터넷 송신뿐 아니라 AWS 내부 데이터 이동에도 비용이 붙는 경우가 있다는 점이다. 리전, AZ, 서비스 경계에 따라 과금이 달라지고, 이를 깊이 이해하지 못하면 이중·삼중 과금처럼 느껴질 수 있다.
IAM과 플랫폼 복잡성
AWS 지지자들은 자체 Linux, 네트워크, 하드웨어, 보안을 운영하는 것이 복잡하므로 AWS를 써야 한다고 말한다. 하지만 글쓴이의 관점에서는 AWS 자체도 너무 복잡해졌다.
IAM은 대표적인 예다. 안전하게 쓰려면 정책, 역할, 권한 경계, 서비스별 조건, 조직 단위 제어를 이해해야 한다. 결국 AWS를 제대로 쓰려면 AWS 전문가 팀이 필요해지고, 이는 “복잡성을 외주화했다”기보다 “다른 복잡성으로 바꿨다”에 가깝다.
Lambda와 락인
Lambda는 확장성과 운영 부담 감소가 매력적이지만, 글쓴이는 다음 문제를 지적한다.
- 콜드 스타트.
- 로컬 개발과 디버깅 복잡성.
- AWS 서비스와 결합된 아키텍처.
- 이탈 시 해체가 어려운 벤더 락인.
자체 웹 서버보다 장점이 크지 않은 상황에서도 Lambda를 쓰면, 나중에 AWS를 떠날 때 가장 제거하기 어려운 부분이 될 수 있다.
오픈소스와 AWS
글쓴이는 AWS가 Elasticsearch, Redis, MongoDB 같은 오픈소스 프로젝트의 시장을 활용해 호스팅 수익을 가져갔다고 비판한다.
이 흐름은 OpenSearch, Valkey, DocumentDB 같은 사례로 이어졌고, 오픈소스 기업들이 SSPL, Elastic License, RSAL 같은 방어적 라이선스를 채택하는 배경이 되었다고 본다.
핵심 쟁점은 클라우드 사업자가 오픈소스 생태계의 가치를 어디까지 수익화할 수 있는가다.
AWS로 잠시 돌아간 이유
글쓴이는 대부분의 서비스를 AWS 밖으로 옮겼지만, 일부는 남겨두었다.
- Route53: 도메인.
- S3: 일부 백업.
- AWS WorkMail: 비즈니스 이메일.
최근 AWS로 다시 로그인한 이유는 두 가지였다.
- Bedrock에서 Claude/Anthropic 모델을 테스트하기 위해.
- 192코어, 1TB RAM급 EC2 인스턴스에서 벤치마크하기 위해.
Bedrock은 동작 자체는 Claude와 비슷했지만 더 느리고, Anthropic 구독보다 비싸게 느껴졌다고 한다. 프라이버시가 중요할 때는 유용할 수 있지만 비용 때문에 계속 쓰지는 않을 것이라는 결론이다.
계정 제한 사건
문제는 192코어 EC2 Spot 인스턴스를 약 3시간 테스트하던 중 발생했다. 거의 휴면 상태였던 계정이 갑자기 비싼 컴퓨팅을 사용하자 AWS가 보안 침해 의심 알림을 보냈고, 계정이 제한되었다.
보안 경보 자체는 합리적일 수 있다. 휴면 계정에서 갑작스러운 고비용 컴퓨팅 사용은 실제 침해 시나리오와 비슷하기 때문이다.
하지만 문제는 제한의 범위였다.
- EC2 테스트를 계속할 수 없었다.
- 새 AWS 리소스를 만들 수 없었다.
- AWS WorkMail로 운영하던 사업용 이메일까지 중단되었다.
AWS 계정 하나에 비즈니스 이메일까지 묶어둔 것이 단일 장애점이 된 셈이다.
지원 플랜 리스크
글쓴이는 무료 지원 플랜 상태였다. AWS의 보안 알림에 답장하고, 비밀번호 변경, 액세스 토큰 삭제, 청구 확인 등 요청받은 조치를 수행했지만, 4일이 지나도 제한이 해제되지 않았다.
이 경험은 중요한 운영 교훈을 준다.
- 클라우드 계정 제한은 기술 장애가 아니라 행정 장애가 될 수 있다.
- 무료 지원 플랜에서는 복구 시간이 예측 불가능하다.
- 비즈니스 핵심 서비스가 같은 계정에 묶여 있으면 피해가 커진다.
- 계정 신뢰성은 인프라 신뢰성의 일부다.
시사점
AWS의 문제는 “기능이 부족하다”가 아니다. 오히려 기능이 너무 많고 강력하다. 문제는 그 강력함에 따르는 복잡성, 비용, 락인, 계정 리스크다.
AWS를 계속 쓴다면 다음 원칙이 필요하다.
- 비용 알림과 예산 한도를 반드시 설정한다.
- 이그레스와 AZ 간 데이터 이동 비용을 설계 단계에서 계산한다.
- Lambda, DynamoDB, Step Functions 같은 고락인 서비스는 의도적으로 선택한다.
- 비즈니스 이메일, 도메인, 백업을 하나의 AWS 계정에 모두 묶지 않는다.
- 중요 계정은 유료 지원 플랜 또는 대체 복구 경로를 확보한다.
- 휴면 계정에서 갑자기 대형 인스턴스를 띄우는 작업은 사전에 quota와 보안 알림 가능성을 고려한다.
결론
AWS는 여전히 강력한 플랫폼이지만, “인프라를 단순하게 만들어주는 도구”라기보다 “거대한 분산 운영체제”에 가깝다. 이 운영체제를 제대로 다루려면 비용 모델, IAM, 계정 보안, 지원 체계, 락인 비용까지 모두 관리해야 한다.
글쓴이의 결론은 명확하다. 이미 AWS를 떠났던 것은 좋은 결정이었고, 남겨둔 WorkMail과 Route53까지 옮겨 완전히 떠나는 것이 맞다는 것이다.