AWS로 돌아갔고, 내가 왜 떠났는지 다시 깨달았다

• 초기부터 AWS를 지지했지만, 클라이언트 라이브러리를 커뮤니티에 맡긴 기간, Python 3 전환 지연, 복잡한 과금과 IAM, AWS Lambda 락인 등이 쌓이며 더 이상 AWS를 좋아하지 않게 됨
• DynamoDB 사용 뒤 하루 75달러 청구를 겪었고, 데이터 송신 비용은 GB당 20센트에서 9센트로 내려갔지만 내부 데이터 이동까지 과금되는 구조가 여전히 비싸고 이해하기 어렵다고 봄
• AWS를 떠난 뒤 대부분의 계정을 닫았지만 Route53 도메인, S3 백업 일부, AWS WorkMail은 남겼고, WorkMail은 이후 12개월 안에 종료된다는 통지를 받음
• 최근 Claude/Anthropic의 AWS Bedrock 동작과 192코어·1TB RAM EC2 Spot 테스트를 위해 AWS에 다시 로그인했으며, Bedrock은 동작은 같지만 더 느리고 Anthropic 구독보다 훨씬 비싸다고 판단함
• 약 3시간 EC2 Spot 테스트 중 Suspected security breach 알림 뒤 계정이 제한되어 사업용 WorkMail 이메일과 리소스 생성이 막혔고, 조치와 채팅 지원 뒤에도 4일간 제한이 풀리지 않아 AWS WorkMail과 Route53까지 옮기기로 함

초기 AWS 지지에서 이탈까지

• AWS가 SQS, S3, EC2, SimpleDB 중심의 더 작은 서비스였던 시절부터 강하게 지지했고, Melbourne에서 미국 AWS 담당자가 와서 AWS를 알리던 첫 행사를 조직함
• 클라우드 컴퓨팅은 스타트업이 데이터센터에 시스템을 설치·운영하지 않고도 몇 분 만에 자체 컴퓨터 시스템을 돌릴 수 있게 만든 큰 변화였음
• 약 15년 동안 AWS를 강하게 믿었지만, 시간이 지나며 불편한 요소가 쌓였고 어느 순간 더 이상 AWS를 좋아하지 않게 됨

시간이 지나며 쌓인 AWS에 대한 불만

• 클라이언트 라이브러리와 Python 전환

  • AWS는 초기 6년 동안 자체 클라이언트 라이브러리를 만들지 않고 Python 같은 언어용 라이브러리를 커뮤니티가 구현하도록 두었고, 무료로 시간을 쓰는 프로그래머들에게 부담을 넘긴 셈으로 받아들여짐
  • AWS가 Python 2에서 Python 3로 옮겨가는 데 지나치게 오래 걸린 것도 큰 불만으로 남음

• DynamoDB와 비용 경험

  • DynamoDB를 사용한 뒤 하루가 끝날 때 75달러 청구가 발생했고, 비용뿐 아니라 시스템 자체도 상상할 수 있는 최악의 방식으로 느껴짐

• 데이터 전송 비용과 복잡한 과금

  • AWS의 데이터 송신 비용은 과거 GB당 20센트였고 이후 GB당 9센트까지 내려갔지만, 여전히 매우 비싸다고 봄
  • AWS 내부 시스템 간 데이터 이동에도 과금이 붙고, 경우에 따라 이중·삼중 과금처럼 느껴지는 구조가 있어 깊이 이해하지 않으면 과금 함정을 피하기 어려움

• IAM과 전반적 복잡성

  • IAM은 인증과 접근 규칙을 다루는 시스템이지만, 지나치게 복잡한 구조로 받아들여짐
  • AWS 지지자들은 자체 Linux, 하드웨어, 네트워킹, 보안을 운영하는 것이 너무 복잡하므로 AWS를 써야 한다고 말하지만, AWS 자체의 거의 모든 영역도 거대한 복잡성을 갖고 있어 결국 비싼 전문가 팀이 필요하다고 봄

• AWS Lambda와 락인

  • AWS Lambda는 확장성을 내세우지만, 느린 시작 시간과 큰 개발 복잡성을 감수해야 했음
  • 자체 웹 서버를 운영하는 것과 비교해 진짜 이점은 없고 단점은 많다고 봤으며, AWS를 떠날 때 가장 되돌리기 어려웠던 부분이 AWS Lambda였음
  • AWS Lambda 사용은 벤더 락인이 실제로 존재한다는 경험으로 남았고, 계속 더 낫다고 스스로 설득해야 하는 선택처럼 느껴짐

