11. 클라우드 제공자 한 곳
한 곳을 깊게 익히면 다른 제공자는 이름만 바꿔 읽을 수 있습니다. 여러 곳을 얕게 보는 것보다 낫습니다.
이름만 다른 것들
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| 가상 서버 | EC2 | Virtual Machines | Compute Engine |
| 객체 저장소 | S3 | Blob Storage | Cloud Storage |
| 관리형 쿠버네티스 | EKS | AKS | GKE |
| 서버리스 함수 | Lambda | Functions | Cloud Functions |
| 관리형 DB | RDS | Database | Cloud SQL |
| 권한 관리 | IAM | Entra ID | IAM |
개념은 거의 같습니다. 고를 때는 기술보다 팀이 이미 쓰는 것, 조직의 계약, 필요한 지역에 리전이 있는지를 봅니다.
책임 범위
제공자가 어디까지 맡는지에 따라 할 일이 달라집니다.
| 직접 챙기는 것 | |
|---|---|
| 가상 서버 | OS 패치, 런타임, 웹 서버, 배포 |
| 컨테이너 서비스 | 이미지와 설정 |
| 서버리스 | 함수 코드와 설정 |
| SaaS | 설정만 |
맡기는 범위가 넓을수록 편하지만 비용이 붙고 제품에 묶이는 정도도 올라갑니다. 처음에는 맡길 수 있는 쪽이 유리하고, 규모가 커지면 직접 운영하는 쪽이 싸지는 지점이 옵니다.
권한
가장 먼저 정리해야 할 부분이고, 가장 자주 방치되는 부분입니다.
- 루트 계정은 초기 설정 후 쓰지 않습니다. MFA를 걸고 봉인합니다
- 사람에게는 사용자 계정, 서비스에는 역할을 줍니다
- 액세스 키를 서버에 두지 않습니다. 인스턴스에 역할을 붙이면 임시 자격 증명을 자동으로 받습니다
- CI는 OIDC로 단기 자격 증명을 받습니다(09. CI/CD)
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::example-uploads/*"
}"Action": "s3:*", "Resource": "*"로 시작해 좁히지 않는 경우가 많습니다. 반대로 갑니다. 필요한 것만 열고 막히면 그때 추가합니다.
네트워크
04. 네트워크와 보안 기초에서 본 내용이 그대로 적용됩니다.
VPC 10.0.0.0/16
├─ 퍼블릭 서브넷 10.0.1.0/24 로드 밸런서, NAT 게이트웨이
└─ 프라이빗 서브넷 10.0.10.0/24 애플리케이션, 데이터베이스데이터베이스를 퍼블릭 서브넷에 두고 보안 그룹으로만 막아 두는 구성을 자주 봅니다. 규칙 하나를 잘못 고치면 바로 인터넷에 노출됩니다. 경로 자체를 만들지 않는 편이 안전합니다.
가용 영역을 두 개 이상 씁니다. 한 영역의 장애로 서비스가 멈추지 않게 하는 가장 기본적인 조치입니다.
가상 서버와 오토스케일링
인스턴스를 길들이지 않습니다. 접속해서 손으로 고친 서버는 다시 만들 수 없습니다.
이미지를 만든다 → 그 이미지로 띄운다 → 고칠 일이 생기면 이미지를 다시 만든다오토스케일링은 부하에 따라 대수를 조절합니다. 주의할 점은 늘어나는 속도입니다. 인스턴스가 뜨고 준비되기까지 수 분이 걸리면 갑작스러운 트래픽에는 늦습니다. 이미지에 미리 구워 두고 시작 스크립트를 줄입니다.
관리형 데이터베이스
직접 운영하는 것보다 비싸지만, 백업·패치·장애 복구를 대신해 줍니다. 그 값을 사람 시간으로 환산하면 대체로 이쪽이 쌉니다.
확인할 항목입니다.
- 자동 백업과 복구 시점 지정이 켜져 있는가
- 다중 AZ로 떠 있는가
- 삭제 방지가 걸려 있는가
- 유지 보수 시간대가 트래픽이 적은 때인가
복구를 실제로 해 봅니다. 백업이 돌고 있다는 것과 복구가 된다는 것은 다릅니다.
객체 저장소
이미지, 백업, 정적 파일을 둡니다. 값이 싸고 용량 제한이 사실상 없습니다.
공개 설정이 사고로 이어지는 단골입니다. 버킷 전체를 공개로 열지 말고, 필요한 파일만 서명된 URL로 내보냅니다.
수명 주기 규칙으로 비용을 줄입니다.
30일 지난 객체 → 저빈도 접근 계층
90일 지난 객체 → 아카이브 계층
365일 지난 객체 → 삭제서버리스
서버를 띄워 두지 않고 요청이 올 때만 실행합니다.
| 맞는 자리 | 맞지 않는 자리 |
|---|---|
| 가끔 도는 배치, 웹훅 수신 | 상시 트래픽이 많은 API |
| 이미지 썸네일 생성 | 긴 작업 (실행 시간 제한) |
| 이벤트 처리 | 응답 지연에 민감한 경로 |
한동안 호출이 없으면 다음 요청이 느려집니다(콜드 스타트). 상시 트래픽이 있으면 컨테이너를 띄워 두는 쪽이 싸고 빠른 구간이 생깁니다.
데이터베이스 커넥션도 주의합니다. 함수가 수백 개 동시에 뜨면 커넥션 수를 그만큼 요구해 DB가 먼저 막힙니다. 프록시를 두거나 HTTP 기반 드라이버를 씁니다.
비용
쓰지 않는 자원이 조용히 과금됩니다.
- 떠 있는 인스턴스, 붙어 있지 않은 디스크와 고정 IP
- 쓰지 않는 로드 밸런서, NAT 게이트웨이
- 리전 간·인터넷으로 나가는 데이터 전송 요금
전송 요금이 특히 눈에 잘 띄지 않습니다. 같은 리전 안에서 통신하도록 배치하고, 바깥으로 나가는 트래픽은 CDN으로 줄입니다.
처음부터 해 둘 것은 두 가지입니다.
- 태그 규칙을 정합니다. 환경·서비스·소유자를 붙여야 청구서를 쪼개 볼 수 있습니다
- 예산 알림을 겁니다. 월말에 알면 늦습니다
실수로 큰 인스턴스를 띄워 두는 일은 누구나 겪습니다. 알림이 있으면 하루 만에 끝나고, 없으면 한 달치가 청구됩니다.