[AWS] VPC

김아름·2022년 2월 15일

AWS

목록 보기

10/25

이 글은 가상 데이터 센터 만들기 - VPC 기본 및 연결 옵션 - 양승도 솔루션즈 아키텍트(AWS 코리아)를 듣고 강의 내용을 요약해 적은 글입니다. 글에서 사용한 모든 사진은 강의에 등장하는 것으로, 이 글에 대한 모든 권한은 Amazon Web Services Korea에 있습니다.

VPC(Virtual Private Cloud)

VPC를 통해 마치 내 전용 가상의 데이터 센터를 이용하는 것처럼 사용이 가능하다.

vpc는 aws에서 2009년에 공개했고 2013년 이후부터는 이전의 클래식 버전(EC2 클래식이라 한다)은 제공하지 않고 vpc만 제공한다.

VPC

vpc를 구성하면 데이터 센터 내에 내부적인 통신을 위한 관리의 목적으로 private IP address를 사용하는데 한 번 할당 받게 되면 EC2 인스턴스가 terminate하기 전까지 사용할 수 있으며 변경되지 않고 직접 설정이 가능하다.

서브넷

커다란 네트워크를 만들어 놓으면 이를 작은 단위로(subnet) 분리해 가상 머신을 위치 시켜 사용할 수 있다.
어떤 서브넷은 인터넷으로 향하는 길목을 만들어서 외부에서 접속하도록 만들어 준다.
- 예를 들어, 외부에서 접속하면 안되는 RDB와 같은 경우 외부에서 접속하는 길목을 차단하여 보안의 레벨을 높일 수 있다.

인터넷에 연결된 VPC 설정

CIDR(사이더) notation

172.31.0.0/16

16비트는 고정이고 나머지 뒤의 16비트가 변경 가능하다.
- 1010 1100 0001 1111 ...
aws에서 사용하는 IP address를 표현하는 방법을 말한다.
Classless Inter Domain Routing에 해당한다.
각각의 의미
- 172.31.0.0
  - 권장: RFC1918에 명시된 ip address를 vpc의 address로 사용할 것이 권장됨
- /16
  - 16이라는 maskig 값을 가지는 커다란 vpc를 놓고 많은 워크로드를 vpc 속에서 사용할 수 있다.
    - 64 address를 사용할 것
연결할 수 있는 다른 네트워크와 겹치는 범위는 피해야 한다.

RFC 1918

내부적인 용도로 사용하는 private ip address를 사용할 때는 위의 3가지 사이더를 사용할 것이 권장된다.
- 즉, 해당 범위 안에 있는 네트워크를 사용할 것이 권장된다.
이 규약을 지키지 않고 54로 시작하는 ip address range를 사용하면 현재 이 ip를 aws에서 public ip로 사용하고 있기 때문에 public과 private이 엉키게 된다.
- 따라서, routing이 밖으로 안나가고 회사 내에서 패킷이 도는 경우가 생길 수도 있다.

서브넷

ip address를 정하고 나면 서브넷이라는 공간을 만들게 된다.
서브넷은 AZ 안에 서브넷을 각각 만들어야 하며 네트워크 속에서 서브넷을 나눈다.
ap-northeast-2a(172.31.0.0/24)
- masking 값 24가 의미하는 바는 24bit(172.31.0)는 고정, 뒤의 8bit는 변화
  - 따라서, 256개(2의 8승)의 ip address를 사용할 수 있는 네트워크이다.
  - 그런데 이 때 0과 255는 브로드캐스팅과 네트워크를 나타내며 1, 2, 3은 aws에서 관리의 목적으로 사용하기 때문에 총 251(256 - 5)개의 ip address를 사용할 수 있다.
라우팅이 되려면 overlapping 되면 안되기 때문에 서브넷끼리는 겹치지 않아야 한다.
masking 값은 20도 되고 25도 되지만 익숙한 단위인 24(8의 배수)를 사용하는 것이 좋다.

