반응형 AWS65 Kubernetes AWS ALB/NLB 구성 yaml 1. AWS ALB Ingress 구성1.1 아키텍처 개요 특징✅ hostNetwork 불필요✅ externalTrafficPolicy 무관 (Service 안 거침)✅ Source IP: X-Forwarded-For 헤더로 전달1.2 Target Type 비교IP Mode (기본/권장)alb.ingress.kubernetes.io/target-type: ipALB → Pod IP 직접 (Service 거치지 않음) 항목 설명트래픽 경로ALB → Pod IP 직접Service 타입ClusterIP로 충분hostNetwork불필요externalTrafficPolicy무관요구사항AWS VPC CNI (Pod가 VPC IP 사용)Instance Modealb.ingress.kubernetes.io.. 2026. 1. 26. AWS EKS 버전 유지 시 확장지원 비용 리스크 (2024년 이후 변경) 목차 EKS를 운영하다 보면 “버전 업그레이드를 꼭 지금 해야 하나?”라는 질문보다 더 중요한 게 하나 있다.바로 Kubernetes 버전 지원 정책과 비용 변화다.결론부터 말하면, EKS는 예전(2024.04.01)과 달리 버전이 오래되면 비용이 급격히 증가한다.이 변화는 비교적 최근(에 도입되었고, 많은 운영 환경에서 체감 비용 차이를 만들고 있다.1. 과거 EKS 버전 정책: “비용 차이 없음”과거에는 EKS Kubernetes 버전이 지원 종료(EOL) 되기 전까지:클러스터 비용은 항상 동일“표준 지원 / 확장 지원” 같은 요금 구분이 존재하지 않음운영팀 입장에서는→ “조금 늦게 올려도 큰 문제 없다”는 판단이 가능했음즉, 업그레이드는 안정성·기능 관점의 문제였지, 비용 문제는 아니었다.2. 정.. 2026. 1. 12. AWS CloudFront 캐시 정책과 CORS 에러 Cloudfront 캐시 정책 설정시 CORS 에러가 발생하여 CloudFront 캐시 정책이 CORS 동작에 미치는 영향과 해결 방법을 상세히 정리합니다. 1. CloudFront 캐시 키(Cache Key) 이해캐시 키란?CloudFront가 캐시된 객체를 식별하는 고유 값입니다. 동일한 캐시 키를 가진 요청은 동일한 캐시 응답을 받습니다.기본 캐시 키 구성요소캐시 키 = URL + (선택적) 헤더 + (선택적) 쿠키 + (선택적) 쿼리스트링캐시 키에 헤더 포함 시 영향HeaderBehavior: "none" (헤더 미포함)├── /fonts/Pretendard.woff2 → 캐시 키 1개└── 모든 Origin에서 같은 캐시 응답HeaderBehavior: "whitelist" + Orig.. 2026. 1. 2. ASG + 스팟 인스턴스 + 사설 DNS 자동등록 잘 안쓰이는이유 구성을 해보는데 asg + spot instance 구성은 그렇게 어렵지 않았습니다. 하지만 private DNS 를 ec2 에 연결하면서부터 굉장히 복잡하게 구성이 됩니다. dns cache, spot instance의 부족으로 인하여 다른 인스턴스가 생성되며 다른 subnet 에 생성이 되어 제어하기가 굉장히 까다롭더군요. 생각해보니 대부분의 개발환경에서는 on-demand를 사용하던데 그이유를 좀더 자세히 알아보고자 포스팅합니다. 왜 잘 안 쓰일까?1) 스팟 특성과 개발 생산성의 충돌예고형 중단(2분 전 통지): 개발 중/테스트 중에 인스턴스가 종료되면 워크플로우가 끊깁니다.가용 용량 변동: 특정 타입/AZ에 스팟 용량이 모자라 스케일-아웃이 실패할 수 있음. “개발=빠른 반복”과 상충.비용 .. 2025. 9. 24. Spot 인스턴스를 안정적으로 쓰는 방법: ASG + Capacity-Optimized + Capacity Rebalancing 2편(단점, 무중단, 장점) 공식 문서에서 말하는 한계 & 주의사항AWS 문서 “Capacity Rebalancing in Auto Scaling”에 따르면 다음 같은 고려사항들이 있어요: AWS Documentation 항목 내용Application의 관용성애플리케이션이 Spot 중단/교체에 내성이 있어야 함. 상태 저장(stateful) 작업이나 연결 유지가 중요한 경우, graceful shutdown, 데이터 복제, 리플리카/리스너 종료 처리 등이 필요. AWS DocumentationLaunch Template / 인스턴스 타입 / AZ 다양성Spot 풀(pool)의 여유(capacity)가 많은 타입/AZ들을 여러 개 열어야 재보충(reserve)이 가능. 단일 타입/AZ만 쓰면 그 풀의 여유가 없을 때 복구가 어려움... 2025. 9. 22. EKS kubectl 연결 오류 해결기: NAT 교체 이후 발생한 함정 운영 중인 AWS EKS 환경에 Kafka 인프라를 추가하던 중, 갑자기 kubectl이 동작하지 않는 상황을 맞았습니다.이번 글에서는 문제 발생 원인과 해결 과정, 그리고 얻은 교훈을 정리했습니다.문제 상황Kafka 서브넷을 추가한 뒤, kubectl이 더 이상 연결되지 않았습니다.$ kubectl get nodesUnable to connect to the server: dial tcp 10.0.11.83:443: i/o timeout이전까지는 정상 작동DNS는 EKS Private IP로 정상 해석VPN도 연결 상태 양호즉, VPN–DNS–보안그룹 모두 정상인데 트래픽이 도달하지 못하는 상황이었습니다.(새로 생성한 kafka는 vpn에서 접속이 정상적으로 동작하고 있음) 진단 과정1. EKS 엔드포.. 2025. 9. 22. [AWS IAM] 사용자에게 S3 전체 버킷 조회 + 객체 Get/Put/Delete 권한 부여하기 S3를 다루는 사용자·역할(예: 개발자, CI/CD 러너)에게 모든 S3 버킷을 목록에서 보이게 하고, 각 버킷의 객체 업/다운로드 및 삭제까지 가능하도록 권한을 부여하는 방법을 정리했습니다.실무에서 바로 쓸 수 있는 정책(JSON), 콘솔/CLI/Terraform 적용 예시, 보안 팁(최소권한 설계)까지 포함합니다. 1) 권한 설계 요점버킷 목록 보기: s3:ListAllMyBuckets (계정 단위 동작 → Resource는 반드시 "*").버킷 내부 탐색: s3:ListBucket (버킷 리소스 ARN 필요, 콘솔/CLI에서 객체 키 목록 조회).객체 작업: s3:GetObject, s3:PutObject, s3:DeleteObject (객체 ARN 필요 → /* 포함).콘솔 편의: s3:GetB.. 2025. 8. 26. CloudFront + S3로 이미지 서빙하기: 한 배포, 여러 도메인, 경로 기반 라우팅 왜 CloudFront 앞에 S3를 두나?S3는 원본 저장소, CloudFront는 글로벌 캐시 + TLS + WAF + 헤더정책 + 로그의 허브 역할.버킷은 비공개로 두고, CloudFront만 읽게 하면 보안과 캐시 전략을 깔끔하게 가져갈 수 있어요(이때 OAC 권장). “한 배포에 여러 서브도메인”은 가능할까?가능합니다. 하나의 CloudFront 배포에 여러 개의 Alternate Domain Name(CNAME)(예: example.com, a.example.com, b.example.com …)을 등록할 수 있어요. 단, 같은 CNAME을 두 개 배포에 동시에 등록할 수는 없습니다(중복 불가). TLS 인증서는 us-east-1(버지니아 북부) 의 ACM에 있어야 CloudFront에 붙일 수.. 2025. 8. 25. ArgoCD + ALB + CloudFront 환경에서 HTTPS 리다이렉션 정리 쿠버네티스에서 ArgoCD와 여러 앱을 ALB(aws-load-balancer-controller) 뒤에 붙이고, 그 앞단에 CloudFront를 둔 구조를 쓰다 보면 HTTP→HTTPS 리다이렉션 충돌 문제가 자주 발생합니다. 이번 글에서는 실제 경험한 케이스와 함께, 왜 문제가 생기는지, 그리고 어떻게 정리하는 것이 좋은지 정리합니다.문제 상황ArgoCD, Grafana, Invitation 앱 등 여러 서비스가 같은 ALB 그룹(shared-alb) 을 공유.Invitation 앱의 Ingress에 리다이렉트 액션 (alb.ingress.kubernetes.io/actions.redirect-to-https) 이 설정되어 있었음.이 액션이 host 제한 없이 / catch-all 로 걸려 있어, 같.. 2025. 8. 24. AWS CloudFront 대체 도메인(Alternate Domain Names)와 Route 53 A 레코드 정리 CloudFront를 이용해 커스텀 도메인(example.com, app.example.com)을 연결할 때, 흔히 대체 도메인(Alternate Domain Name, CNAMEs) 과 Route 53의 A 레코드(Alias) 를 함께 사용합니다. 하지만 *.example.com 와일드카드와 루트 도메인(example.com) 처리가 달라 혼란이 생길 수 있습니다. 이번 글에서는 그 차이를 명확히 정리합니다. 구분*.example.com (와일드카드)example.com (루트 도메인)CloudFront Alternate Domain (CNAMEs)- 모든 서브도메인(app.example.com, api.example.com, …) 적용- 루트 도메인 포함 ❌- 반드시 별도로 추가해야 함- *.exam.. 2025. 8. 20. AWS Route 53 도메인에 SSL 인증서 발급 및 여러 리전 관리 방법 목차 1. AWS에서 SSL 인증서 관리 구조Route 53 → 도메인 DNS 관리ACM → SSL/TLS 인증서 발급, 자동 갱신ALB, CloudFront, API Gateway 등 → ACM 인증서를 연결하여 HTTPS 서비스 제공2. ACM에서 SSL 발급 및 Route 53 연동 방법ACM 콘솔 접속리전 주의: CloudFront는 us-east-1에서만 지원, ALB는 해당 리전에서 발급해야 함.인증서 요청Request a certificate 선택 → 퍼블릭 인증서 선택도메인 이름 입력 (예: example.com, *.example.com)검증 방식 선택DNS Validation 선택 (Route 53이면 자동 검증 가능)Route 53 자동 레코드 생성ACM이 제안하는 CNAME 레코드.. 2025. 8. 14. AWS VPC에서 OpenVPN 스플릿 터널 구성 & 트러블슈팅 목차 목표: 사내 VPC(10.0.0.0/16) 에 있는 프라이빗 서브넷들과 외부 단말(노트북 등)을 OpenVPN 으로 안전하게 연결하되, 인터넷 트래픽은 로컬로 내보내는 스플릿 터널을 구성한다. 실제로 겪은 증상과 해결 과정을 그대로 정리했다. 핵심 요약VPN 풀 대역은 VPC CIDR과 겹치면 안 된다. (예: VPC=10.0.0.0/16이면 VPN 풀=10.8.0.0/24, 10.99.0.0/24 등)양방향 라우팅이 성립해야 통신된다.프라이빗 서브넷의 라우트 테이블에 VPN 풀 → OpenVPN ENI 경로 추가 (리턴 경로)OpenVPN 인스턴스의 Source/Destination Check 비활성화0.0.0.0/0 으로 열면 되는데 10.8.0.0/24로 좁히면 안 되는 이유는 SNAT 때문이.. 2025. 8. 14. 이전 1 2 3 4 ··· 6 다음 반응형