2025년 AWS: 당신이 알고 있다고 생각하지만 지금은 틀린 것들

• AWS의 핵심 서비스들이 빠르게 진화하고 있음
• EC2, S3, Lambda 등 주요 기능들이 과거와 달리 사용자의 기대를 뛰어넘는 성능과 유연성을 제공함
• 네트워킹, 인증, 비용 절감 방안 등에서도 많은 변화와 최적화가 이루어졌음
• 잘못된 오래된 블로그 포스트나 정보 때문에 혼동이 생길 수 있음
• 최신 업데이트와 변화된 정책을 숙지하는 것이 AWS 활용에 필수적임

---

AWS 2025: 과거의 인식과 달라진 현재

• AWS는 20년 가까운 역사를 가진 클라우드 플랫폼으로, 그만큼 서비스의 ‘상식’이 계속 변화함
• 기존 사용자들도 변화의 속도를 따라가기 어려울 정도로 많은 핵심 기능이 개선되어 있음
• 여전히 오래된 정보를 제공하는 블로그 포스트도 많아, 실제 구성이 바뀐 점을 제대로 알아두는 것이 중요함

EC2

• EC2 인스턴스의 시큐리티 그룹과 IAM 역할을 이제는 중단 없이 변경할 수 있음
• 실행 중인 인스턴스에서 EBS 볼륨의 크기 변경, 연결/해제 작업이 가능함
• 최근 EC2 인스턴스를 강제 중지 또는 종료할 수 있어, 긴 타임아웃을 기다릴 필요 없음
• 물리 호스트 간 라이브 마이그레이션 기능이 도입되어, 인스턴스 성능 저하 경고가 드물어짐
• 인스턴스의 신뢰성이 대폭 올라가, 예전처럼 인스턴스가 예고 없이 사라지는 일은 거의 없음
• Spot 인스턴스의 가격 변동이 점진적으로 바뀌어, 투기장처럼 실시간으로 감시할 필요가 줄어듦
• 전용 인스턴스가 필요한 케이스가 극히 드물어짐(HIPAA BAA도 거의 10년 전부터 필요하지 않음)
• AMI Block Public Access가 신규 계정에서 기본값으로 활성화됨(2023년 기준 90일 이상 퍼블릭 AMI 미소유 계정에도 적용됨)

S3

• S3는 더 이상 Eventually Consistent가 아니고, Read-After-Write Consistency를 제공함
• 객체 키의 첫 부분을 임의화할 필요가 없어져 데이터 분산 및 핫스팟 문제 걱정이 줄어듦
• ACLs(Access Control List) 가 더 이상 권장되지 않으며, 신규 버킷에서는 기본적으로 꺼져 있음
• 신규 버킷은 Block Public Access가 기본값으로 설정됨
• 자동으로 저장자료 암호화가 적용됨
• Glacier가 S3의 스토리지 클래스가 되기 전, 별도의 서비스였으나 현재는 결합되어 있음. 청구 내역 등에서 그 흔적만 남아 있음
• Glacier 복원 비용과 속도가 과거와 비교해 상당히 예측 가능해지고 저렴해졌음. 이전 공포스런 복원 비용은 사실이 아님

네트워킹(Networking)

• EC2-Classic은 완전히 사라짐
• 공인 IPv4 주소가 이제는 무료가 아니며, Elastic IP와 동일한 비용이 부과됨
• VPC Peering 대신 Transit Gateway, VPC/리소스 공유, Cloud WAN 등 더 좋은 옵션이 등장함
• VPC Lattice와 Tailscale로 복잡한 네트워킹 문제를 쉽게 해결 가능함
• CloudFront 업데이트 반영 시간이 45분에서 5분 내외로 단축됨(여전히 CloudFormation 배포 대기시에는 길게 느껴질 수 있음)
• ELB Classic은 교차 AZ 데이터 전송 요금이 부과됐으나, ALB는 LCU 요금만 부과함. NLB는 여전히 교차 AZ 요금이 부과됨에 주의
• Network Load Balancer에 시큐리티 그룹 지원이 추가됨
• 가용 영역(Availability Zone) ID가 계정마다 달랐지만, 이제 Resource Access Manager로 Zone ID 정렬이 가능함