인터넷 경로

서브넷 생성 후 네트워크가 인터넷으로 나갈 수 있는 경로를 만들어 주어야 한다.
- 이를 라우팅 테이블이라고 말한다.
vpc에는 기본적인 라우팅 테이블이 존재하며, 서브넷 별로 원하는 라우팅 테이블을 설정하면 된다.
- 어떤 서브넷은 인터넷과 통신 하도록/ 어떤 서브넷은 인터넷과 통신하지 못하도록 만들 수 있다.
Destination은 위에서 VPC에 설정되었던 ip address이다.
위와 같이 Target이 local로 라우팅 테이블이 설정되어 있다면 외부로 패킷을 보내지 말고 내부로(내 vpc로) 라우팅을 하라는 뜻이다.
이는 vpc를 만들고 서브넷을 만들고 인스턴스를 여기 저기 만들어도 모든 인스턴스끼리는 서로 통신할 수 있도록 기본적으로 라우팅 테이블이 만들어지는 것이다.

일반적으로 인터넷과 연결된, 외부로 서비스할 수 있는 vpc를 만들어야 하기 때문에 Internet Gateway를 만들어서 vpc를 연결해 주어야 한다.
- 그러면 igw-로 시작하는 id를 가진 internet gatway가 생성된다.
- 이를 이용해 해당 서브넷에 있는 EC2 인스턴스에서 인터넷으로 트래픽을 보내고자 할 때 경로를 만들어 줄 수 있다.
- 아래에 0.0.0.0/0은 지구상에 존재하는 모든 네트워크를 말하며 이를 igw-(Target)로 보내도록 설정되어 있다.
  - 따라서, 내가 존재하는 범위가 아닌 다른 곳으로 패킷을 보낼 때는 위 테이블에서 두 번째 행에 적힌 규칙을 따르게 된다.
  - 즉, vpc → 인터넷으로 나가려 하는 관문(igw-)으로 패킷을 보내고 나면 인터넷에 존재하는 네트워크가 서로서로 패킷을 주고 받으며 원하는 작업을 수행하게 된다.

VPC의 네트워크 보안(Network ACLs/Security Groups)

접속이 허용된 사람에게만 열어준다.
aws는 기본적으로는 고객이 허용하기 전에는 불허하는 정책을 사용하고 있다.
aws에서 제공하는 방화벽 기능이 크게 2가지(ACL, Security Groups)가 있다.

Network ACL(Network Access Control List)

서브넷 단위로 적용한다.
서브넷 안에 EC2 인스턴스 200개가 있으면 200개 모두가 적용을 받게 된다.
단, NACL은 Stateless로 동작한다.
- 반면 Security Groups는 Stateful로 동작한다.
차례 차례 Rule을 검사하게 되는데 가장 위쪽에 ALL Traffic에 대해 ALLOW 설정이 되어 있다.
- NACL은 VPC를 생성하고 나면 모든것을 허용하도록 만들어져 있다(Security groups는 모든 것을 차단하기 때문에 기본적으로 외부로 트래픽을 보낼 수도 들어올 수도 없다).

Security Groups: 애플리케이션 구조

만약 우리 vpc 안에 프론트엔드와 백엔드 서버가 모두 있다면 각각의 인스턴스에 내가 정해 놓은 “My web server” security group을 설정하고 “My backend”라고 하는 security group을 설정한다.
그런데 이 때, 웹 서버는 외부에서 들어오는 80 포트와 443 포트를 받고 싶을 것이며 백엔드는 웹 서버의 포트만 허용해야 할 것이다.
- 프론트엔드: 아래와 같이, 80 포트로 anywhere(0.0.0.0/0)에서 오는 트래픽을 allow하는 설정을 만든다.
- 백엔드: 아래와 같이, 2345(예시) 포트로 sg-82ba7ee6으로부터 오는 트래픽을 allow 한다.
  - sg-82ba7ee6는 웹 서버에 할당된 security group을 의미한다.
    - source를 ip address로 명시를 해도 되지만 이는 번거롭다. 왜냐하면, aws의 장점은 auto-scaling에 있는데 그 때마다 ip address를 찾아서 적는 것은 불가능하다. 따라서, 서버가 추가되었을 때 security group을 자동으로 붙여주면 해당 security group이 붙은 서버로부터 오는 모든 트래픽을 허용할 수 있게 된다.
    - 따라서, 아래 그림의 의미는 MyWebServers security group에 속한 인스턴스만 백엔드 security group에 연결이 가능하다는 뜻이다.

