네트워크·운영·요금

VPC는 논리적으로 분리된, 자신이 정의한 가상 네트워크 안에 AWS 리소스를 시작할 수 있는 서비스로, 자사 데이터센터의 전통적인 네트워크와 매우 비슷한 구성을 AWS 위에 만들 수 있다. 콘텐츠를 에지 로케이션에서 전달하는 것은 CloudFront, 도메인 등록과 DNS 라우팅, 헬스 체크를 제공하는 것은 Route 53, 경로상의 ISP를 우회해 전용 연결을 여는 것은 Direct Connect이다.

서브넷은 VPC 내 IP 주소 범위로, 반드시 단일 가용 영역에 속한다. 따라서 서브넷은 AZ를 넘나들 수 없고, 여러 AZ에 분산시키려면 AZ마다 서브넷을 만들어야 한다. 통신의 향할 곳을 정하는 것은 라우팅 테이블, 인터넷으로의 출입구는 인터넷 게이트웨이로, 둘 다 서브넷과는 별개의 부품이다.

라우팅 테이블은 서브넷이나 게이트웨이로부터의 트래픽이 향할 곳을 정하는 표이다. IP 주소 범위를 잘라내는 것은 서브넷, 인터넷으로의 연결을 제공하는 것은 인터넷 게이트웨이, 프라이빗 IP를 가진 리소스의 외부 통신을 대리하는 것은 NAT 게이트웨이이다. 4개의 부품은 각각 역할이 겹치지 않는다.

NAT 게이트웨이는 프라이빗 IP 주소를 가진 리소스가 프라이빗한 상태 그대로 인터넷에 접근할 수 있게 하는 구조이다. 내부에서 외부로의 통신을 대리할 뿐이므로 외부에서 들어오는 연결은 성립하지 않는다. 인터넷 게이트웨이는 VPC 자체를 인터넷에 연결하는 것으로, 서브넷 안에 두는 부품이 아니다. Direct Connect는 사내 네트워크와의 전용 연결, CloudFront는 콘텐츠 전송으로, 어느 것도 이 용도에는 쓰지 않는다.

Route 53은 가용성과 확장성이 뛰어난 DNS 웹 서비스로, 도메인 등록, DNS 라우팅, 헬스 체크의 3가지 기능을 가지며 이들을 임의로 조합해 사용할 수 있다. 콘텐츠 전송을 담당하는 것은 CloudFront, 수신 트래픽의 부하 분산을 담당하는 것은 Elastic Load Balancing이며 Route 53의 기능이 아니다.

CloudFront는 정적 및 동적 웹 콘텐츠의 전송을 빠르게 하는 CDN이다. 정적 파일만 전달하는 구조라고 오해하기 쉽지만, 공식 설명에는 동적 콘텐츠도 대상에 포함되어 있다. 전송은 에지 로케이션이라 불리는 전 세계 규모의 데이터센터 네트워크를 통해 이루어지며, 가장 지연이 낮은 로케이션에서 전달된다. 사내 네트워크와의 전용 연결을 다루는 것은 Direct Connect이며 CloudFront의 역할이 아니다.

Direct Connect는 사내 네트워크와 Direct Connect 로케이션을 표준 이더넷 광섬유 케이블로 연결하여, 네트워크 경로상의 ISP를 우회하고 AWS 서비스로의 가상 인터페이스를 직접 만드는 서비스이다. 인터넷을 거치지 않는 전용 연결이라는 점이 핵심이며, 인터넷상에 암호화 터널을 여는 방식과는 이 부분이 다르다.

라우팅 테이블은 서브넷이나 게이트웨이로부터의 트래픽이 향할 곳을 정하는 표이다. 인터넷 게이트웨이로의 경로를 가진 서브넷이 관용적으로 퍼블릭 서브넷, 가지지 않은 것이 프라이빗 서브넷이라 불린다. 서브넷은 반드시 단일 AZ에 속하므로 AZ의 수로는 구분되지 않는다. 프라이빗 서브넷의 리소스가 외부로 나갈 때는 NAT 게이트웨이를 경유한다.