• 오픈소스 프로젝트와 호스팅 수익

  • AWS는 Elasticsearch, Redis, MongoDB 같은 프로젝트가 복제·수익화를 원하지 않는 의사를 보였음에도 OpenSearch, Valkey, DocumentDB를 추진했다고 봄
  • 해당 커뮤니티와 회사들이 시장을 만든 뒤 AWS가 호스팅 서비스 수익을 가져갔고, 그 결과 SSPL, Elastic License, RSAL 같은 방어적 라이선스와 source-available 모델이 늘어났다고 봄

AWS를 떠난 뒤 남겨둔 일부 서비스

• AWS에 대한 애정이 끊긴 뒤 모든 것을 AWS 밖으로 옮기고 계정을 거의 모두 닫음
• 다만 당시에는 실제로 맞는 해결책이라고 본 일부 서비스만 남겨둠
• 남겨둔 항목은 Route53의 도메인, S3의 일부 백업, AWS WorkMail이었음
• AWS WorkMail은 이후 12개월 안에 종료된다는 통지를 받음

AWS로 잠시 돌아간 이유

• 최근 연구와 테스트를 위해 AWS에 다시 로그인함
• Claude/Anthropic이 AWS Bedrock에서 얼마나 잘 동작하는지 확인하려 했고, Claude Code 기준으로는 동작은 같지만 더 느리고 Anthropic 구독보다 훨씬 비싸다고 봄
• 보유한 가장 빠른 집 장비는 20코어 CPU와 32GB RAM이었고, 코드가 192코어와 1TB RAM 장비에서 얼마나 빨리 실행되는지 벤치마크하려 했음
• 약 한 달 전 AWS Bedrock 테스트는 문제없이 끝났고, 테스트 후 모두 종료함
• AWS Bedrock은 프라이버시가 필요하면 유용할 수 있지만 비용 때문에 다시 Claude를 AWS Bedrock에서 쓰지는 않겠다고 봄

EC2 Spot 테스트 중 발생한 계정 제한

• 이후 192코어 EC2 Spot 인스턴스를 실행해 약 3시간 테스트하던 중 AWS에서 “Suspected security breach of your account” 이메일을 받음
• 거의 휴면 상태였던 계정이 갑자기 비싼 컴퓨팅 자원을 쓰기 시작한 점이 AWS 내부 보안 경보를 트리거했을 가능성이 있다고 봄
• AWS가 사용자를 보호하려는 목적 자체는 이해하고 긍정적으로 평가함
• 하지만 AWS는 계정을 정지 또는 제한했고, 그 결과 AWS WorkMail로 쓰던 주 사업 이메일 계정이 동작하지 않게 됨
• 더 이상 누구도 이메일을 보낼 수 없었고, 어떤 AWS 리소스도 만들 수 없어 원래 하려던 테스트도 계속할 수 없게 됨

지원 대응과 지연

• AWS 지원 알림에 답장해 계정이 해킹되지 않았고 문제나 과금 이상도 없다고 알렸지만 응답이 없었음
• 프리미엄 지원을 쓰지 않아 AWS가 말한 24시간 응답 시간을 기다려야 했고, 3일이 지나도 AWS 지원 응답이 오지 않음
• AWS 포럼에 도움을 요청한 뒤, 이메일 지시사항을 수행하고 웹 대신 채팅을 쓰라는 조언을 받음
• 비밀번호 변경, 액세스 토큰 삭제, 청구 내역 확인 등 요청받은 조치를 모두 수행했고, 채팅 연결까지 약 30분을 기다린 뒤 AWS 담당자와 장시간 대화함
• 담당자는 만족한 듯 보였고 관련 내부 팀에 처리를 요청하겠다고 했지만, 24시간이 지나도 제한은 해제되지 않음
• 8시간 뒤 후속 문의를 했을 때는 “기다려 달라”는 답변만 받음

다시 확인된 결론

• 계정이 제한된 지 4일이 지난 시점에도 큰 장비에서 테스트하고 싶은 작업은 남아 있었고, 이를 위해 다시 “quota” 요청을 해야 할 일을 걱정하게 됨
• 사업용 이메일 시스템은 여전히 동작하지 않았음
• 이번 복귀 경험은 AWS를 떠난 이유를 다시 확인시켰고, AWS WorkMail을 벗어나고 Route53의 도메인도 옮겨 다시는 돌아오지 않아야겠다고 판단함
• 과거 AWS에서 벗어나 둔 점은 매우 다행이었지만, 신뢰하고 남겨둔 이메일 시스템이 AWS 복귀 과정에서 중단된 점은 실패로 받아들여짐
• AWS가 언젠가 계정 제한을 풀 수도 있지만, 그 시점은 알 수 없음