체크 포인트

최소 권한 원칙(Principle of Least Privilege)를 준수해야 한다.
- 필요한 방화벽만 열어놔야 한다.
  - 예를 들어, SSH를 사용하기 위해 22번 포트를 열어 놓으면 source address는 회사의 관리자 ip만 열어 놓으면 된다. 인터넷에서 오는 모든 source가 접속하지는 못하도록 해야 한다.
vpc가 있기 전에는 inbound security group만 설정할 수 있었는데 현재는 security group을 이용해 inbound/outbound 모두 보안 설정할 수 있다.

Stateful/ Stateless의 차이

인바운드 트래픽(들어오는 트래픽) 80 포트를 허용해 주면
- stateful: 들어올 때의 connection을 그대로 기억해서 response를 보낸다. 들어올 때 해당 포트가 허용되었으니 나갈 때도 똑같이 허용해 준다.
  - 즉, 인바운드 룰만 설정하면 된다.
  - AWS에서는 security group이 stateful에 해당한다.
- stateless: stateful에서처럼 “기억"을 하지 않는다.
  - 즉, 들어올 때 열어줬으면 나갈 때도 똑같이 열어줘야 하지만 stateless의 경우 그렇게 하지 못한다.유의해야 할 점은 나갈 때는 들어왔을 때 사용한 포트보다 복잡하다는 것이다.
    - 왜냐하면, 서버는 특정한 포트가 정해져 있지만 클라이언트는 os마다 사용하는 포트 범위가 다양하기 때문이다.
    - 보통 클라이언트는 1025 ~ 65536(그 이하는 well known 포트로, 서비스하는 데몬들이 주로 사용하는 포트)의 포트를 랜덤하게 사용하기 때문에 해당 포트로 나가는걸 허용하도록 ACL 설정을 해 주어야 한다.
    - 따라서, stateless 방화벽은 들어오는 것과 나가는 것을 쌍으로 설정하지 않으면 통신을 하지 못한다.
  - AWS에서는 NACL이 이에 해당한다.

VPC의 연결 옵션

크게 세 가지의 새로운 연결이 주로 사용된다: 인터넷 엑세스 제한, 다른 VPC와 연결, 회사 네트워크에 연결

인터넷 엑세스 제한: 서브넷 별로 각기 다른 라우팅

아래의 상황이 있을 수 있다.

프론트엔드: 인터넷 연결 O
백엔드: 인터넷 연결 X

가끔 필요에 의해 private subnet에 인터넷을 허용해 주어야 할 때가 있는데(os 패치, 외부의 소스로부터 애플리케이션을 deploy 하는 경우 등등...) 그 때마다 public 서브넷의 인스턴스로부터 받아오는 것은 매우 불편한 작업이다.

이럴 때 사용하는 것이 NAT(Network Address Translation) Gateway이다.

NAT Gateway: 아웃바운드 전용 인터넷 허용

Public subnet: 인터넷과 연결된 서브넷
Private subnet: 인터넷과 연결되지 않은 서브넷

