EC2 Instance Role 실습 메모
인스턴스 내부에서 AWS CLI를 쓸 때 보안을 챙기는 가장 좋은 방법은 IAM Role을 부여하는 것이다.
기존 방식: aws configure를 실행해 Access Key와 Secret Key를 직접 입력한다. 하지만 이건 인스턴스 내부에 자격 증명이 파일로 남아서 보안상 위험하다.
Role 방식: EC2 인스턴스의 Security > Modify IAM Role 메뉴에서 적절한 정책이 담긴 역할을 부여한다.
Before: aws configure 필요
aws configure
aws iam list-users
After: IAM Role 연결 후
이렇게 하면 aws configure를 따로 안 해도 바로 aws iam list-users 같은 명령어가 작동한다. EC2가 부여된 역할을 통해 임시 자격 증명을 자동으로 가져오기 때문이다.
인스턴스 운영할 땐 무조건 IAM Role을 쓰는 게 원칙이다.
비용을 아끼려면 상황에 맞는 구매 방식을 선택해야 한다.
On-Demand Instances: 짧은 작업, 가격 예측 가능, 초 단위 결제. 가장 비싸지만 약정 없이 언제든 쓰고 버릴 수 있다.
Reserved Instances (RI): 1년 또는 3년 약정. 긴 작업에 적합하다.
Convertible Reserved Instances: 나중에 인스턴스 타입을 바꿀 수 있는 유연함이 포함된 약정.
Savings Plans: 일정량의 사용량을 약정하고 할인받는 방식. RI보다 좀 더 유연하다.
Spot Instances: 가장 저렴하지만(최대 90% 할인) AWS가 리소스가 필요하면 인스턴스를 회수해갈 수 있다. (신뢰성은 낮음)
Dedicated Hosts: 물리적 서버 한 대를 통째로 예약. 규제나 라이선스 이슈가 있을 때 쓴다.
Dedicated Instances: 하드웨어를 다른 고객과 공유하지 않는다.
Capacity Reservations: 특정 AZ에 용량을 미리 확보해두는 방식. 인스턴스를 실행하지 않아도 비용이 나간다.
구매 옵션을 리조트에 비유하기 (Resort Analogy)
On-demand: 리조트에 가고 싶을 때 언제든 가서 정가를 내고 묵는 것.
Reserved: 미리 계획을 세우고 장기 투숙을 예약해서 큰 할인을 받는 것.
Savings plans: 특정 기간 동안 시간당 일정 금액을 내기로 하고, 방 타입(킹, 스위트 등)을 유연하게 선택하는 것.
Spot instances: 빈방에 대해 경매(Bid)를 붙이는 것. 가장 높은 금액을 쓴 사람이 방을 차지하지만, 호텔이 필요하면 언제든 쫓겨날 수 있다.
Dedicated Hosts: 리조트 건물 한 동을 통째로 빌리는 것.
Capacity Reservations: 방을 미리 예약해두는 것. 실제로 가서 자든 안 자든 풀 가격을 지불해야 한다.
Public IPv4 과금 이슈
2024년 2월 1일부터 모든 퍼블릭 IPv4 주소에 대해 요금이 부과되기 시작했다.
가격: 시간당 $0.005 (한 달에 약 $3.6 정도).
Free Tier: 신규 계정은 처음 12개월 동안 EC2용 퍼블릭 IP 750시간 무료 제공. 하지만 다른 서비스(RDS 등)는 무료 혜택이 없다.
이유: 전 세계적인 IPv4 고갈 문제로 IPv6 전환을 독려하기 위함이다. 하지만 여전히 많은 곳이 IPv4를 쓰고 있어서 비용이 발생하더라도 쓰는 경우가 많다.
Troubleshooting: 내 계정에서 어디에 돈이 나가는지 보려면 AWS Bill을 보거나, IPAM (IP Address Manager)의 Public IP Insights를 확인하면 된다.
EC2 Spot Instance 상세
비용 절감의 핵심이지만 작동 방식을 정확히 알아야 사고가 안 난다.
작동 원리: 내가 설정한 Max Price보다 현재 Spot Price가 낮으면 인스턴스가 실행된다. 가격이 역전되면 인스턴스가 중단되는데, 이때 2분의 유예 시간(Grace period)이 주어진다.
Spot Block: 1~6시간 동안 끊김 없이 쓰도록 예약하는 방식인데, 정말 희귀한 상황에서는 회수될 수도 있다.
적합한 작업: 배치 작업, 데이터 분석 등 실패해도 다시 실행하면 되는 업무. DB나 중요한 운영 서버에는 절대 쓰면 안 된다.
★ 중요: 스팟 인스턴스 종료 방법 그냥 인스턴스만 종료(Terminate)하면 AWS가 "어? 사용자가 인스턴스를 원한다고 했는데 왜 없지?" 하고 스팟 요청(Spot Request)을 기반으로 새 인스턴스를 다시 띄워버린다.
먼저 Spot Request를 Cancel(취소) 한다. (그래야 AWS가 새로 안 만든다)
그 후에 실행 중인 Spot Instance를 Terminate 한다.
Spot Fleets (스팟 플릿)
비용 절감과 가용성을 동시에 챙기는 똑똑한 방법이다.
개념: 스팟 인스턴스 묶음 + (선택사항) 온디맨드 인스턴스.
장점: 여러 인스턴스 유형(m5.large, c5.large 등)과 여러 가용 영역(AZ)을 런치 풀(Launch Pool)로 정의해두면, 플릿이 알아서 가장 저렴하거나 안정적인 풀에서 인스턴스를 가져온다.
할당 전략 (Allocation Strategies):
lowestPrice: 가장 싼 풀에서 가져옴 (비용 최적화).
diversified: 모든 풀에 골고루 분산 (가용성 향상).
capacityOptimized: 용량이 넉넉한 풀을 우선 선택 (회수될 확률이 적음, 권장 방식).
**Spot vs Spot Fleet 차이점
Spot Instance: 특정 인스턴스 타입 + AZ 지정
Spot Fleet: 여러 인스턴스 타입 + AZ 중 최적 선택
💡 학습 포인트 (Self-Note)
보안 Best Practice
Spot Instance 관리
단순 스팟 요청은 내가 특정 타입과 AZ를 찍어서 요청하는 느낌이라면, 스팟 플릿은 "이런 조건들을 만족하는 것 중에 제일 최적인 걸로 알아서 가져와"라고 뭉텅이로 요청하는 느낌이다.
IPv4 비용이 이제는 무시 못 할 수준이니 안 쓰는 탄력적 IP(EIP)는 바로 반납하고, 퍼블릭 IP가 굳이 필요 없는 인스턴스는 프라이빗 서브넷으로 옮기는 습관을 들여야겠다.