백엔드 › 클라우드·네트워크
새벽에 스팟 인스턴스가 꺼지면 어떡하나 걱정했다 — EC2 사이징부터 구매옵션까지
지난 포스트에서 리전이랑 가용영역, 엣지로케이션까지 배웠다. “서버를 어디에 둘 것인가”까지는 감이 잡혔는데, 정작 그 자리에 올라가는 서버 자체는 하나도 모르고 있었다.
멘토님이 주신 자료로 EC2를 파고들었는데, 처음엔 “그냥 서버 켜는 서비스 아니야?” 싶었다. 근데 콘솔 한 번 켜보려고 하니까 고를 게 너무 많았다. 사이즈는 뭘로 할지, OS는 뭘 깔지, 결제는 어떻게 할지… 이 글은 그 과정을 정리한 거다.
EC2는 서버 하나가 아니라 서비스 묶음이었다
EC2란 무엇인가 — 서버를 사는 대신 몇 분만 빌려쓴다
회사에 서버가 급하게 필요해졌다고 생각해보자. 원래대로면 컴퓨터를 주문하고, 배송을 기다리고, 전산실에 설치하고, 전원이랑 네트워크까지 연결해야 한다. 짧아도 며칠, 길면 몇 주가 걸리는 일이다.
근데 EC2는 이 과정을 통째로 없애버렸다. 콘솔에서 몇 번 클릭하면 몇 분 안에 컴퓨터 한 대가 인터넷 저편에서 켜진다. 다 쓰고 나면 그냥 꺼버리면 된다. 렌터카 빌리는 거랑 똑같은 원리다.
EC2(Elastic Compute Cloud)는 AWS가 미리 준비해둔 가상 서버를 시간 단위, 심지어 초 단위로 빌려주는 서비스다. 이름에 붙은 Elastic이라는 단어가 핵심인데, 필요하면 늘리고 필요 없으면 바로 줄일 수 있다는 뜻이다. 물리 서버였으면 스펙 바꾸려고 부품을 새로 사야 하는데, EC2는 껐다가 인스턴스 타입만 바꾸고 다시 켜면 끝난다.
여기서 하나 헷갈렸던 게, 인스턴스를 “중지(stop)”해도 과금이 완전히 멈추는 게 아니라는 점이다. 인스턴스 자체 사용료는 안 나가는데, 거기 붙어있던 EBS 볼륨은 인스턴스가 꺼져 있어도 계속 과금된다. 이거 모르고 있었으면 나중에 “왜 다 껐는데 요금이 나오지” 하고 당황했을 것 같다.
EC2 혼자 일하지 않는다 — EBS·ELB·ASG 패밀리
EC2를 배우면서 제일 신기했던 부분이 여기다. EC2는 혼자 일하는 서비스가 아니라, 항상 세 가지 동료(?)와 세트로 붙어다닌다.
서버 한 대만 켜놓은 상황을 생각해보자. 손님이 10명일 땐 잘 돌아가는데, 갑자기 손님이 1000명으로 늘면 그 서버 한 대로는 감당이 안 된다. 그럼 서버를 여러 대 켜야 하는데, 이번엔 손님을 어느 서버로 보낼지 정해주는 애가 필요하다. 그리고 서버를 껐다 켤 때마다 데이터가 날아가면 곤란하니까 따로 보관해주는 창고도 필요하다. 마지막으로 새벽에 손님이 없는데 서버 20대를 계속 켜두면 돈만 나가니까, 손님 수에 맞춰 서버 대수를 알아서 조절해주는 관리자도 있으면 좋겠다.
이 네 가지 역할이 각각 실제 서비스 이름을 갖고 있다.
1
2
3
4
5
6
EC2 (Elastic Compute Cloud, 연산을 담당하는 가상 서버 본체)
└─ EBS (Elastic Block Store, 인스턴스를 꺼도 데이터가 남는 네트워크 디스크)
여러 대의 EC2
└─ ELB (Elastic Load Balancing, 트래픽을 여러 EC2에 고르게 나눠주는 로드밸런서)
└─ ASG (Auto Scaling Group, 트래픽에 맞춰 EC2 인스턴스 개수를 자동으로 늘리고 줄이는 관리자)
동작 흐름은 이렇다. 사용자 요청이 들어오면 ELB가 여러 EC2 인스턴스 중 하나로 트래픽을 분배한다. 트래픽이 몰리면 ASG가 정해둔 규칙(예: CPU 사용률 70% 초과)에 따라 EC2 인스턴스를 자동으로 추가한다. 각 EC2 인스턴스에 붙은 EBS는 인스턴스가 재시작되거나 교체돼도 데이터를 그대로 유지한다.
왜 이렇게 설계했을까 생각해봤는데, 서버 한 대에 모든 걸 몰아넣으면 그 서버가 죽는 순간 서비스 전체가 죽는다(단일 장애점). EC2+EBS+ELB+ASG 조합은 서버를 여러 대로 쪼개고, 죽은 서버는 자동으로 새 서버로 교체하는 구조를 만들어준다. 처음엔 “왜 서비스가 4개나 나뉘어 있지” 싶었는데, 이유를 알고 나니까 오히려 하나로 뭉쳐놓는 게 더 이상했을 것 같다.
EC2 혼자가 아니라 EBS(저장)·ELB(분산)·ASG(자동조절)가 항상 세트로 붙어다닌다
인스턴스도 옷처럼 사이즈가 있었다
t3.micro라는 이름 뜯어보기
콘솔에서 인스턴스를 만들려고 하니까 t3.micro, m5.large, c5n.xlarge 같은 알쏭달쏭한 이름들이 쭉 나왔다. 처음엔 그냥 외워야 하나 싶었는데, 알고 보니 이름 자체에 규칙이 있었다.
옷 사이즈 고르는 거랑 비슷하다고 생각하면 편하다. 몸에 비해 너무 작은 옷을 사면 불편하고, 너무 큰 옷을 사면 돈과 공간이 아깝다. 서버도 똑같다. 하루 손님 10명인 홈페이지에 큰 서버를 켜두면 대부분 놀고 있는 셈이고, 반대로 손님이 몰리는 서비스에 작은 서버를 켜두면 버벅거리다가 멈춘다.
AWS 공식 문서를 찾아보니까 명명 규칙이 [패밀리][세대][프로세서 옵션][추가 기능].[크기] 순서로 되어 있었다. t3.micro로 예를 들면:
1
2
3
4
t3.micro
│ │ └─ 크기 (nano < micro < small < medium < large < xlarge ...)
│ └─── 세대 (숫자가 클수록 최신 하드웨어)
└───── 패밀리 (용도)
여기서 재밌었던 건 패밀리 뒤에 붙는 추가 문자였다. t3a.micro처럼 a가 붙으면 AMD 프로세서를 쓴다는 뜻이고(보통 인텔보다 살짝 저렴하다), m6g.large처럼 g가 붙으면 AWS가 자체 설계한 ARM 기반 Graviton 칩을 쓴다는 뜻이다. c5n.xlarge의 n은 네트워크 성능이 강화된 버전이라는 뜻이고. 이런 접미사까지 다 규칙이 있다는 걸 알고 나니까, 처음엔 암호처럼 보이던 이름들이 조금씩 읽히기 시작했다.
주요 패밀리는 이렇게 나뉜다:
| 패밀리 | 특화 | 용도 |
|---|---|---|
| t 계열 | 범용, 버스트형 | 저렴하고 평소 부하가 낮은 서비스 |
| c 계열 | CPU 최적화 | 연산이 많은 워크로드(인코딩 등) |
| r 계열 | 메모리 최적화 | 대용량 데이터 처리 |
| g 계열 | GPU 탑재 | 머신러닝, 그래픽 처리 |
t 계열은 “버스트형”이라는 게 특이했는데, 평소엔 낮은 성능으로 돌다가 순간적으로 크레딧을 소모해서 성능이 확 올라가는 방식이다. 근데 크레딧을 다 쓰면 성능이 기본 성능으로 뚝 떨어진다고 한다. 트래픽이 꾸준히 높은 서비스에 t 계열을 썼다가는 어느 순간 갑자기 느려지는 원인이 될 수 있다는 걸 배웠다. 나중에 서비스 운영할 때 t 계열 쓸 거면 이 부분은 꼭 CloudWatch로 크레딧 잔량을 모니터링해야겠다고 메모해뒀다.
패밀리 + 세대 + (프로세서 옵션) + 크기, 이 순서로 이름이 지어진다
인스턴스 만들 때 채워야 하는 4가지 (OS·스토리지·보안그룹·부트스트랩)
사이즈만 정한다고 바로 서버를 쓸 수 있는 게 아니었다. 새 컴퓨터를 산 것과 비슷한데, 운영체제를 깔고, 저장 공간을 붙이고, 문단속(방화벽)을 하고, 필요한 프로그램까지 설치해야 진짜로 쓸 수 있는 서버가 된다.
콘솔에서 인스턴스를 시작할 때 실제로 정하는 순서는 이렇다.
1
2
3
4
1. OS 선택 → AMI(Amazon Machine Image)를 고른다
2. 스토리지 설정 → EBS 볼륨 크기·타입 지정
3. 보안그룹 설정 → 인바운드/아웃바운드 규칙 (예: 80/443 포트만 개방)
4. 부트스트랩 → User Data에 셸 스크립트를 넣어 최초 부팅 시 자동 실행
이 중에서 부트스트랩(User Data)이 제일 신선했다. 인스턴스가 처음 켜질 때 자동으로 실행되는 스크립트를 미리 넣어둘 수 있다는 건데, 실제로 아래처럼 작성할 수 있다.
1
2
3
4
5
#!/bin/bash
# 인스턴스가 처음 켜질 때 딱 한 번만 실행되는 스크립트
yum update -y # 패키지 목록 최신화
yum install -y nginx # 웹서버 설치
systemctl start nginx # nginx 실행
이 스크립트를 인스턴스 생성 시 미리 넣어두면, 서버 100대를 켜도 100대 모두 똑같은 상태로 자동 세팅된다는 게 핵심이다. 사람이 일일이 접속해서 설치할 필요가 없다는 뜻이니까, 나중에 ASG랑 엮이면 왜 이게 중요한지 바로 이해가 됐다.
보안그룹은 인스턴스 단위로 붙는 방화벽인데, “차단 규칙”이 아니라 “허용 규칙”만 쓸 수 있다는 게 특징이었다. 기본은 전부 막혀있고, 필요한 포트만 하나씩 열어주는 화이트리스트 방식이다. 이건 오히려 직관적이어서 이해하는 데 오래 안 걸렸다.
사이즈를 정한 다음, 이 네 가지를 채워야 실제로 쓸 수 있는 서버가 된다
AMI, 서버의 설치 완료 상태를 통째로 복제하기
AMI가 정확히 뭐길래
위에서 “OS 선택 → AMI를 고른다”라고 짧게 넘어갔는데, 이 AMI라는 게 뭔지 좀 더 파봤다.
휴대폰을 새로 살 때를 생각해보면 이해가 빠르다. 예전 폰에 깔아둔 앱, 설정, 사진을 하나하나 다시 세팅하려면 몇 시간이 걸린다. 근데 백업본이 있으면 복원 버튼 하나로 그대로 새 폰에 옮길 수 있다. 몇 분 만에 예전 폰이랑 완전히 똑같은 상태가 되는 거다.
AMI(Amazon Machine Image)는 EC2 인스턴스를 실행하는 데 필요한 정보(OS, 설치된 소프트웨어, 설정, 권한)를 통째로 담은 템플릿이다. OS를 깔고 필요한 프로그램을 설치하고 설정을 끝낸 서버를 “사진”으로 찍어두면, 그 사진으로 몇 초 만에 똑같은 서버를 몇 대든 복제할 수 있다.
인스턴스를 시작할 때 실제 흐름은 이렇다.
1
2
3
4
5
AMI를 고른다
↓
AWS가 그 AMI의 스냅샷을 기반으로 새 EBS 볼륨을 만든다
↓
그 볼륨을 붙인 새 EC2 인스턴스가 부팅된다
여기서 헷갈리기 쉬운 부분이, AMI 자체가 실행되는 게 아니라 AMI를 “원본”으로 삼아 매번 새 복사본이 만들어지는 구조라는 거다. 만약 AMI 하나를 여러 인스턴스가 공유해서 쓰는 구조였다면, 인스턴스 하나가 파일을 수정할 때마다 다른 인스턴스에도 영향을 줬을 거다. AMI를 원본 템플릿으로 두고 매번 복사본을 만드는 방식이라, 인스턴스끼리 서로 독립적으로 동작할 수 있다.
그리고 AMI는 리전 단위로 존재한다는 것도 알게 됐다. 서울 리전에서 만든 내 AMI를 도쿄 리전에서 쓰려면 별도로 “AMI 복사(Copy AMI)”를 해줘야 한다. 리전마다 데이터센터가 물리적으로 완전히 분리돼 있다는 걸 앞선 포스트에서 배웠던 게 여기서 다시 연결됐다.
AMI는 실행되는 게 아니라, 매번 새 복사본을 만드는 원본 템플릿이다
AMI 3갈래 — Public / Own / Marketplace
AMI를 어디서 가져오느냐에 따라 세 갈래로 나뉜다는 것도 배웠다. 새 집에 들어갈 가구를 마련하는 상황에 비유하면, 관리사무소 기본 가구를 그냥 쓸 건지, 예전 집에서 쓰던 내 가구를 그대로 옮겨올 건지, 가구점 완제품 세트를 살 건지의 차이다.
| 종류 | 제공자 | 상태 | 비용 |
|---|---|---|---|
| Public AMI | AWS 또는 커뮤니티 | 순수 OS만 설치 | 무료 (인스턴스 사용료만) |
| Own AMI | 나 자신 | 내가 설정 끝낸 걸 스냅샷 저장 | EBS 스냅샷 저장 비용만 |
| Marketplace AMI | 써드파티 벤더 | OS + 상용 소프트웨어 사전 설치 | 인스턴스 사용료 + 라이선스 비용 |
실무에서 가장 흔한 패턴은 Public AMI로 시작해서, 필요한 설정을 끝낸 뒤 Own AMI로 저장하고, 그 Own AMI를 ASG의 시작 템플릿(Launch Template)에 등록해서 자동 확장 시 계속 재사용하는 흐름이라고 한다.
이 부분을 배우다가 “자동 확장 시 계속 재사용한다는 게 오토스케일링 수평적 확장할 때를 말하는 거냐”고 직접 물어봤었다. 답을 듣고 나니 흐름이 명확해졌다. ASG가 트래픽 증가를 감지하면 시작 템플릿에 등록된 AMI를 기준으로 새 인스턴스를 추가하는데, 이때 Public AMI(순수 OS)를 등록해뒀으면 새로 늘어난 인스턴스는 nginx도 안 깔린 빈 서버로 뜬다. 그래서 “설정 다 끝낸 상태”인 Own AMI를 만들어서 등록해두는 게 실무 패턴이라는 걸 알게 됐다. 수직적 확장(서버 사양 자체를 키우는 것)이랑 헷갈리지 않게 이 부분은 따로 메모해뒀다.
Marketplace AMI는 인스턴스 사용료 외에 소프트웨어 라이선스 비용이 시간당 별도로 붙는다는 것도 주의할 점이었다. 견적 낼 때 이 비용을 빠뜨리기 쉽다고 하니, 나중에 실제로 견적 뽑을 일 있으면 꼭 체크해야겠다.
출처에 따라 무료 기본형, 내가 만든 것, 유료 완제품으로 나뉜다
서버도 결제 방식이 다르다 — EC2 구매 옵션 네 가지
같은 사양의 서버라도 결제 방식에 따라 가격이 최대 90%까지 차이난다는 걸 알고 좀 놀랐다. 비행기표 끊는 상황이랑 비슷하다. 정가 티켓, 미리 예매한 할인 티켓, 언제 취소될지 모르는 초특가 좌석 중에서 상황에 맞게 고르는 거다.
온디맨드 vs 예약 인스턴스
온디맨드는 그때그때 정가로 쓰는 방식이고, 예약 인스턴스는 미리 오래 쓰겠다고 약속하고 할인받는 방식이다.
| 온디맨드 | 예약 인스턴스 | |
|---|---|---|
| 과금 단위 | 초 단위 (최소 60초) | 1년/3년 약정 |
| 약정 | 없음 | 전액/일부/무선결제 선택 |
| 할인율 | 정가 (기준선) | 최대 72% (3년+전액선결제 기준) |
| 적합한 상황 | 트래픽 예측 어려운 신규 서비스 | 24시간 항상 켜진 DB, 백엔드 서버 |
찾아보니 AWS 공식 자료 기준으로는 온디맨드가 예약 인스턴스나 스팟 인스턴스 대비 최대 2~5배 비쌀 수 있다고 한다. 결제 방식 하나 바꾸는 것만으로 이 정도 차이가 난다는 게 신기했다.
예약 인스턴스가 “특정 물리 서버를 예약하는 게 아니라 할인 계약”이라는 것도 새로 안 사실이다. 인스턴스 타입과 리전만 맞으면, 실제로 그 스펙의 인스턴스를 실행할 때 자동으로 할인이 적용되는 구조다. AWS 입장에서는 “이 손님이 최소 1년은 이 자원을 쓸 것”이라는 확실성을 얻는 대가로 할인을 주는 거고, 사용자 입장에서는 유연성을 포기하고 비용을 아끼는 선택이다.
대신 예약 인스턴스를 약정했는데 나중에 트래픽이 줄어서 그 스펙이 필요 없어져도, 남은 약정 기간 동안 비용이 계속 청구된다고 한다. 예측이 확실한 워크로드에만 써야 한다는 걸 배웠다.
약정 없이 정가로 쓸지, 1~3년 약정하고 최대 72% 할인받을지
스팟 인스턴스 vs 전용 호스트 — 그리고 새벽에 걱정했던 것
이 둘은 완전히 반대 성격의 옵션이다. 스팟은 AWS가 남는 자원을 싸게 파는 거고, 전용 호스트는 물리 서버 한 대를 통째로 빌리는 거다.
스팟 인스턴스는 항공사 초특가 좌석이랑 비슷하다. 출발 직전까지 안 팔린 좌석을 엄청 싸게 풀되, 다른 승객이 정가로 그 자리를 사면 취소될 수도 있다. 대신 온디맨드 대비 최대 90%까지 저렴하다. 전용 호스트는 정반대로, 물리 서버를 아예 독점해서 다른 고객과 절대 섞이지 않는다. 대신 구매 옵션 중 가장 비싸다.
여기서 회수될 때 “2분 전 경고를 준다”는 부분을 배우다가, 문득 이런 생각이 들었다. “새벽 시간대에 스팟 인스턴스가 회수되면 아무도 안 보고 있을 텐데 그럼 대응이 안 되는 거 아닌가?” 싶어서 바로 물어봤다.
답은 명확했다. 이 2분은 사람이 반응하라고 주는 시간이 아니라, 코드가 자동으로 반응하도록 만들어진 시간이었다. 인스턴스 안에서 도는 프로그램이 아래 메타데이터 주소를 주기적으로 확인(polling)하다가, 회수가 결정되면 응답이 바뀌는 걸 감지해서 알아서 대응하는 구조다.
1
http://169.254.169.254/latest/meta-data/spot/instance-action
평소엔 “정보 없음”으로 응답하다가, 회수가 결정되는 순간 “2분 뒤 종료됨”으로 바뀐다. 프로그램이 이걸 감지하면 진행 중이던 작업을 S3 같은 곳에 저장(체크포인트)하고 안전하게 종료한다. 실무에서는 이런 그레이스풀 셧다운 로직을 미리 넣어두거나, Spot Fleet·AWS Batch·EKS 스팟 노드그룹처럼 인스턴스 하나가 죽어도 자동으로 작업을 다른 인스턴스에 재배정해주는 서비스를 쓴다고 한다.
그러니까 스팟 인스턴스를 쓰는 워크로드는 애초에 “언제 죽어도 괜찮게” 설계하는 게 핵심이었다. Netflix가 영상 인코딩 서버를 스팟 인스턴스로 대량 실행해서 비용을 크게 아낀다는 사례도 봤는데, 인코딩 작업이 중간에 끊겨도 이어서 재개할 수 있게 미리 설계했기 때문에 가능한 거였다. 사람이 밤새 지키고 있는 게 아니라 시스템이 알아서 이어받는다는 걸 알고 나니 걱정이 좀 풀렸다.
전용 호스트는 소켓/코어 단위로 라이선스 비용이 매겨지는 상용 소프트웨어(Windows Server, Oracle DB 등)를 쓸 때 필요하다고 한다. 물리 서버를 단독 점유해야 라이선스 정책을 지킬 수 있는 경우다.
최대 90% 할인이지만 회수될 수 있는 스팟, 가장 비싸지만 완전히 격리된 전용 호스트
EC2에 붙는 저장 장치, 종류가 왜 이렇게 많나
3-2단계에서 EBS를 잠깐 언급했었는데, EC2 스토리지가 EBS 하나가 아니라 네 종류나 된다는 걸 마지막에 알게 됐다.
EBS vs EC2 Instance Store
이 둘은 둘 다 “인스턴스 한 대에 붙는 전용 저장소”라는 공통점이 있지만 성격이 반대다. 서랍이랑 메모지 비유가 딱 맞았다. 서랍(EBS)은 책상(인스턴스)이 바뀌어도 서랍째 새 책상에 옮겨 달면 내용물이 그대로다. 메모지(Instance Store)는 책상 표면에 직접 낙서한 거라서, 책상을 바꾸면 낙서가 사라진다. 대신 메모지는 서랍보다 훨씬 빨리 꺼내 쓸 수 있다.
| EBS | EC2 Instance Store | |
|---|---|---|
| 연결 방식 | 네트워크 스토리지 | 물리 서버 직결 |
| 데이터 지속성 | 인스턴스 종료 후에도 유지 | 인스턴스 중지·종료 시 소멸 |
| 속도 | Instance Store보다 느림 | 매우 빠름(로컬 디스크) |
| 특징 | 다른 인스턴스에 재연결 가능, 스냅샷 백업 가능 | 특정 인스턴스 타입에만 딸려나옴 |
EBS 볼륨은 인스턴스와 완전히 독립된 리소스라서, EC2 인스턴스가 죽어도 그 EBS 볼륨만 따로 살아남아 다른 인스턴스에 다시 연결할 수 있다. Instance Store는 인스턴스가 도는 물리 하드웨어의 일부라서, 인스턴스가 사라지면 물리적으로도 접근할 방법이 없어진다.
Instance Store는 EBS와 달리 인스턴스 시작 시점에 함께 붙여야 하고 나중에 추가로 붙일 수 없다는 점도 배웠다. DB 데이터처럼 잃으면 안 되는 걸 실수로 Instance Store에 저장하는 게 흔한 사고 패턴이라고 하니, 캐시나 임시 버퍼처럼 날아가도 괜찮은 데이터에만 써야겠다고 마음에 새겼다.
영구 보관되는 네트워크 디스크 EBS, 인스턴스와 함께 사라지는 초고속 로컬 디스크 Instance Store
EFS vs FSx
여기까지는 인스턴스 한 대 전용 저장소였다면, EFS랑 FSx는 여러 인스턴스가 동시에 접근하는 공유 저장소다.
EFS(Elastic File System)는 여러 EC2 인스턴스가 동시에 마운트해 쓰는 NFS 기반 관리형 파일 시스템이고, FSx는 Windows나 고성능 컴퓨팅처럼 특정 파일시스템 프로토콜이 필요한 워크로드를 위한 관리형 스토리지다.
1
2
3
4
5
6
7
8
9
EFS
- 프로토콜: NFS (리눅스 계열 표준 공유 파일시스템)
- 동시 접근: 여러 EC2가 같은 파일 시스템을 동시에 마운트
- 확장성: 용량이 자동으로 늘고 줌
FSx
- FSx for Windows File Server: SMB 프로토콜, 윈도우 서버 환경 파일 공유
- FSx for Lustre: 고성능 컴퓨팅, 머신러닝 학습 등 초고속 병렬 처리용
- FSx for NetApp ONTAP / OpenZFS: 특정 벤더 파일시스템 기능 그대로 사용
EFS는 여러 EC2가 각자 mount 명령으로 같은 파일 시스템 경로를 연결해서, 한 인스턴스가 파일을 쓰면 다른 인스턴스에서도 바로 그 파일이 보인다. 이게 EBS와의 결정적 차이였다. EBS는 한 번에 하나의 인스턴스에만 연결되지만, EFS·FSx는 여러 인스턴스가 동시에 붙을 수 있다.
EFS 하나로 안 끝내고 FSx까지 따로 만든 이유도 납득이 갔다. 온프레미스에서 Windows 서버나 HPC 환경을 쓰던 기업이 AWS로 이전할 때, 기존에 쓰던 프로토콜(SMB, Lustre)을 그대로 유지해야 재구축 비용이 안 든다. EFS(NFS 전용)만으로는 이런 요구를 충족 못 해서 FSx가 별도로 존재하는 거다.
그리고 EFS는 리눅스 인스턴스에서만 기본 지원된다는 것도 체크해뒀다. Windows 인스턴스에서 공유 파일 시스템이 필요하면 EFS가 아니라 FSx for Windows File Server를 써야 한다.
여러 EC2가 공유하는 저장소지만, 프로토콜과 용도가 완전히 다르다
마무리
EC2 하나 배우는데 생각보다 챙길 게 많았다. 서버 켜는 게 끝이 아니라 사이즈, AMI, 결제 방식, 스토리지까지 다 결정해야 진짜 서비스를 올릴 수 있다는 걸 알았다.
제일 인상 깊었던 건 스팟 인스턴스 회수 2분 알림 부분이었다. 처음엔 “사람이 새벽에 어떻게 대응하지”라고 순진하게 생각했는데, 애초에 사람이 아니라 코드가 대응하도록 설계하는 거라는 걸 알고 나니 클라우드 서비스를 설계할 때의 관점 자체가 다르다는 걸 느꼈다. “언제 죽어도 괜찮게” 만드는 게 핵심이라는 말이 계속 기억에 남는다.
다음 포스트는 S3(오브젝트 스토리지)로 넘어간다. EC2에 붙는 EBS·EFS·FSx까지 배웠으니, 이제 인스턴스 없이도 쓸 수 있는 스토리지가 뭔지 궁금해졌다.