서론

AWS 관련하여 개인 프로젝트를 수행하고, 공부하다보니 몇가지 헷갈리는 점이 있다.

바로 AWS의 권한 및 IAM 과 AWS의 네트워크 구조 및 VPC 관련내용이다.

이번 포스트는 공부한 AWS의 네트워크 구조와 VPC 관련 내용을 정리하기 위한 목적으로 작성한다.

AWS는 어떻게 서비스를 하는가?

AWS는 전 세계 여러 대륙, 여러 나라에 있는 리전(Region)에서 여러 가용영역(AZ, Availability Zone)을 기반으로 서비스를 제공한다.

퍼블릭 클라우드 시장에서 부동의 1위를 유지하고 있는 AWS는 다양한 서비스를, 시간과 장소에 구애 받지 않고 인터넷만 있다면 어디서든지 접근할 수 있도록 제공한다.

이 말은, 우리가 어떤 서비스를 사용하거나 구축을 하기 위해 물리적 서버, 네트워크 장비, 장소, 전선, 항온항습기 등 여러가지 필요한 것을 직접 준비할 필요가 없다는 것이다.

그렇기 때문에 클라우드를 도입하는 것이 비용을 아낄 수 있다는 것이다.
(다만, 이는 초기 투자비용이 저렴하다는 것이며, 적절한 비용계획을 세우지 않는다면 오히려 요금 폭탄을 맞을 수 있다.)

그런데, 이런 서비스는 결국 물리적인 요소들이 있어야 사용할 수 있는데 AWS는 이를 어떻게 제공하는가?

AWS도 똑같다. 물리적 서버, 네트워크 장비, 장소, 전선, 항온항습기 등 여러 장비를 구매해서 인프라를 구축하고, 구성한 인프라를 이용해 서비스를 제공한다.

즉, 우리는 AWS가 대신 관리하고 있는 인프라와 서비스를 돈을 주고 빌려쓰고 있다는 것이다.

이러한 대규모 인프라를 구성해놓은 것을 우리는 IDC(Internet Data Center)라고 부른다. 물론, 클라우드 컴퓨팅을 위한 데이터센터는 CDC(Cloud Data Center)라는 명칭을 사용하기도 한다.

AWS는 자체적으로, 또는 여러 IDC 사업자와 계약하여 전 세계 곳곳에 자신들의 인프라를 구축해놨다.

AWS Region & AZ

세계 곳곳에는 여러 AWS 리전이 존재한다. 이 포스트를 작성하는 시점인 2023년도 5월 기준으로는 31개의 리전이 존재한다.

IAM등 몇몇 서비스를 제외하고는 AWS에서 제공하는 대부분의 서비스는 리전에 종속적이다. 서로 다른 리전간에 우리가 생성한 EC2 인스턴스, 리소스 등이 공유되지 않는다.

리전은 국가나 지역 단위로 구분되며, 각 리전은 1개 이상의 가용영역을 보유하고 있다.

가용영역은 1개 이상의 데이터센터로 구성된 논리적인 데이터센터이다. 즉, 각 가용영역은 데이터센터의 집합체이다.

각 가용영역은 물리적으로 분리된 위치에 존재하며, 그렇기 때문에 화재등의 이유로 하나의 가용영역이 마비되더라도 다른 가용영역에서 AWS 서비스를 제공할 수 있다.

리전마다 여러개의 가용영역을 가지고, 각 가용영역에 장애가 발생하더라도, 다른 가용영역을 통해 서비스를 지속할 수 있는것이 AWS에서 강조하는 고가용성의 핵심 원리이다.

여담으로, AWS가 리전을 만드는 기준은 여러가지가 있다.
물론 AWS 또한 이윤을 추구하는 기업이기 때문이 수익성이 제일 우선적이겠지만, 리전이 만들어지는 지역의 법률, 지정학 및 지리학적 리스크 등 여러 요소를 종합적으로 판단하여 선정한다.

예를들어 우리나라의 대표적인 지정학적 리스크는 북한이다.

옆나라 일본같은 경우 상대적으로 좁은 위치에 2개의 리전이 존재하는데 이는 지리학적 리스크, 강도 높은 지진이 자주 발생하는 위험 때문에 2개의 리전이 만들어져 있다고 들었다.

VPC란 무엇인가?

VPC의 정의

Virtual Private Cloud
사용자의 AWS 계정 전용 가상 네트워크
AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다.

VPC의 등장 배경

AWS의 네트워크 환경을 이해하기 위해서 필수로 알아야 하는것이 바로 VPC에 대한 개념이다.

지금은 AWS를 사용하기 위해 필수적인 요소 중 하나지만, 처음부터 AWS에서 VPC를 제공한 것은 아니다.

처음에는 온프레미스 환경과 유사한 방식으로 네트워크 서비스를 제공했다. 하지만, 네트워크를 좀 공부 해 본 사람이라면 아이피 주소에는 한계가 있고, 효율적인 사용을 위해 CIDR을 이용해 대역을 나누고 용도별로 구분하는 노력이 필요하다.

AWS의 사용자가 점점 많아짐에 따라 이러한 관리 오버헤드가 증가했고, 이는 곧 빠르게 인프라를 제공해야 하는 클라우드 서비스와는 거리가 멀어지는 결과로 이어진다.