Lambda

• Lambda는 5분 제한에서 15분으로 실행 시간이 늘고, 컨테이너 이미지(Docker) 및 EFS 공유 스토리지, 최대 10GB RAM, /tmp 10GB 지원이 추가됨
• VPC 내 Lambda 호출 속도가 대폭 개선됨
• 콜드 스타트 이슈가 과거보다 크게 완화됨

EFS

• EFS IO 성능 조정이 이제 용량과 별도로 조절 가능해, 무의미한 데이터로 공간을 채울 필요 없음

EBS

• 신규 EBS 볼륨은 기초 데이터가 없으면 즉시 최대 성능 사용 가능함
• 스냅샷에서 생성된 볼륨은 첫 데이터 읽기 시 느릴 수 있으니, 전체 디스크를 한번 읽는 것이 권장됨(더 빠른 옵션도 제공됨)
• io1 볼륨은 여러 EC2 인스턴스에 동시 연결 가능하지만, 실제로는 매우 특수한 상황에만 권장됨

DynamoDB

• 항목 안에 빈 필드를 허용하게 되었음
• 성능이 훨씬 일정해져, 예전처럼 핫키(Hot key) 문제 모니터링을 별도 도구로 해야 할 필요가 적어짐
• Pricing 변화로, 대부분의 사용자는 On Demand 타입이 더 합리적임

비용 절감 옵션(Cost Savings Vehicles)

• Reserved Instances는 점차 단종 중이며, Savings Plans가 앞으로의 표준임. Savings Plan의 할인율이 RI 대비 하락했으나, 유연성이 더 높아졌음
• EC2 사용 요금이 초 단위로 과금되므로 매우 짧게 인스턴스를 켜도 비용 효율적임
• Cost Anomaly Detector는 예기치 않은 사용 패턴을 뛰어난 정확도로 감지하며 무료임
• Compute Optimizer는 EBS 등 다양한 리소스 추천을 제공하며 신뢰도가 높음. Trusted Advisor의 추천은 아직도 일관성이 부족함

인증(Authentication)

• IAM 역할을 통한 권한 부여가 권장되며, IAM 사용자는 레거시 앱에만 적합함
• IAM Identity Center가 AWS SSO를 대체하며, 계정 접근에 사용됨. 이로 인해 혼란이 일부 존재함
• 루트 계정에 다중 MFA 장치를 등록할 수 있음
• 조직 구성원 계정에 별도로 루트 자격 증명을 구성할 필요 없음

기타(Miscellaneous)

• us-east-1의 신뢰성과 내구성이 전보다 크게 향상됨. 예전처럼 자주 발생하던 장애가 이젠 뉴스가 될 만한 사건임
• AWS 서비스의 폐기(Deprecation) 는 여전히 드물지만 증가 추세이니, 마이너 서비스에는 의존도 고려 필요함
• CloudWatch 데이터의 마지막 포인트가 불일치로 비정상적으로 낮게 나타나는 현상이 더는 발생하지 않음
• 루트 계정에서 조직 내 멤버 계정의 AWS 계정도 직접 종료(닫기) 가능함

[roxie]

와 많이 변했네요 정말

[howudoin]

AWS는 이제 단일 서비스를 골라 쓸 수 없음.
뭐 하나 하려면 이것저것 다 물려서 써야됨.
결고 단순하지 않음.
벤쳐에서 쓰려면 클라우드 비용뿐만 아니라 devops 인건비도 써야됨.
제대로 구축하려면 개발 시간 다 뺏길 정도로 배보다 배꼽으로 업무량이 급증함.
게다가 managed 서비스를 써야 더 좋은 경우가 늘어서 코드 레벨에서 이미 플랫폼 의존적이 됨.

