# AWS로 돌아갔고, 내가 왜 떠났는지 다시 깨달았다 > Clean Markdown view of GeekNews topic #29364. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29364](https://news.hada.io/topic?id=29364) - GeekNews Markdown: [https://news.hada.io/topic/29364.md](https://news.hada.io/topic/29364.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-11T01:34:27+09:00 - Updated: 2026-05-11T01:34:27+09:00 - Original source: [fourlightyears.blogspot.com](http://fourlightyears.blogspot.com/2026/05/i-returned-to-aws-and-was-reminded-hard.html) - Points: 1 - Comments: 1 ## Topic Body - 초기부터 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가 언젠가 계정 제한을 풀 수도 있지만, 그 시점은 알 수 없음 ## Comments ### Comment 57185 - Author: neo - Created: 2026-05-11T01:34:27+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48073201) - 몇 년 전 한 회사에 합류해 개발팀을 맡고 3개월 안에 제품을 출시하라는 요청을 받았는데, AWS에서 새 머신을 추가하려고 보니 **가격이 UI에 안 보이는 구조** 자체가 적대적이고 착취적인 관계의 신호처럼 보였음 사양 표와 가격표를 따로 열어 대조해야 했고, 과거 경험상 이런 신호를 보고도 떠나지 않으면 이후의 결과는 내 책임이라고 봤음 그래서 **DigitalOcean** 계정을 만들고 전부 이전한 뒤 CI/CD도 그쪽으로 배포하게 설정했고, 남은 두 달은 제품에 집중해 약속보다 한 달 빨리 출시함 예전에 강가에 구멍을 파고 강과 구멍을 파이프로 연결해 물고기가 스스로 덫으로 들어가게 하는 영상을 봤는데, 최소 저항 경로를 택하고 실수를 되돌리지 않는 태도가 그 물고기처럼 끝나는 비결이라는 인상이 강하게 남았음 - Azure에서 마음에 드는 점 중 하나가, 개별 항목을 만들 때마다 가격을 과하게 들이밀지는 않지만 비쌀 수 있는 항목에는 대체로 **가격을 보여주는 균형**이 있다는 것임 아직 요금 때문에 놀란 적은 없음 - Amazon 엔지니어링 문화가 꽤 **엔지니어 주도 제품 문화**라서 개발자가 UX와 흐름까지 책임지는 경우가 많지 않나 싶음 예전에 AWS 인턴을 마친 주니어 개발자를 채용했는데, 여름 동안 제품 담당자나 디자이너 도움 없이 혼자 만든 대시보드를 보여줬고 정말 끔찍해 보였음 일부 개발자는 제품/UX 감각이 좋지만 대다수는 UX에 심각하게 약하니, 의도적이었다기보다 그냥 나쁜 UX 문화였을 가능성이 큼 - 올바른 방식은 **출시를 도와주는 인프라 제공자**를 고르는 것임 AWS는 좋지만 모두에게 맞는 건 아니고, Heroku 같은 서비스와 베어메탈 사이 어딘가에서 유지보수를 많이 추상화하면서도 확장 아키텍처 제어권을 일부 줌 즉 클라우드 제공자로서 AWS는 확장에는 도움이 되지만, 가장 싸고 단순한 구성을 만들기 위한 도구는 아님 VC 자금이 있고 성장을 내세운다면 AWS가 안전한 선택일 수 있고, 액셀러레이터를 통한 2년 스타트업 크레딧 덕분에 첫 18개월은 인프라 예산보다 구축에 집중할 수 있음 부트스트랩이나 인디 개발자라면 감당 가능한 단순한 것을 고르면 되고, **Hetzner나 DigitalOcean**이면 충분히 잘 돌아감 - AWS에는 꽤 괜찮은 **가격 계산기**와 쓸 만한 프리셋이 있지만, 당연히 완전히 별도 앱임 Amazon은 가격 정보를 손쉽게 확인하는 데 약간의 마찰이 있길 원하겠지만, 주된 이유는 Conway의 법칙처럼 보임 AWS는 여전히 자기 조직도를 제품으로 내보내고 있음 - 어느 정도 동의하지만, AWS 가격은 UI에 뜨는 정적 숫자 하나로 얼마를 낼지 계산할 수 있을 만큼 단순하지 않음 비용 대조를 위해 탭 두 개 여는 게 불편하다면 AWS뿐 아니라 모든 클라우드 제공자를 피하는 게 나을 수 있음 **NAT 게이트웨이, CloudFront, S3, 자동 확장, 로드 밸런서**가 들어가면 비용 계산은 정확한 과학이라기보다 예술에 가까워짐 이런 것들을 쓰지 않는다면 AWS를 쓸 이유가 별로 없고, 저렴한 VPS 제공자는 많음 - OpenSearch와 Valkey만 놓고 보면 “AWS가 포크를 만들어서 라이선스 변경을 유발했다”는 설명은 완전히 거꾸로임 AWS는 상류 프로젝트가 라이선스를 바꾼 뒤에야 포크를 만들었고, 특히 **Valkey**는 이전 Redis 핵심 개발팀 구성원들이 만든 것임 - 이런 프로젝트 상당수는 핵심 제품을 오픈소스로 공개하고, 고급 서비스·설치·유지보수·완전관리형 서비스를 제공하는 비즈니스 모델로 운영됨 AWS가 완전관리형 서비스를 제공해 그들을 우회했기 때문에, 이 건에서는 프로젝트를 만든 사람들 편에 서게 됨 기본적으로 **AWS가 그들의 밥그릇을 가져간 것**이고, 라이선스를 바꿀 수밖에 없었음 - 그 라이선스 변경 자체가 AWS가 상류 프로젝트에 지속 불가능한 방식으로 그들의 작업을 수익화한 데 대한 대응이었음 - Amazon이 자신들이 판매하는 **오픈소스 소프트웨어**의 제작자와 유지보수자에게 사용 청구 기간당 1센트씩만 지급하면 얼마나 타격이 있을지 궁금함 그렇게 하면 오픈소스 팀에는 어느 정도 돈이 될지도 궁금하고, 제품 개선에 위험 부담 없이 기여하게 만들 수 있을 듯함 - Redis에 처음 패치를 보냈을 때 커미터 한 명이 내 메시지에는 답하지 않고 그 패치를 자기 이름으로 넣은 뒤부터, 많은 오픈소스 프로젝트 철학에 대한 공감이 사라졌음 그들은 **Valkey**를 겪을 만함 JBoss와 Marc Fleury도 아직 기억남 - AWS가 해당 프로젝트의 코드로 돈을 벌지 못하게 라이선스를 바꾼 뒤에야 포크를 만든 건 당연함 그게 바로 핵심임 - 클라우드 서비스와 셀프호스팅 사이를 몇 번 오갔음 처음에는 **Vercel**을 썼고, 프로젝트가 Next.js라 경험은 괜찮았지만 사용자 100명도 안 되는 프로젝트에 월 20달러가 필요해 성능 요구가 낮은 서비스치고는 비싸게 느껴졌음 이후 Hetzner와 Coolify로 자체 서버를 구성했는데, Coolify가 오픈소스라 VPS 비용만 내면 됐고 월 5달러로도 PostgreSQL 인스턴스와 웹 서버를 돌릴 수 있었음 하지만 PostgreSQL과 Redis 유지보수에 여전히 손이 많이 갔고, Docker 컨테이너 안에 있어도 서비스 사이에 시스템 변수와 환경 변수를 넘기는 일이 번거로웠음 그래서 나중에는 **Cloudflare Workers, D1 Database, Cloudflare KV**로 옮겼고, Worker 안에서 바로 호출할 수 있어 환경 변수 전달이 필요 없었음 로컬 개발 경험도 좋고 가격도 합리적이라 이후 Cloudflare 제품군 전체를 계속 쓰고 있음 - Cloudflare 제공 기능이 내가 AWS에서 원했던 것에 가까워졌음 기본적인 **풀스택 앱과 파일 배포**가 훨씬 단순하고, AWS는 셀프호스팅보다도 훨씬 어려워졌음 - Docker가 PostgreSQL 관리를 더 쉽게 해줬는지 궁금함 PostgreSQL에서 겪는 유일한 문제는 새 메이저 버전으로 옮길 때 약간의 마이그레이션 작업 정도임 서비스 사이에 시스템 변수와 환경 변수를 넘기는 일이 Docker 때문에 더 어려워졌는지도 궁금함 - Cloudflare Workers를 좋아하고 싶었고 기술적으로 좋은 이유도 있겠지만, 이메일 활성화 같은 작업에 **Wrangler 프로젝트**를 써야 하는 방식은 플랫폼에 묶이기 직전처럼 느껴졌음 이메일을 허용하려면 필요한 바인딩을 설정해야 하는데, 콘솔에서는 설정할 수도 없고 Wrangler가 설정한 뒤에는 볼 수도 없는 것처럼 보였음 - 작성자가 **DynamoDB**를 싫어하는 게 의외임 내가 가장 좋아하는 AWS 서비스 중 하나이고, 가용성이 좋고 운영 부담이 없으며, 쓸 때마다 비용도 꽤 낮았음 다만 데이터 모델을 미리 설계하는 데 시간을 들여야 하고, 그러려면 서비스 문서를 읽고 이해해야 함 - DynamoDB는 의도된 방식으로 쓰면 꽤 좋음 기본적으로 좋은 영속성과 거의 무한한 테이블 크기 확장을 가진 비교적 단순한 **키-값 저장소**로 봐야지, SQL 데이터베이스처럼 쓰려고 하면 안 됨 프로토타입 코드로 75달러 청구서를 만드는 가장 쉬운 방법은 JOIN과 GROUP BY 같은 걸 쓰는 SQL 데이터베이스처럼 다루도록 바이브 코딩하는 것임 정말 빛나는 곳은 작은 영속 저장용 테이블 1~2개가 필요하지만 전체 RDBMS를 관리하고 싶지 않을 때, 또는 아주 큰 테이블 하나를 단순한 방식으로 조회하면서 RDBMS에 맞추고 싶지 않을 때임 - DynamoDB와 Lambda 같은 여러 서비스는 **아주 특정한 사용 사례**가 있음 즐거운 키-값 저장소를 데이터베이스로 쓰면 안 됨 - 몇 년 전 앱을 만들면서 약 5천만 건의 레코드, 월 1만 회 정도 읽기+쓰기, 인덱스 1개를 저장할 DB가 필요했음 처음 적재 비용은 약 50달러였고, 이후 유지 비용은 월 10센트 같은 수준이었음 - 이런 글을 보면 늘 웃음이 나옴 맞는 동시에 틀렸고, 시스템은 “가능한 한 단순하게, 하지만 그보다 더 단순하지 않게” 만들어야 함 세부 사항을 대충 넘길 수 있다고 생각하면 나중에 더 큰 번거로움이 생김 **IAM**은 그냥 복잡함 사용자, 그룹, 역할, 정책, 신원 제공자, OIDC를 정말 단순하게 구현한 사례는 떠오르지 않음 예전에 Kubernetes 도입을 “너무 복잡하다”며 반대한 사람이 결국 Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash와 침, 풀로 Kubernetes를 조악하고 임시방편으로 재발명하며 많은 실수를 하는 걸 봤음 어떤 기능은 필요 없다고 생각하다가 결국 필요해짐 스타트업에서 단독 인프라 담당자로 일해본 입장에서 AWS는 대부분이 배울 수 있는 범위 안에 있고, 형편없는 부분은 보통 피할 수 있음 Lambda가 싫으면 쓰지 말고, **EKS, ECS, EC2**를 쓰면 됨 - 내부 관점에서 보면 IAM에는 옵션이 수천 개쯤 있지만 본질은 “이 역할이 무엇에 접근해 무엇을 할 수 있는가(작업+리소스)”와 “누가 이 역할에 접근할 수 있는가”임 1만 피트 상공에서 보면 그게 전부임 IAM이 좋은 이유는 외부와 내부에 똑같이 적용되기 때문임 AWS 내부 팀이라고 더 많은 접근권을 갖는 게 아니고, 특정 서비스를 수행하려고 고객 계정에서 어떤 일을 할 권한이 생긴다면 고객이 IAM 신뢰 관계에 서비스 주체를 넣어 접근을 허용했기 때문이며, 고객은 이를 보고 감사할 수 있음 예를 들어 Lambda에는 Lambda 역할이 있는데, “우리는 AWS니까 자동으로 접근 가능”이라는 이유로 Lambda 서비스가 S3 버킷을 읽는 걸 원하지 않기 때문임 AWS 내부 접근이라도 고객이 확실히 보고 제어할 수 있음 - “X는 너무 복잡하다”며 도입을 막다가 결국 X를 조악하게 재발명하는 패턴은 기술과 소프트웨어에서 놀랄 만큼 흔함 어떤 것들은 이제 명백한 **표준**인데도, 많은 사람이 제대로 배우는 데 시간을 쓰길 거부함 - 셀프호스팅보다 AWS가 비쌀 수는 있지만, 그 절감액은 엔지니어링 비용 앞에서 작아짐 괜찮은 인프라 엔지니어가 “돈을 아끼겠다”는 OVH 구성에 두 달을 쓰면, 그냥 **Fargate나 RDS**를 쓰지 않아서 절약할 수 있는 돈보다 더 비쌈 - Anthropic, OpenAI 같은 곳에 대해서도 언제쯤 같은 이야기가 나오기 시작할지 궁금함 지금 AI 흐름은 AWS 초기와 비슷한 냄새가 나고, 모두가 올라탔다가 나중에 쉽게 떼어내기 어려운 **큰 의존성**을 쌓았다는 걸 깨닫게 될 듯함 - Lambda는 정말 멋지고, 머리 아프지 않게 빠른 반복 주기로 배포 서비스를 운영하는 최고의 방법이라고 봄 꼭 마이크로서비스로 가거나 코드를 수십억 개의 작은 저장소로 쪼갤 필요는 없음 서버 내 상태를 요청 간에 공유할 수 있다고 기대하지 않는다면, 표준 웹 서버를 **Lambda**로 옮길 수 있음 - 그 분야에서 일하지 않아서 AWS는 가끔 개인 재미 프로젝트에만 만지는데, 매번 악몽 같음 실험용 카드 게임 서버 하나 만들려는 거지 새 금융기관을 세우려는 게 아닌데, 모든 게 내일 무한 확장할 준비를 하고 천 명짜리 조직과 VC 예산을 전제로 하는 것처럼 보임 다행히 **Netlify** 같은 서비스가 겉을 덮어줘서 바다를 끓이지 않아도 됨 언젠가는 IAM, VPN, 그리고 뭔지 모를 것들을 실제로 배워야 할지도 모르지만, 그때까지는 AWS를 만질 때마다 눈이 튀어나올 듯함 - EC2나 Lightsail에서 원시 VPS를 띄우고 공인 IP를 붙인 뒤 끝내면 됨 모든 엔터프라이즈 패턴을 구현해야 하는 건 아님 - Heroku는 거의 20년 전에 대부분의 웹 앱에 필요한 것을 정말 정확히 맞췄다는 점이 놀라움 - Azure를 다뤄보지 않았다면 AWS만 악몽처럼 느껴질 수 있음 - Cloudflare로 옮겼는데 정말 숨통이 트였음 필요한 건 다 있고 가격도 합리적임 - AWS는 개인 프로젝트가 아니라 **엔터프라이즈**를 겨냥함 개인 프로젝트는 결국 비용만 중요해서 AWS에 의미 있는 매출을 주지 못함 - 2023년 이후 AWS에서 기술 인력이 체계적으로 비워지고 있음 대규모 해고나 두 차례의 성과개선계획을 통해서였고, 프리세일즈나 지원 쪽에서 실력 있던 동료들은 AWS에 남아 있지 않은 경우가 많았음 반면 업무 이력이 가장 모호한 사람들이 남고 승진한 경우를 자주 봄 AWS는 각자 위험을 감수하고 써야 하며, **Paul Vixie**가 와서 구해주지는 않음 - 오래전부터 **ElastiCache**가 유독 거슬렸음 RDS는 확장성, 적당히 최적화된 설정, 신경 쓰지 않아도 되는 백업 같은 가치를 더해주니 참고 돈을 낼 수 있음 하지만 ElastiCache는 부가가치가 거의 없는데 가격은 착취적으로 느껴짐 기본 Redis 설치와 비교해 더 느리고, 덜 최적화됐고, 덜 안정적이며, 아무 설정 없는 Redis는 여러 DB를 지원하는데 ElastiCache는 하나만 지원함 확장성 개선은 일부 있지만, 비슷한 인스턴스에서 기본 Redis가 ElastiCache를 워낙 크게 앞서기 때문에 그런 개선이 실제로 필요한 경우는 매우 드묾 - ElastiCache는 확실히 **셀프호스팅**을 고려할 만한 서비스 중 하나임 AWS가 API나 완성도 측면에서 크게 더해주는 게 많지 않고, 반대로 Redis/Valkey는 직접 호스팅하기 가장 단순한 서비스 중 하나임