왼쪽이 백엔드(private), 오른쪽이 프론트엔드(public) 서브넷이다.
백엔드 서브넷에 인터넷 연결을 하기 위해 NAT Gateway를 이용해 오른쪽의 프론트엔드 서브넷과 연결되도록 설정 했다.
이렇게 설정하면 백엔드 서버에서는 외부에서 무언가를 다운받아 오는 것이 가능하지만 외부에서는 백엔드 서버에 접근할 수 없다.
- 왜냐하면, private subnet은 public ip address를 가지고 있지 않기 때문이다.
- 아래와 같이 라우팅 설정을 하면 된다.
  - 내부는 그대로, 나머지는 nat gateway에 연결한다.
  - 그러면 나가는 패킷은 nat gateway로 보내지고 nat gateway는 인터넷으로부터 나간 패킷들을 받았다가 private subnet으로 돌려 보낸다.

VPC 간 연결: VPC Peering

게임을 예로 들면, VPC Peering을 이용해 인증 서버를 중앙에 둘 수 있다.

VPC끼리는 private 하게 연결할 수 있다(마치 데이터센터의 전용 라인을 서로 연결한 것처럼).
보통 인증, 모니터링, 로깅, 원격 관리, 스캐닝 등을 위해 사용한다.
라우팅을 할 때 소스를 ip 주소가 아니라 security group으로 referencing할 수 있기 때문에 VPC Peering을 할 때도 다른 VPC에 있는 security group도 referencing할 수 있다.

연결 방법

누군가 신청을 하면 승인을 해주어야 하며 account가 서로 다를 수도 있다(회사끼리 서비스 하는 네트워크를 서로 묶는 데 이용할 수도 있기 때문).

VPC 1이 VPC2로 피어링 요청
VPC 2의 피어링 요청 수락 - connection이 생성됨
피어링 요청이 수락 되었으면 경로를 만들어야 한다. - 패킷을 라우팅 하기 위함이다.
- 피어링 게이트웨이를 만들면 id가 나오는데 pcx- 로 시작한다.
  - 따라서, 피어링 게이트웨이로 향하도록 라우팅 테이블을 만든다.
  - 만약 10.55.3.6으로 패킷을 보내라는 요청이 들어오면 알아서 pcx-로 시작하는 게이트웨이로 보내진다.

2017년 당시 세션에서 연사 분은 aws VPC Peering이 transit VPC(하나의 VPC를 통해 다른 VPC로 트래픽이 왔다갔다 하는 것)를 지원해 주지 않고 있다고 언급했다. 즉, 위의 vpc peering 설명 첫 번째 그림에서 A ↔ C, A ↔ D는 통신이 가능하지만 C ↔ D 통신은 할 수 없다. 하지만 원한다면 할 수 있는 best practice guide를 aws 웹 사이트에서 제공하고 있다고 한다.

회사 네트워크에 연결: VPN(Virtual Private Network) & DX(Direct Connect)

온-프레미스 데이터 센터와 vpc를 연결할 수도 있다.

회사의 데이터 센터에 있는 중요한 데이터를 aws로 마이그레이션 하고 싶을 수 있는데 인터넷을 통해 전송하는 것은 보안상 문제가 있다. 따라서 이를 안전하게 전송하고 싶다면 VPN 또는 DX(aws와의 전용 선을 연결하는 것)를 이용할 수 있다.

이러한 구조를 흔히 Hybrid network 구조라 한다.

VPN 연결

고객과 aws를 연결하기 위한 세팅
- 고객: 사용하고자 하는 데이터 센터에 VPN 장비를 하나 마련해야 한다. 이를 aws에서는 customer gateway라고 부른다.
- aws: aws의 vpc에는 aws 전용 virtual gateway가 있다.
그러면 이제 이 둘 사이를 IPSec tunnel로 연결한다.
- VPN 연결 당 IPSec tunnel은 2개가 생성 된다.
aws에서는 고객이 사용하는 VPN 장비의 제조사와 장비에 들어간 os 버전을 선택하면 해당하는 configuration을 만들어 주며 이후 고객은 파일 다운로드 받아서 VPN 장비에 밀어 넣으면 된다.