[GN⁺]

Hacker News 의견

• S3의 "Block Public Access"가 이제 새 버킷에 기본 적용됨을 보며, 당연히 옳은 결정이라 생각함, 그동안 잘못 구성된 S3 버킷 때문에 거대한 데이터 유출이 많이 일어났음, 하지만 가끔씩 나는 파일을 공개적으로 서빙하려고 퍼블릭 읽기 권한이 있는 S3 버킷을 만들고 싶은데, 매번 뭔가 바뀌어서 예전 레시피가 안 먹히고 처음부터 다시 공부해야 하는 상황이 반복됨
  • "Block Public Access" 설정을 주의 깊게 보라고 말하고 싶음, 이건 사람들이 큰 실수를 안 하도록 해주는 일종의 안전장치임, 만약 매우 허술한 bucket policy나 ACL(구식이지만 여전히 사용됨)을 설정해도 Block Public Access가 켜져 있으면 퍼블릭 엑세스가 불가능함, 반대로 Block Public Access를 꺼두고, 아주 잘 설계한 버킷 정책을 써도 괜찮음, 버킷 정책이 누가 접근 가능한지 전적으로 결정함, 물론 장기적으로 정책이 우연히 바뀌거나, 예기치 않게 IAM 역할이 추가되거나, 신뢰 정책이 변경될 수 있으니 그에 대한 관리가 중요함
  • 나는 이런 상황에서 LLM을 자주 사용함, 문서 읽어주고 AWS 공식 문서 여기저기에 박혀 있는 데모 코드를 뽑아달라고 요청함, 얻은 후에 원하는 커스텀 수정도 바로 물어봄
  • 이거 예전에도 하지 않았나 하는 기시감 느낌, 10년 전에도 다들 버킷을 오픈으로 놔둬서 이런 조치 하지 않았나 싶음
  • 이런 변화 때문에 면접에서 "이 기술 익숙하세요?"라는 질문이 너무 애매해짐, 기술이 매달 바뀌니 언제 기준으로 아는지 묻고 싶음
  • 공식적으로 배우려면 $250 내고 인증 시험까지 치르게 해줌
• EC2에서 인스턴스 종료 없이 보안 그룹이나 IAM 역할 교체 가능한 건 몇 년 전부터 가능하던 일이었음, 스팟 인스턴스는 과거엔 입찰 시장이었는데 지금은 입찰 자체가 없어져서 오히려 급격한 가격 변동이나 특정 유저만 접근 가능한 일이 없어져서 훨씬 좋음, 그리고 예전엔 객체 키 앞부분 무작위로 만들어 핫스팟을 피해야 한다고 했지만, 지금은 그럴 필요가 없어졌음, 동료들에게 설득하는데 한참 걸렸지만 이 사람들은 어차피 S3 백엔드 병목과 관련 없는 초미니 파일들만 저장하고 있었음, Lambda는 예전엔 5분 제한에 컨테이너 이미지도 지원하지 않았는데, 지금은 15분 런타임, Docker 이미지, EFS 공유, 최대 10GB RAM, /tmp 저장공간 10GB까지 지원함, 나도 한 가지 깨달았던 게 Python 글로벌 스코프도 /tmp처럼 살아남는다는 점임
• Glacier 복원이 이제 고통스럽게 느릴 필요가 없어졌음, Amazon 스타일로 추측해봤을 때 예전 Glacier는 어디선가 실제 Amazon 물류창고에서 돌아갔을 거란 생각이 있었음, 데이터 요청하면 작업자가 선반에서 이동식 미디어를 찾아서 서버에 꽂는 느낌이었음, 옛날 시분할 컴퓨터의 테이프 백업 방식과 비슷했음, 당시엔 테이프를 직접 물리적으로 교체해야 했음
  • 실제로는 테이프 로봇 같은 자동화 장비를 썼을 확률이 높다고 봄, 관련 사진 예시, 사람이 아닌 로봇이 테이프 찾아서 드라이브에 넣고, 오프셋으로 감고 읽은 뒤 다시 되감아서 반납하는 방식임, 대기 시간이 생기는 건 테이프 찾기, 되감기, 그리고 드라이브 대기 때문임, 아마 효율 위해 한 번 넣은 테이프 내 요청 다 처리하고 꺼내는 식이었을 것임
  • 내부 사정에 대해선 공개할 순 없지만 Glacier 설계를 정확히 맞춘 사람을 본 적은 없음, 나도 예전 AWS에 있었는데 어차피 Glacier도 다른 AWS 서비스와 동일한 데이터센터에서 운영됐다고 얘기할 수 있음, 엔지니어링이나 제품관리에서 중요한 건 고객의 기대치를 잘 관리하는 거임, 만약 업로드 제한이 10개라고 해놓고 12개 올리게 두면 고객이 계속 12개로 기대하게 됨, 기대 관리가 중요함
  • 하드디스크가 균일해서 웨어하우스는 자동로봇으로 돌린다고 생각함, 사람을 쓰는 건 다양한 크기, 형태 같은 비표준 처리 때문임
  • 어쨌든 이런 장비들은 수십년 전부터 로봇화 되어왔음
