본문 바로가기
반응형

CLOUD/AWS218

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.
Spot 인스턴스 안정성 확보: ASG + Capacity-Optimized + Capacity Rebalancing 활용하기 인프라 비용 절감 측면에서 Spot 인스턴스는 매력적입니다. 할인폭이 크지만, 중요한 단점은 “언제든 종료(interruption)”될 수 있다는 것.이 글에서는 Auto Scaling Group(ASG) + Capacity-Optimized 할당 전략 + Capacity Rebalancing 조합을 써서 Spot 인스턴스의 불안정성을 완화하고 높은 가용성을 확보하는 방법을, AWS 문서와 실제 운영 팁 중심으로 설명합니다.주요 컴포넌트 개념 정리 구성 요소 역할 요약Auto Scaling Group (ASG)인스턴스 수(desired capacity)를 자동으로 유지하며, Spot/On-Demand 혼합 가능. 실패/종료 시 보충 가능.Capacity-Optimized Allocation Strateg.. 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 Network Loadbalancer의 ALPN이란? NLB의 ALPN(Application-Layer Protocol Negotiation) 기능은 TLS 연결에서 클라이언트와 서버가 어떤 애플리케이션 프로토콜(HTTP/1.1, HTTP/2, gRPC 등)을 사용할지 협상하는 메커니즘입니다.즉, 클라이언트가 서버로 TLS 핸드셰이크를 할 때 "난 HTTP/2 또는 HTTP/1.1을 지원한다"라고 알리고, 서버(NLB 뒤의 Target 그룹)가 지원하는 프로토콜을 골라주는 방식이에요.1. ALPN 기본 개념TLS 확장(extension) 중 하나.애플리케이션 계층 프로토콜을 TLS 핸드셰이크 중에 미리 결정.Upgrade 헤더 방식보다 빠르고 안전하게 프로토콜 협상 가능.예:브라우저(클라이언트)가 HTTP/2 + HTTP/1.1 지원을 선언.서버가 HTTP.. 2025. 9. 9.
CORS “보여주기 vs 읽기”, 프리플라이트, S3·CloudFront 정리 다른 오리진 리소스를 “그려 넣기(표시/적용)”만 하면 보통 CORS 불필요: , , , 등.JS가 응답 “내용을 읽는 요청”(예: fetch/XHR, 픽셀 읽기, 웹폰트)은 브라우저가 SOP로 막음 → 서버가 CORS 헤더로 예외 허용해야 함. MDN Web Docs,2프리플라이트(OPTIONS) 는 “단순 요청(simple request)”이 아니면 뜸(예: Content-Type: application/json, 커스텀 헤더, PUT/DELETE 등). MDN Web Docs, 2Credentials(쿠키/서명/Authorization) 사용 시 Access-Control-Allow-Origin: * 금지, 정확한 오리진을 돌려야 함 + 필요 시 Vary: Origin. MDN Web DocsC.. 2025. 8. 28.
[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.
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.
AWS EKS에서 externalTrafficPolicy 설정에 따른 NLB 헬스체크 동작 차이: Ingress Controller vs 일반 서비스 AWS EKS에서 Kubernetes 서비스에 NLB(Network Load Balancer)를 연동할 때,externalTrafficPolicy 설정에 따라 NLB의 타겟 헬스체크 상태가 다르게 표시되는 현상을 종종 마주하게 됩니다.이 글에서는 특히 Ingress Controller를 사용할 때와 일반적인 서비스(e.g. echo-service)를 사용할 때externalTrafficPolicy=Cluster일 때의 동작이 왜 다르게 보이는지를 기술적으로 분석합니다.✅ externalTrafficPolicy 란?Kubernetes 서비스에서 외부로부터 들어온 트래픽을 어떻게 Pod에 전달할 것인지를 결정하는 설정입니다. 설정 값설명Cluster트래픽이 도달한 노드에 파드가 없어도 kube-proxy가 .. 2025. 8. 7.
AWS EKS NGINX Ingress Controller - hostNetwork에 따른 NLB 헬스체크 정상/비정상 분석 다음은 2~3일간 이론상 ingress 에서 동작해야하는 동작이 동작하지 않을때의 오류 해결입니다... AWS EKS 환경에서 ingress-nginx를 Helm으로 배포하고, type: LoadBalancer와 NLB(Network Load Balancer)를 함께 사용하여 외부 트래픽을 수신하도록 구성했습니다. 이때 externalTrafficPolicy: Local을 설정하여 클라이언트 IP를 보존하는 설정을 적용했습니다.하지만 이상한 현상이 발생했습니다:Ingress Controller가 하나의 노드에만 배포되어 있음에도, NLB의 Target Group에서 두 노드 모두 헬스체크가 성공하는 현상 발생.이는 이론적으로 맞지 않습니다. externalTrafficPolicy: Local이라면 Ing.. 2025. 8. 6.
반응형