오리진은 CloudFront가 전송하는 콘텐츠의 원본을 보관하는 장소로, S3 버킷이나 HTTP 서버 등이 해당한다. 에지 로케이션에 원하는 콘텐츠가 없을 때 CloudFront는 오리진에서 가져와 전송한다. 이용자와 가장 가까운 곳에서 콘텐츠를 반환하는 것은 에지 로케이션, 에지 로케이션과 콘텐츠 원본 사이에 놓이는 중간 캐시 계층은 리전별 엣지 캐시, 이름 조회에 응답하여 전송처로 안내하는 것은 Route 53의 DNS 라우팅이다.

Route 53은 도메인 등록, DNS 라우팅, 헬스 체크의 3가지 기능을 임의로 조합해 사용할 수 있는 DNS 웹 서비스이다. 3가지가 모두 갖춰져야만 동작하는 관계가 아니므로, 도메인을 다른 업체에서 취득한 채로 DNS 라우팅만 맡기는 것도, 헬스 체크만 사용하는 것도 가능하다. 이전은 이용의 전제 조건이 아니다.

ALB는 레이어 7, 즉 애플리케이션 계층에서 동작하며 HTTP, HTTPS, gRPC를 다룬다. 여기까지 보므로 HTTP의 내용을 판단 재료로 삼을 수 있고, 콘텐츠 기반 라우팅 같은 유연한 분산이 가능하다. 레이어 4에서 동작하는 것은 NLB(TCP, UDP, TLS), 레이어 3과 4에서 동작하는 것은 Gateway Load Balancer(IP)이다.

NLB는 레이어 4의 로드 밸런서로 TCP, UDP, TLS를 다룬다. 매우 높은 성능과 고정 IP 주소가 필요한 경우에 선택한다. HTTP, HTTPS, gRPC를 다루는 것은 레이어 7의 ALB이며, IP를 다루어 흐름을 종단하지 않고 투과적으로 통과시키는 것이 Gateway Load Balancer이다. gRPC는 NLB의 대응표에 실려 있지 않다.

GWLB는 레이어 3과 4에서 동작하며 다루는 프로토콜은 IP이다. 어플라이언스형 보안 기능이나 네트워크 기능을 경로상에 배치하기 위한 구조로, 흐름을 종단하지 않고 투과적으로 통과시키는 점이 다른 2개와 결정적으로 다르다. HTTP 내용을 보고 분산하는 것은 레이어 7의 ALB, 고정 IP와 UDP는 레이어 4의 NLB의 특기이다.

고정 IP 주소가 필요한 경우에는 NLB를 선택한다. NLB는 레이어 4에서 동작하며 매우 높은 성능과 고정 IP가 요구되는 장면에 적합하다고 공식적으로 자리매김되어 있다. ALB는 레이어 7에서 HTTP, HTTPS, gRPC를 다루며 내용 기반 분산이 특기이다. GWLB는 어플라이언스를 투과적으로 끼워 넣기 위한 것이다. Classic Load Balancer는 TCP, SSL/TLS, HTTP, HTTPS에 대응하는 오래된 세대이다.

ELB는 1개 이상의 가용 영역에 있는 여러 대상에게 수신되는 애플리케이션 트래픽을 자동으로 분산한다. 단일 AZ에 국한되지 않고 여러 AZ로 나눈 대상에게 분산할 수 있는 것이 가용성 설계의 토대가 된다. 도메인명 등록은 Route 53, 에지 로케이션에서의 전송은 CloudFront의 역할이다.

ALB가 다루는 프로토콜은 HTTP, HTTPS, gRPC이며 동작하는 것은 레이어 7이다. gRPC를 직접 다룰 수 있는 것은 이 중에서 ALB뿐이다. NLB는 TCP, UDP, TLS를 다루는 레이어 4, GWLB는 IP를 다루는 레이어 3과 4의 로드 밸런서이다. Classic Load Balancer가 대응하는 것은 TCP, SSL/TLS, HTTP, HTTPS이다.