• 나는 AWS 계정에 더이상 로그인할 수 없음, MFA를 미리 안 해뒀기 때문임, 장치를 발급받으려고 해도 로그인부터 필요함, 미리 경고를 듣긴 했지만, 로그인 없이 MFA 장치 신청 못하는 구조는 꽤 답답함
  • 지원팀에 문의해보는 게 좋을 듯함
    AWS Support 문의
  • 지원팀에서 쉽게 풀어줄만한 문제로 보임
• 나 같은 사람 많을거라 생각함, 원래 AWS 방식대로—API Gateway, serverless Lambda에 IAM 역할까지 손대서 맞추는 복잡함—이제 놔두고, 그냥 EC2나 LightSail VPS, S3 버킷, Route53로 도메인 연결만 하고 나머진 신경 안 쓰고 싶어짐
  • 스토리지+VPS만 쓸 거면 AWS보다 전통 VPS가 훨씬 저렴함, 나는 오히려 AWS를 쓰는 이상 제대로, 많이 써야 한다는 철학임, 위임 가능한 건 모두 Amazon에 넘겨서 효율과 비용 절감하는 식임, Step Functions, Lambda, DynamoDB도 대체재를 능가해왔음, 다만 개발자들이 벤더 활용 최적화를 생각보다 잘하지 않는 게 아쉽다고 느낌
  • 실제로 클라우드를 간소화한 업계도 많은데, 그 이유는 서비스 지역 제한이나 예측 가능한 청구 때문임
  • IAM 관리가 너무 시간소모라서, 예전엔 시스템 관리에 썼던 시간이 이제 퍼미션 관리에 다 들어가는 느낌임, IAM이 너무 어려워서 실상은 순손해임, VPS와 과도한 서버리스 최소권한 관리의 중간쯤에 스위트스팟이 있을 것 같음, Fargate가 그 후보인데 더 옮겨보면서 실험해보려 함
• AWS는 다른 분야 따라가겠다며 AI 쪽에서 산만하게 이것저것 내놓기보다, 기존에 잘하던 "기초적이지만 중요한 서비스"에 더 집중했으면 좋겠음, AWS 리더십이 GenAI 쪽에선 방향성을 놓친 느낌이지만 기본 인프라는 잘 만듦, AI 때문에 패닉 상태로 보이고 고객 입장에선 너무 산만해져서 불편함
  • 지금 리더십의 방향은 인프라를 모두가 간단히 모델 고르고 바로 쓸 수 있게 해주는 쪽임, 셋업 복잡함 없이 바로 가능한 환경 추구임
