CloudFront 캐시 TTL 설정 — 헤더 우선순위와 무효화 비용까지 실측 기반 분석
CloudFront 캐시 TTL 설정은 콘솔의 숫자 세 개가 아니라 오리진 헤더와의 협상으로 결정된다. 적중률이 60%대에서 멈춘 이유와 89%까지 끌어올린 정책 조합을 정리한다.
CloudFront 캐시 TTL 설정은 콘솔의 숫자 세 개가 아니라 오리진 헤더와의 협상으로 결정된다. 적중률이 60%대에서 멈춘 이유와 89%까지 끌어올린 정책 조합을 정리한다.
Lambda에서 S3 SlowDown을 만나고 알게 된 AWS SDK 재시도 전략과 Jitter. boto3 standard·adaptive 모드와 Java SDK v2 설정을 코드로 정리한다.
Lambda 동시 실행 1000개와 PostgreSQL max_connections 87이 만나는 지점에서 'too many connections' 에러가 시작된다. RDS Proxy의 설정 방법, 연결 핀닝이라는 의외의 함정, 그리고 vCPU 시간당 과금의 실체를 본다.
Fargate는 비싸다는 말이 정설처럼 돈다. ephemeral runner 구조에서는 그 통념이 깨지는 지점이 있다. ECS Fargate 기반 self-hosted runner 설정과 실제 비용을 본다.
FastAPI 워커에서 주간 47건씩 발생하던 OOMKilled를 Kubernetes VPA 설정으로 3건까지 줄였다. HPA·수동 튜닝과 비교한 기준과 EKS 환경에서의 helm 설치, Recommender 모드 활용까지 다룬다.
단일 노드 ElastiCache로 버티다 메모리 한계를 만났다. 클러스터 모드 ON으로 전환하면서 샤드 슬롯, 키 해시태그, Failover 검증까지 거쳐온 3개월을 시간순으로 풀어본다. 처음부터 클러스터 모드로 갔어야 했다는 결론이다.
DynamoDB TTL 설정의 진짜 가치는 비용보다 운영 부담 제거에 있다. 자동 삭제 메커니즘과 실수하기 쉬운 함정 네 가지를 정리한 TIL 노트.
분당 단가는 비슷하다. 하지만 동시성, IAM 통합, 캐시 전략까지 보면 그림이 달라진다. 두 서비스를 같은 자에 놓고 비교한다.
HPA만으로 버티던 EKS 워커 클러스터에 KEDA를 도입한 3개월의 기록이다. SQS와 Kafka Lag 기반으로 스케일링을 다시 설계했더니 노드 평균 사용량이 30% 줄었다. 그 사이 IRSA 연결과 폴링 주기 때문에 헤맨 시간도 적지 않았다.
EKS 월 청구서가 세 배 가까이 뛴 뒤 Karpenter 전환, Spot 혼합, 리소스 요청 튜닝을 3단계로 적용해 약 40% 줄인 기록이다. Cluster Autoscaler와 Karpenter, EKS Auto Mode를 항목별로 비교한 기준도 담았다.