NLB는 TCP, UDP, TLS를 다루는 레이어 4의 로드 밸런서이므로 UDP 통신을 분산할 수 있다. ALB가 다루는 것은 HTTP, HTTPS, gRPC로 UDP는 포함되지 않는다. GWLB는 IP를 다루지만 어플라이언스로 투과적으로 통과시키기 위한 것으로 일반적인 부하 분산 용도가 아니다. Classic Load Balancer가 대응하는 것은 TCP, SSL/TLS, HTTP, HTTPS이다.

ALB는 레이어 7에서 HTTP, HTTPS, gRPC를, NLB는 레이어 4에서 TCP, UDP, TLS를, GWLB는 레이어 3과 4에서 IP를 다룬다. 번호가 클수록 상위 정보까지 보고 분산할 수 있다고 생각하면 배열이 머리에 남는다. GWLB만 2개의 계층에 걸쳐 있는 것은 IP 패킷을 그대로 투과적으로 통과시키는 성질 때문이다.

경로나 호스트명 같은 HTTP 내용에 기반한 분산은 콘텐츠 기반 라우팅이라 불리며, 레이어 7에서 동작하는 ALB의 특기이다. NLB는 레이어 4이므로 HTTP 내용까지는 보지 않는다. GWLB는 흐름을 종단하지 않고 투과적으로 통과시키는 것으로, 분산 판단에 쓸 수 있는 것은 IP까지이다. Classic Load Balancer도 오래된 세대의 구조로, 이 용도에서는 ALB를 선택한다.

GWLB는 레이어 3과 4에서 동작하며 어플라이언스형 보안 기능이나 네트워크 기능을 위해 마련된 로드 밸런서이다. 흐름을 종단하지 않고 투과적으로 통과시키므로 중간에 검사 장치를 끼워도 통신이 보이는 방식이 달라지지 않는다. ALB와 NLB는 자신이 트래픽을 받아 분산하는 역할로, 투과적으로 통과시키는 용법은 쓰지 않는다. CloudFront는 콘텐츠 전송 서비스이다.

IAM은 AWS 리소스로의 접근을 안전하게 제어하는 서비스로, 누가 인증(로그인)되고 누가 인가(권한을 가지는가)되는지를 관리한다. 키의 생성과 제어는 KMS, HTTP 요청의 모니터링과 제어는 WAF, 인증 정보나 API 키의 보관과 로테이션은 Secrets Manager가 각각 담당한다. 역할은 서로 겹치지 않는다.

IAM은 '누가 인증(로그인)되고 누가 인가(권한을 가지는가)되는가'를 관리하는 서비스이다. 인증은 본인임을 확인하는 단계, 인가는 그 후 무엇을 해도 되는지를 결정하는 단계로 순서도 역할도 다르다. 로그인이 되어도 정책으로 허용되지 않은 조작은 실행할 수 없다. 이 둘을 바꿔서 기억하면 권한 설계를 잘못 읽게 된다.

KMS는 암호화나 서명에 사용하는 키의 생성과 제어를 쉽게 해주는 매니지드 서비스로, KMS 키는 FIPS 140-3 보안 레벨 3 인증을 받은 HSM으로 보호된다. 키는 암호화되지 않은 상태로 KMS 밖으로 나가는 일이 없다. 따라서 평문으로 꺼내거나 배포하는 사용법은 성립하지 않으며, 암호화나 복호화 작업을 KMS에 의뢰하는 형태로 사용한다.

WAF는 보호 대상 웹 애플리케이션 리소스로 전달되는 HTTP 및 HTTPS 요청을 모니터링하고, 허용·차단·카운트·CAPTCHA나 챌린지 같은 동작으로 접근을 제어한다. 카운트가 있으므로 바로 차단하지 않고 영향을 측정한 뒤 운영 규칙으로 만들 수 있다. 암호화나 서명에 관여하는 것은 KMS, 기록이나 시각화는 CloudWatch, 도메인 등록이나 이름 해석은 Route 53이다.