• S3 버킷이 VPC와 같은 리전에 있더라도 퍼블릭 인터넷 경유하면 NAT Gateway 비용이 청구되는 게 정말 말이 안 됨, 기본값은 opt-out이 돼야 마땅한데, opt-in이 기본인 건 아마 AWS가 이 구조로 추가 수익을 거두기 때문이라 봄, 현재 경로를 바라는 사용자는 극히 드물 것임
  • 이건 보안이 기본값이란 점을 고려한 설계임, NAT Gateway, VPC Gateway Endpoint(S3), 기타 인터넷 출구를 모두 설정하지 않으면 워크로드는 S3에 접근 못함, 네트워킹은 닫혀있는 게 맞고, 만약 사용자가 경로를 잘 이해하지 못하고 뭘 만든다면 그 책임은 고객에게 있음, AWS는 Infrastructure as a Service(IaaS) 원시적인 도구만 제공한다고 생각해야 함
  • S3 VPC Gateway Endpoint가 바로 이 목적임, 요금도 무료임
    AWS 공식 문서
  • VPC, 서브넷, PrivateLink 엔드포인트 등 모두 셋업해보고 나면 정말 황당하게 느껴짐, PrivateLink란 이름 짓는 데도 공 들였고(기술적으로도 의미는 있지만), 이런 게 애초에 셋업 없이 기본 제공이어야 한다고 생각함, 심지어 프라이빗 서브넷 사용하는 경우 S3 등의 접근은 PrivateLink가 유일한 방법 아닌지, 이상하게 느껴짐
  • VPC 엔드포인트는 전부 무료로 기본 적용돼야 한다고 생각함, 자기 서비스 API 쓰는데도 추가 과금 구조는 좀 심함
  • 이건 가격 차등화 목적임, 가격에 민감하지 않은 고객은 굳이 신경 안 씀, 신경 쓰는 쪽은 비용 줄이려고 노력하게 되고, 그런 상황에서도 종종 어쩔 수 없이 AWS를 써야 하는 경우가 많음
• 이번 기사 덕분에 안심했음, Amazon이 뭔가 크게 바꿔서 마이그레이션 강요하면 어떡하나 늘 걱정했는데, 2013년부터 EC2 인스턴스를 거의 관리할 필요 없이 잘 쓰고 있었음, 예상치 않은 변화가 없어서 다행임
• 과거 Availability Zones가 계정별로 랜덤 매핑이었던 게 충격적임
  • 이건 부하 분산 때문이었음, 여러 계정에서 1b처럼 특정 AZ를 고정으로 쓸 경우 실제 물리적인 분산이 골고루 되도록 했던 것임, 나중엔 AZ별 canonical 이름이 제공됐는데, 실제로 핫스팟 만들던 계정들과 메타데이터가 필요한 계정이 달랐기 때문일 거라 생각함
  • 기본 설정에서 모두 us-east-1a만 골라버리면 특정 AZ에 쏠리는 걸 막으려던 목적이라고 봄
  • 처음엔 부하 분산엔 좋았는데, 여러 계정 간 네트워크(PrivateLink 등) 연결할 때, 어떤 AZ가 어디랑 매칭되는지 일일이 확인해야 해서 혼란스러웠음, 그래서 계정마다 일대일 맵핑 방법론 만들고 내부 조회 테이블까지 구축했는데, 나중엔 AWS가 zone ID를 메타데이터에 추가해서 쉽게 조회 가능하게 해줬음
  • 이 정책 때문에 정말 고생한 적 많음
• 바로잡고 싶은 점이 있음, 의미 없는 잡지식이 다 뒤집힐 수 있음
  Weird Al: Everything You Know is Wrong
  Firesign Theatre: Everything You Know is Wrong