VPN 연결을 하면 안전한 채널이 생성되기는 하지만 이를 서비스 하는 용도로 사용하기 위해서는 부족함이 있다.
- 많은 데이터를 정해진 시간 내에 보내고 싶다든지 둘 사이에 원하는 latency를 보장받고 싶을 수 있다.
- VPN 연결을 하지만 경로는 인터넷이며 전용망이 아니다. 따라서 품질이 나빠질 수도 있다.
- 이러한 리스크를 없애고 싶다면 Direct Connect라는 연결을 할 수 있다.
DX는 aws와 고객 사이의 전용선이다.

VPC 및 다른 AWS 서비스

S3

aws에는 VPC 안에 위치시킬 수 있는 서비스가 다양하게 있는데, S3의 경우 VPC 내에 있지 않다.
- 즉, 인터넷이 연결된 곳이라면 S3에 엑세스 할 수 있기 때문에 서울 리전에 있는 사람도, 유럽 리전에 있는 사람도 모두 엑세스 할 수 있다.
- 그렇기 때문에 VPC내에 있는 인스턴스가 S3에 접근하려면 VPC 밖으로 나가야 한다.
  - 서울 리전에 있는 S3라면 굳이 vpc 밖으로 나가서 접근하는 것이 불합리하게 느껴질 수도 있으나 대부분의 고객들이 이와 같은 방식으로 사용을 하고 있다.
보안 관점에서 S3는 ip가 고정되어 있지 않다.
- 회사의 보안 정책 중 outbound도 깐깐하게 고정해 적용하는 회사라면 S3를 anywhere로 모두 다 공개하는 것이 불가능할 수 있다.
  - 이러한 고객들을 위해 만든 것이 VPC endpoint for S3이다.
VPC endpoint for S3를 이용하면 해당 endpoint를 통해서 private하게 S3와 데이터를 주고 받을 수 있다.
아래와 같이 라우팅 테이블을 생성하면 되는데, 이는 S3로 향하는 것을 vpc로 보내라는 뜻이 된다.
- 이를 통해 private하게 왔다갔다 할 수 있다.
- 이렇게 VPC endpoint를 설정해 놓으면 IAM이나 S3 bucket policy를 이용해 access control을 잘 할 수 있게 되어 보안이 좋아진다. 아래와 같은 예시를 들 수 있다.
  - VPC endpoint에 특정 S3 bucket 액세스만 허용할 수 있다(IAM Policy at VPC Endpoint).
  - VPC Endpoint를 통한 엑세스만 허용(IAM Policy at S3 Bucket).

VPC Flow Logs

내가 허용한 방화벽 설정에 의해서 패킷이 드랍 되거나 거부 되는지 확인할 수 있어야 하는데(방화벽 로그) 이를 통해 사고를 방지할 수 있다.

이를 위해 제공하는 것이 VPC Flow Logs 서비스이다.

Network ACL 또는 security group을 통해 만들어지는 방화벽에 걸리는 모든 패킷들의 로그를 수집해 고객에게 제공한다.
Flow Log를 enable하게 되면 어느 ip에서 몇 번 포트로 가는 것들이 accept 되고 reject 되었는지 알 수 있다.

IP 주소 체계 복습

현재 우리가 일반적으로 사용하는 주소는 IPv4라고 보면 된다. 이 주소는 32비트로 이루어져 있으며, 8비트씩 4개의 구간으로 나누어서 나타낸다(X.X.X.X).
각 자릿수는 0~255(2^8)의 범위(256개)로 표현이 가능하다. 따라서 이론적으로 42억 9496만 7296개의 IP가 존재한다. 하지만 일부 IP주소들은 특별한 용도를 위해 예약되어 있어서 실질적으로는 더 적은 수의 IP 주소만 사용할 수 있다고 생각하면 된다.

참고 강의

가상 데이터 센터 만들기 - VPC 기본 및 연결 옵션 - 양승도 솔루션즈 아키텍트(AWS 코리아)

김아름

쿄쿄쿄

이전 포스트

[AWS] Elastic Load Balancer

다음 포스트