하지만, 사용자의 편의를 위해서 온프레미스와 비슷한 환경을 제공하는 현재의 서비스를 포기할 순 없었을 것이다.

이때 등장한 것이 바로 VPC이다.

각자 논리적으로 완전히 독립된 네트워크 환경을 제공하여 사용자가 원하는대로 네트워크 환경을 구성할 수 있고, 클라우드 서비스 제공자인 AWS 입장에서도 자신들이 이전까지 부담하고 있던 대규모의 Private 네트워크를 관리하는 오버헤드도 없앨 수 있었을 것이다.

추가적으로 각자 완전히 분리된 네트워크 환경을 가지기 때문에 보안적인 측면에서도 이전보다 훨씬 우수해졌다.

여담으로 만약 VPC환경과 VPC이전의 환경, 즉 Classic한 환경에 대한 차이점을 느껴보고 싶다면 네이버 클라우드 플랫폼 서비스(NCP)를 이용해 보는것을 추천한다.

NCP는 현재 VPC 네트워크 환경과 Classic 네트워크 환경 둘다 지원하고 있다.

VPC와 가용영역, 그리고 서브넷

VPC는 여러 리전을 걸쳐서 존재할 수 없고, 하나의 리전 안에 종속된다.

하지만, 여러 가용영역을 걸쳐서 존재할 수 있다.

위 그림에서 보듯이 VPC는 리전 안에 종속되지만 여러 가용영역에 걸쳐서 존재하고 있으며 그 안에 여러개의 서브넷이 존재한다.

즉, 서브넷을 생성하기 위해서는 VPC가 필요하다.

그리고 서브넷은 VPC와 가용영역의 교집합이라고 생각하면 된다.

VPC와 AWS 서비스

AWS에서는 다양한 서비스를 제공한다.

EC2, EKS, Lambda, RedShift, RDS, Kinesis, S3,
CloudFront, Route53, EBS, EFS, CloudFormation, BeanStalk, ECS, CloudWatch, CloudTrail, GuardDuty, KMS, SES, SNS, SQS, Macie, Rekognition, Inspector, DynamoDB, Snowball, Cloud9, ElasticCache 등...

지금 기억나는거만 대충 적었는데도 이정도다.
AWS는 이것보다 훨씬 많은 서비스를 제공중이다.

이러한 서비스를 네트워크, VPC를 관점으로 기준을 잡아 분류 할 수 있다.

---

1. 네트워크 사용 불가능 서비스
   AWS는 클라우드 서비스를 제공하지만, 별도로 네트워크를 사용하지 않는 서비스들도 존재한다.
   대표적으로 IAM이 있고, AWS 환경으로의 대용량 데이터 마이그레이션을 위한 물리적인 장비를 대여해주는 Snow Family 서비스도 있다.
   
   
2. VPC 사용 불가 서비스
   네트워크를 사용하긴 하지만, VPC 상에서는 서비스되지 않는 서비스도 있다. 대표적으로 DNS 서비스인 Route53, 메세징큐를 제공하는 Amazon MQ 등이 있다.
   
   
3. VPC 필수 서비스
   대표적으로 RDS는 VPC 내부에서만 사용 가능하다.
   
   
4. VPC 선택 가능 서비스
   대부분의 서비스는 VPC를 사용할지 안할지 선택할 수 있다.
   하지만 클라우드 컴퓨팅의 특성 상 네트워크를 사용하지 않는 경우는 거의 없다고 봐도 무방할 것이다.

---

그렇다면 VPC를 사용한다는 것은 무엇을 의미할까?

의외로 이것은 아주 간단히 정의할 수 있다.

바로, ENI(Elastic Network Interface)의 사용 여부이다.

즉, ENI를 사용한다면 해당 서비스는 VPC에 연결되어 있는 것이며, VPC에 존재하는 모든 서비스는 ENI가 연결되어 있다는 뜻이다.

ENI

VPC에서 가상 네트워크 카드를 나타내는 논리적 네트워킹 구성 요소
프라이빗 IP 주소, 퍼블릭 IP 주소, 보안 그룹 및 MAC 주소와 같은 네트워크 인터페이스에 필요한 모든 정보를 포함한다.

우리가 EC2 인스턴스를 생성하면 해당 인스턴스는 기본적으로 ENI가 하나 연결된 채로 생성된다. 그래서 우리는 일반적으로 EC2 인스턴스는 VPC 내부에서 제공되는 서비스라고 생각한다.

하지만, EC2 인스턴스 자체는 VPC 종속적인 서비스라곤 할 수 없다.

잘 생각 해보자. 기본적으로 EC2 인스턴스에 1개 이상의 ENI가 있어야 하긴 하지만, 다른 ENI를 연결하면 기존 ENI는 자유롭게 분리 가능하지 않은가?

즉, VPC에 종속적인 것은 EC2 인스턴스가 아니라 ENI이다. 그렇기 때문에 위 그림을 실제로 정확히 표현한다면 다음과 같이 나타낼 수 있을 것이다.

좀 더 정확히 말하자면 ENI는 항상 Subnet에 종속적이며, Subnet은 항상 VPC에 종속적이다.