Shield는 DDoS 공격으로부터의 보호를 담당한다. Standard는 AWS WAF 등에 추가 비용 없이 자동으로 포함되는 기본 보호이며, Advanced는 추가 요금의 확장 보호이다. Advanced에서는 레이어 7 DDoS의 자동 완화, 상세한 시각화, Shield Response Team(SRT)에 의한 전담 지원을 받을 수 있다. 비용이 드는 방향이 반대로 되어 있는 선택지에 주의한다.

Shield Advanced는 추가 요금의 확장 보호로, 레이어 7 DDoS의 자동 완화, 상세한 시각화, Shield Response Team(SRT)에 의한 전담 지원을 제공한다. 로테이션은 Secrets Manager, 여러 계정에 걸친 보호의 일원 관리는 AWS Firewall Manager, 사용자 디렉터리와 토큰 발급은 Amazon Cognito의 사용자 풀이 담당한다.

Secrets Manager는 데이터베이스 인증 정보, 애플리케이션 인증 정보, OAuth 토큰, API 키 같은 비밀 정보를 생애 주기 전반에 걸쳐 관리·조회·로테이션하는 서비스이다. 로그인과 토큰 발급은 Cognito, 구성 기록과 준수 평가는 AWS Config, 키 자체의 생성과 보호는 KMS가 담당한다. 값을 다루어 순환시키는 것이 Secrets Manager라고 기억하면 좋다.

사용자 풀은 앱이나 API에 대해 사용자를 인증·인가하는 사용자 디렉터리로, 독립된 OIDC IdP로 기능하며 OAuth 2.0 토큰이나 JWT를 발급한다. ID 풀은 인증되었거나 인증되지 않은 사용자에게 AWS 리소스로의 접근 권한을 부여하는 것으로, AWS STS를 경유해 임시 AWS 인증 정보를 발급한다. 둘의 통합은 서로 필수가 아니며, 한쪽만으로도 사용할 수 있다.

ID 풀은 인증되었거나 인증되지 않은 사용자에게 AWS 리소스로의 접근 권한을 부여하는 구조로, AWS STS를 경유해 임시 AWS 인증 정보를 발급한다. 사용자 풀이 발급하는 것은 OAuth 2.0 토큰이나 JWT로, 이는 AWS API를 직접 호출하기 위한 인증 정보가 아니다. 장기 인증 정보를 배포하거나 이용자마다 IAM 사용자를 만드는 설계는 이 용도에 적합하지 않다.

Firewall Manager는 AWS WAF, Shield Advanced, VPC의 보안 그룹과 네트워크 ACL, Network Firewall, Route 53 Resolver DNS Firewall 같은 보호를 여러 계정·여러 리소스에 걸쳐 일원 관리하는 서비스이다. 개별 요청을 검사하는 것은 WAF 자신, 키 생성은 KMS, 로그인 정보를 다루는 것은 Cognito이다.

CloudWatch는 AWS 리소스와 그 위에서 동작하는 애플리케이션을 실시간으로 모니터링하여, 메트릭·로그·알람·대시보드를 통해 성능이나 운영 상태, 리소스 사용률을 시각화한다. 누가 어떤 API 조작을 했는지 기록하는 것은 CloudTrail, 구성과 그 변화를 기록하는 것은 AWS Config, 템플릿으로부터 리소스를 구축하는 것은 CloudFormation이다.

CloudTrail은 사용자·역할·AWS 서비스가 취한 조치를 이벤트로 기록한다. 관리 콘솔, CLI, SDK나 API를 통한 조작이 대상이며, 누가 어떤 API 조작을 했는지 나중에 추적할 수 있다. CloudWatch는 성능과 상태의 모니터링, CloudFormation은 템플릿으로부터의 구축, Systems Manager는 노드의 운영 조작을 담당하는 것으로, 조작 주체를 추적하는 용도가 아니다.

