SAA와 DOP공부하며 정리한 내용 + 송주영님의 DevOps with Terraform 강의내용을 기반으로 학습한 내용 + 추가적으로 찾아보고 공부한 내용을 아카이빙 (지속적으로 내용 추가)
AWS 서비스의 분류
VPC는 AWS서비스의 근간을 이룬다. 이유는 대부분의 서비스가 실제로 각 리전마다 존재하는 Default VPC내부에서 생성되기 때문이다. 많은 사람들이 서비스를 사용하면서 VPC 내부의 리소스와 통신하고 있다는 것을 모르기 때문에, 알아두면 그만큼 시야가 넓어지는 중요한 서비스 중 하나라고 생각한다. 기본적으로 보안그룹을 설정해야하는 서비스들은 VPC 내부에서 동작한다고 생각하면 편하다.
VPC와 보안그룹
사실 VPC이야기를 하기 이전에, 일반적으로 애플리케이션 개발을 하고 배포할 때 마주하는 보안그룹과의 문제를 먼저 정리하면 좋을 것 같다.
우선, AWS의 서비스는 크게 세 가지로 분류된다.
- 글로벌 서비스(IAM 등)
- 리전 종속 서비스(DynamoDB, S3, Cloudfront, Global Accelerator 등)
- VPC 종속 서비스(나머지)
몰랐다면 지금 알아두자.
그리고, 보안그룹은 위 3가지의 분류 중 2번과 3번에 적용 가능하다.
이 때, 중요한 규칙이 적용된다.
- 기본적으로 보안그룹은 VPC에 종속적이다. 하나의 ID를 가진 보안그룹을 다중 VPC에 중복 적용할 수 없다.
- VPC에 종속된 보안그룹은 해당 VPC 내부의 서비스 여러 개에 적용할 수 있고, 해당 VPC내에서 자유자재로 활용되며 트래픽을 제어하는 데 사용된다.
- 리전 종속 서비스의 경우는 리전 종속 보안그룹이 별도로 할당되며, 해당 서비스(S3, DynamoDB)에서 직접 관리하도록 되어 있다. 이는 VPC와는 별개로 생각되기 때문에, 타 서비스나 VPC에 중복 적용할 수 없다.
사실 위의 내용만 잘 이해하고 있어도 보안그룹을 적용하는 데 있어 시야가 트인다.
VPC 여러 개에 동일한 규칙 적용이 필요하다면
AWS Organization SCP를 통해 보안 그룹 규칙을 작성하고 이를 해당 조직에 적용하면 조직 내부의 모든 VPC에 동일한 보안 그룹 규칙이 적용된다. 물론 각 보안 그룹은 다른 보안 그룹이다.
VPC
VPC는 퍼블릭 클라우드 내에서 구현된 ‘논리적으로 격리된’ 가상 사설망을 의미한다. 물리적으로 분리되는 것을 원한다면 온프레미스 환경에서 직접 구현해야한다. 우리가 일반적으로 사용하는 퍼블릭 클라우드 서비스 제공자들이 VPC서비스를 대부분 제공하기 때문에, 어렵지 않게 논리적으로 격리된 사설망을 구축할 수 있다.
AWS를 기준으로 얘기하면, AWS에는 각 리전별로 기본 VPC가 존재하며, 앞서 언급한 VPC에 종속적인 서비스들의 경우 생성 시 VPC를 선택하도록 되어 있다.
VPC는 한 리전 내에 여러 가용 영역에 걸쳐서 생성할 수 있으며, 이렇게 하여 재해 등의 이슈에 대비하여 가용성을 끌어올리는 것을 권장한다. ap-northeast-2 리전의 Default VPC도 모든 가용영역에 걸쳐 생성되어있다. 서브넷 4개가 각 가용영역에 할당되어있다.
Subnet
VPC는 하위에 서브넷이라는 단위로 나뉘는데, 각 서브넷 또한 논리적으로 분리되어있다. 서브넷의 특징은 Public, Private으로 나누어 사용할 수 있으며, 이를 기반으로 퍼블릭 네트워크에 노출할 서비스와 그렇지 않을 서비스를 구분 및 할당한다는 점이다.
Public Subnet은 기본적으로 VPC의 출입문 역할을 한다. 퍼블릭 인터넷과 직접적으로 통신할 수 있는 Internet Gateway가 연결된 NAT Gateway가 위치하며, 해당 NAT Gateway를 통해 타 Private Subnet과도 통신할 수 있다.
NAT Gateway에는 라우팅테이블을 적용해야하는데, 이 라우팅 테이블은 Internet Gateway, Private Subnet 등 다양한 곳에 연결되어있으므로 각 경로를 헷갈리지 않고 구분할 수 있어야한다.
즉 우리가 만약 특정 프라이빗 서브넷의 RDS 인스턴스에 통신하고 싶다고 하면, 다음과 같은 경로를 통해 접속하게 된다.
Internet Gateway → NAT Gateway(VPC내 Public Subnet) → Private Subnet Routing Table → RDS
조금 복잡해보이더라도, 보안을 위해 가장 권장되는 형태이다.
VPC Endpoint
기본적으로 우리가 VPC 내부의 EC2 서버에서 외부 S3 등의 서비스에 접속한다고 치자(S3는 리전 종속이라 VPC내부에 존재할 수 없음). 그러면 어쩔 수 없이 인터넷을 통해 트래픽이 오가게 된다. 이렇게 되면 보안상으로도, 속도 상으로도 이점을 가지기 어렵다.
이를 위하여 VPC EndPoint를 사용한다. 이를 통해 인터넷이 아닌 AWS 내부망을 통해 외부 서비스와 안전하고 빠르게 정보를 주고받을 수 있다.
Gateway형 Endpoint
S3나 DynamoDB의 경우 Gateway 형으로 생성되는데, 이는 따로 보안그룹을 형성할 필요가 없다.
Interface Endpoint
이외의 서비스들은 보안그룹을 설정해야하는 Interface형 Endpoint를 생성하는데,
기본적으로 443 포트를 허용한다. 특정한 경우를 제외하면(RDS등?)
VPC Peering
타 VPC와 통신할 수 있도록 다리를 놓는 과정. 각 VPC의 CIDR블록이 겹치면 안 된다.
Requester VPC가 peering request를 보내면, Accepter VPC가 해당 request를 받아들이는 과정으로 진행된다.
피어링을 진행한다고 무조건 연결되는 것이 아니고, 각 VPC의 라우팅 테이블에 CIDR 블록에 대한 트래픽을 명시해주어야 해당 트래픽이 올바르게 VPC 간 이동을 진행할 수 있다.