Config는 AWS 리소스의 구성에 대한 상세한 뷰를 제공하며, 리소스 간의 관계나 과거에 어떻게 구성되어 있었는지를 기록해 구성 변화를 추적할 수 있게 한다. 나아가 Config 규칙으로 구성을 평가하여 위반한 리소스를 비준수로 표시한다. 임계값 모니터링은 CloudWatch, 템플릿으로부터의 구축은 CloudFormation, 조작 기록은 CloudTrail의 역할이다.

이 3가지는 나란히 기억한다. CloudWatch는 성능과 상태의 실시간 모니터링, CloudTrail은 누가 어떤 API 조작을 했는지의 기록, Config는 리소스 구성의 기록과 준수 평가이다. 경쟁하는 서비스가 아니라, CloudTrail의 트레일은 S3 버킷에 저장되고 선택적으로 CloudWatch Logs로도 전달할 수 있다. CloudTrail이 보내는 쪽, CloudWatch Logs가 받는 쪽이라는 관계가 된다.

CloudFormation에서는 필요한 리소스를 기술한 텍스트 파일인 템플릿을 만들면, CloudFormation이 그대로 리소스를 프로비저닝하고 설정한다. 만들어진 리소스 그룹은 스택이라는 하나의 단위로 통합 관리할 수 있으며, 한꺼번에 삭제도 할 수 있다. 템플릿이 설계도, 스택이 완성된 것의 묶음이라는 대응이 된다.

CloudFormation이 생성한 리소스 그룹은 스택으로서 하나의 단위로 관리할 수 있으며, 한꺼번에 삭제할 수도 있다. 개별적으로만 다룰 수 있는 것이 아니며, 스택을 삭제하면 그에 포함된 리소스도 함께 삭제된다. 구성 변화를 시계열로 기록하는 것은 AWS Config의 역할이다. 한꺼번에 만들고 한꺼번에 지울 수 있다는 점이 인프라를 코드로 다루는 이점이 된다.

Systems Manager는 AWS·온프레미스·멀티 클라우드의 각 환경에 있는 노드를 대규모로 일원적으로 표시·관리·운영하기 위한 통합 인터페이스로, Run Command, Session Manager, Automation, Parameter Store, Patch Manager, Fleet Manager 등을 포함한다. 구성 기록은 Config, 템플릿으로부터의 구축은 CloudFormation, 트래픽 분산은 ELB이다.

스팟 인스턴스는 AWS 클라우드의 미사용 EC2 용량을 이용하는 구매 옵션으로, 큰 폭의 할인이 있는 대신 중단되는 경우가 있다. 중단을 허용할 수 있는 배치 처리나 테스트 환경에 적합하다. 사용량 약정은 Savings Plans, 인스턴스 속성 약정은 예약 인스턴스, 선불도 약정도 없는 것이 온디맨드이다.

Savings Plans는 일정 사용량 약정과 맞바꾸어 할인을 받는 요금 모델이고, 예약 인스턴스는 인스턴스 유형·플랫폼·테넌시 같은 속성에 약정하여 할인을 받는 요금 모델이다. 둘 다 기간은 1년 또는 3년이며, 지불은 전액 선불·일부 선불·선불 없음 중에서 선택할 수 있다. 중단될 수 있는 것은 스팟 인스턴스이다.

Compute Savings Plans는 가장 유연하여 인스턴스 패밀리 변경, 리전 변경, EC2와 Fargate와 Lambda 간 이동, OS 변경에 대응한다. EC2 Instance Savings Plans는 특정 리전의 특정 인스턴스 패밀리에 약정하므로 패밀리 내 크기 변경이나 OS 변경은 가능하지만 패밀리와 리전의 변경은 할 수 없다. 기간은 둘 다 1년 또는 3년이며, 지불은 전액 선불·일부 선불·선불 없음 중에서 선택한다.