.

Data_Engineering_TIL(20230114)

Youtube “AWS를 사용한다면 반드시 알아야 할 네트워크 기초 지식” 자료를 공부하고 정리한 내용입니다.

** URL : https://youtu.be/vCNexbgYmQ8

[목차]

1 ) Default VPC

2 ) 보안 강화된 네트워크 위한 VPC 설계 전략

3 ) Hybrid Networking

[공부한 내용]

1 ) Default VPC

AWS의 자원레벨 관점에서 VPC는 리전레벨의 서비스이다. VPC는 리전 레벨의 리소스이기 때문에 여러 가용영역에 걸쳐 하나의 VPC를 생성할 수 있다. VPC 안에는 서브넷이라던지 EC2, RDS 같은 가용영역 레벨의 리소스들이 구성될 수 있다. 참고로 리전레벨에 해당하는 서비스에는 S3가 있다. 이 S3는 VPC 안에 있지는 않다. 글로벌 레벨으로는 클라우드 프론트 서비스가 있다.

VPC는 기존 데이터센터에서 운영하는 네트워크의 인프라와는 유사하지만 물리적으로 제공되는 인프라가 아닌 가상의 독립적인 네트워크 환경을 제공하는 서비스이다. 네트워크 인프라 설계를 할수 있도록 서브넷구성, 라우팅 테이블 설정, 방화벽 설정 등을 통해서 네트워크의 흐름을 제어하고 VPC 내에 배포된 자원을 보호할 수 있다.

그러면 AWS에서 제공하는 default VPC가 어떻게 구성되어 있는지 알아보자.

어느 리전에서 시작하더라도 default VPC는 하나씩 구성되어 있다. 모두 동일하게 172.31.0.0/16 대역의 아이피 주소를 사용하고 있다.

리전마다 사용할수 있는 가용영역은 조금씩 다르지만 최소 2개 이상이 있고, 서울리전 같은 경우에는 4개의 가용영역을 제공하고 있다. 그래서 아래 그림과 같이 default VPC 같은 경우에는 a,b,c,d 가용영역을 포함하고 있는데 그 안에 서브넷을 하나씩 두고 있는 형태이다. 서브넷은 사실 가용영역이 몇개냐에 상관없이 모두 20비트를 사용하고 있고, 4개의 서브넷이 구성되어 있다. 그리고 메인 라우팅 테이블 1개와, 네트워크 컨트롤 리스트 1개, 보안그룹 1개가 구성되어 있다. default VPC는 모두 인터넷 게이트웨이를 갖고 있다. 즉 외부인터넷과 통신이 가능하다.

라우팅 테이블은 서브넷 레벨의 설정이다. 4개의 서브넷은 하나의 라우팅 테이블에 연결이 되어 있다. 라우팅 테이블 설정을 살펴보면 172.31.0.0/16 이 local이라고 되어 있다. 즉 VPC 내부는 서로 통신이 가능한 상태라고 할 수 있다. 그리고 그외 아이피 대역은 (0.0.0.0/0)은 인터넷 게이트 웨이를 통해서 통신을 하라고 설정이 되어 있다.

이렇게 인터넷 게이트웨이를 통해서 외부 인터넷과 통신이 가능한 서브넷을 퍼블릭 서브넷이라고 하는데 디폴트 VPC의 서브넷들은 모두 퍼블릭 서브넷으로 구성되어 있다.

네트워크의 흐름제어를 위해서 NACL(나클)을 사용할수 있다. 나클은 상태를 저장하지 않는 방화벽의 역할을 수행한다. 그리고 라우팅 테이블과 마찬가지로 서브넷 단위의 설정이다. default VPC에서는 4개의 서브넷이 동일한 나클 하나를 바라보고 있도록 되어 있다. 나클은 상태를 저장하지 않기 때문에 인바운드 및 아웃바운드를 모두 설정해줘야 한다. 기본설정으로는 모든 인바운드/아웃바운드 트래픽을 허용하도록 되어 있다. 나클 설정된거를 보면 앞쪽에 rule 번호가 적혀있는데 숫자가 작을수록 우선순위가 높다. 예를 들어서 100번룰에서 112.112.112.112 아이피를 허용했는데 1000번룰에서는 똑같은 조건의 아이피를 거부를 했더라도 100번룰이 우선순위가 높기 때문에 112.112.112.112 아이피는 허용된다.

default VPC에서 설정된 보안그룹은 같은 보안그룹에 포함되어 있는 경우에 서로 통신이 가능하도록 설정되어 있다. 보안그룹은 나클과 다르게 상태저장 방화벽이기 때문에 인바운드를 설정하였다면 아웃바운드는 따로 설정하지 않아도 된다. 그 반대의 경우에도 동일하게 동작한다.

2 ) 보안 강화된 네트워크 위한 VPC 설계 전략

VPC를 실제 운영환경에 사용하기 위해서는 default VPC보다는 VPC를 새로 구성하는 것을 권장한다.

먼저 CIDR에 대해서 알아보자. CIDR은 아이피 주소대역을 a클래스, b클래스, c클래스 이러한 방식으로 나누지 않고 클래스 없이 유연하게 네트워크 영역을 나누어 아이피 주소를 할당하는 방식을 말한다. 192.168.0.0/16를 예를 들어서 알아보자. 첫부분 16비트는 네트워크 라우팅을 위한 주소를 의미한다. 아이피주소는 여덟자리 이진수 4개를 사용해서 표현하게 되는데 앞에서부터 16개를 네트워크 주소로 쓰겠다는 의미이다. 그리고 네트워크 주소 뒤에는 호스트 주소로 사용될수 있다는 것이다. 즉, 192.168.0.0 부터 ``192.168.255.255` 까지의 호스트 주소 대역을 사용하겠다는 의미이다. 숫자로 보면 65534개의 호스트 주소를 사용할수 있다.

VPC 설정할때 가장먼저 고민하는 부분이 VPC에 사용할 아이피 대역 사용을 정의하는 것이다. VPC는 IPv4와 6 모두 지원하게 되는데 4의 경우 16비트부터 28비트까지 넷마스크를 허용하고 있다. 네트워크 주소대역 설정은 RFC 1918에서 정의하고 있는 사설 아이피 대역 사용을 권장하고 있다.

일반적으로 사설아이피 대역을 왜 사용할까? 이유는 단순하다. 퍼블릭 아이피 주소 대역이 부족하기 때문이다. 또한 VPC 내에 EC2나 RDS 또는 대량의 컨테이너들이 배포되어 있다면 이들간의 통신을 위해서는 많은 아이피 주소가 필요하기 때문에 사설 아이피 대역을 사용한다면 쉽게 아이피 주소를 할당할수 있다. 다른 이유로는 보안때문이다. VPC 내에서는 리소스들끼리 프라이빗 주소로 통신하게 되므로 외부에서의 접근이 원천 차단된다는 보안상 이점이 있다. VPC의 아이피 대역은 한번 설정하면 변경할수 없지만 대역추가는 가능하다. 만약에 아이피 v6를 사용한다면 사이즈가 정해져서 나오게 된다. IPV6는 VPC 대역은 /56로, 각 서브넷은 /64로 고정된다. 아래와 같이 서브넷마다 예약된 IP 주소가 있는데 이들은 피해서 사용해야 한다.

다음으로 고려해야하는게 적절한 서브네팅이다. VPC 아이피 할당받은 대역을 하나의 라우팅 대역으로 관리한다면 라우팅에 부담을 줄수 있다. 그래서 VPC의 대역을 계층적 구조를 활용해서 네트워크를 쪼개서 관리할 수 있다. 이를 서브네팅이라고 한다. 예를 들어서 VPC의 아이피 대역을 10.0.0.0/16로 설정하였다고 가정하자. 서브넷을 하나의 가용영역에 할당하고 10.0.0.0/18로 지정하는 경우 이 서브넷의 경우 10.0.0.0 ~ 10.0.64.255까지 총 18382개의 호스트 주소를 할당하겠다는 의미이다.

네트워크를 쪼개는 단위는 용도 및 같은 네트워크 공간에 몇대의 서버를 배치할것인가를 고려하고 설정하면 된다. 서브넷 단위로 가용영역, 라우팅 테이블 및 나클을 설정할 수 있다.

VPC 서브넷 설정 모범사례를 알아보자.

먼저 외부 인터넷과 통신이 가능한 퍼블릭 서브넷과 외부 인터넷 통신을 제한하는 프라이빗 서브넷을 아래와 같이 분리할 수 있다. 퍼블릭 서브넷을 다이렉트로 외부 인터넷과 양방향 통신이 가능하므로 필요한 경우가 아닐경우 서버를 배치하지 않는 것이 좋다. VPC를 통해 배포된 서버들이 외부 인터넷으로 노출되는 것을 최소화 할 수 있다. 서브넷은 상황에 따라 더 잘게 쪼갤수도 있다.

서브넷으로 아이피 대역을 분리한 후에 라우트 테이블과 연결하여 네트워크의 흐름을 제어할 수 있다. 먼저 퍼블릭 서브넷을 살펴보면 연결된 라우팅 테이블에 VPC에서 사용하는 아이피 대역 외에 모든 트레픽을 인터넷 게이트웨이로 라우팅 되도록 설정한다. 인터넷 게이트웨이는 VPC와 외우 인터넷간에 통신을 할 수 있게 해준다. 이 서브넷에 있는 인스턴스의 경우 프아이빗 아이피와 퍼블릭 아이피 두개를 할당하게 된다. 외부에서는 이 인스턴스를 퍼블릭 아이피로 구분할 수 있고 인터넷 게이트웨이를 통해서 외부와 다이렉트로 통신이 가능하다. 이 퍼블릭 서브넷에서는 서버 또는 서비스가 외부 인터넷망과 양방향 통신이 가능한가 여부를 확인하여 필요한 경우 이 퍼블릭 서브넷에 배포하면 된다. 예를 들어서 NLB가 내가 제공하는 서비스와 외부 인터넷과의 접점역할을 해야한다면 외부에 사용자가 NLB의 퍼블릭 주소로 접근이 가능하도록 퍼블릭 서브넷에 배포를 해줘야 한다.

VPC 내부에서만 네트워크 연결이 필요한 경우에는 인터넷과 다이렉트로 연결이 되지 않도록 프라이빗 서브넷에 인스턴스를 배포하면 된다. 아무것도 설정이 안된 프라이빗 서브넷의 라우팅 테이블을 보면 로컬 설정만 되어 있는데 프라이빗 서브넷에 배포가 될 서버라 하더라도 서버 패치나 기나 필요한 경우에 따라 인터넷과 제한된 연결이 필요할 수 있다. 프라이빗 서브넷에 배포된 인스턴스가 외부 인터넷과 통신하기 위해서는 두가지가 필요하다. 하나는 트래픽이 외부 인터넷으로 나갈 수 있도록 설정해야하고, 다른 하나는 이 프라이빗 서브넷에 있는 인스턴스들은 사설 아이피 주소만 할당되어 있기 때문에 외부 인터넷으로 나갈때 통신이 가능한 퍼블릭 아이피가 필요하다. 이때 NAT 게이트웨이를 사용하면 된다. 퍼블릭 서브넷에 NAT 게이트웨이를 배포하고 프라이빗 서브넷에 할당된 라우팅 테이블에 로컬 아이피 대역 이외의 트래픽은 NAT 게이트웨이로 나가도록 설정하면 된다.

설정을 완료하면 네트워크의 흐름은 아래와 같이 될 것이다. 프라이빗 서브넷의 인스턴스는 외부 인터넷의 어떤 서버와 통신을 위해서 먼저 라우팅 테이블의 설정에 따라서 로컬 아이피 대역과 통신하는게 아니기 때문에 트래픽을 NAT 게이트웨이로 라우팅하게 된다. NAT 게이트웨이는 이 NAT 게이트웨이에 할당된 퍼블릭 주소를 가지고서 외부 인터넷에 이 라우팅된 트래픽을 보내게 된다. 외부 인터넷의 그 서버와 통신후 결과 트래픽이 다시 NAT 게이트웨이로 전달되면 NAT 게이트웨이는 이 결과를 프라이빗 아이피로 전환하여 프라이빗 서브넷의 서버로 보내게 된다.

고가용성이 필요한 경우에는 다른 가용영역에도 동일하게 환경을 구성하면 된다.

RDS와 같이 디비의 경우 패치작업 등 외부 인터넷과 전혀 통신할 필요가 없다면 아래와 같이 VPC 내부와만 통신이 가능하도록 설정하면 된다.

VPC 나클설정의 경우 any to any로 일반적으로 사용하게 되는데 서브넷 레벨로 특정 아이피 대역을 거부할 수 있다. 예를 들어서 퍼블릭 서브넷에서 디도스 공격을 받았다고 한다면 디도스 공격을 해오는 아이피 주소를 나클에서 deny 하도록 설정하여 서브넷 내의 리소스들을 보호할 수 있다.

그러면 VPC에서 보안그룹에 대한 모범사례를 알아보자.

아래에 퍼블릭 서브넷의 NLB에 적용된 보안그룹을 보면 HTTP(S) 서비스를 위해서 모든 트래픽에 대해서 들어오는 아이피 대역의 접근을 허용하고 있다.

하지만 프라이빗 서브넷에 위치한 웹서버는 NLB에서 들어오는 네트워크 트래픽만 허용하도록 설정할 수 있다. 보안그룹의 특징중에 하나가 각각의 보안그룹이 서로를 참조할 수 있다는 것이다. 이러한 특징을 활용해서 프라이빗 서브넷의 웹서버 보안그룹에는 퍼블릭 서브넷의 NLB가 포함된 보안그룹 자체를 rule에 적용하였다.

RDS가 포함된 보안그룹은 웹서버가 포함된 보안그룹을 허용하도록 rule을 추가하면 된다.

3 ) Hybrid Networking

VPC와 외부 네트워크와의 연결방법에 대해 알아보자.

VPC는 독립된 가상환경의 네트워크 서비스이다. 그래서 VPC 외부에 있는 다른 AWS의 서비스들은 퍼블릭 인터넷과 동일하게 트래픽 흐름을 제어하게 된다. 예를 들어서 아래 그림과 같이 퍼블릭 서브넷에 있는 인스턴스가 S3로 접근이 필요한 경우에 dig 명령어로 s3의 주소를 확인해보면 아이피는 예를 들어서 52.216.229.141로 확인이 되는데 이는 인스턴스가 인터넷 게이트 웨이를 통해서 퍼블릭 아이피 주소로 AWS S3에 접근을 한다는 얘기다.

그러면 AWS의 다른 서비스들과 프라이빗 통신을 하고 싶다면 어떻게 해야할까. AWS에서는 게이트웨이 엔드포인트, 인터페이스 엔드포인트(프라이빗링크)라는 리소스를 제공하여 프라이빗 통신을 가능하도록 지원한다.

S3 또는 다이나모 디비와 프라이빗 통신을 할수 있도록 AWS에서 지원하는 게이트웨이 엔드포인트가 있다. S3에서 통신할 서브넷을 선택하여 S3의 게이트웨이 엔드포인트를 (라우팅 테이블에) 추가하면 된다. VPC endpoint policy를 통해서 IAM 정책을 적용해서 접근제어를 설정할수도 있다.

다음으로는 인터페이스 엔드포인트에 대해 알아보자. 게이트웨이 엔드포인트와 마찬가지로 VPC 내부 네트워크를 통해서 AWS의 서비스와 통신이 가능하다록 도와주는 리소스이다. 게이트웨이 엔드포인트와의 차이점은 게이트웨이 엔드포인트는 S3와 다이나모 디비만 지원하는데 인터페이스 엔드포인트는 s3와 다이나모 디비를 제외한 서비스들에 대한 프라이빗 통신을 지원하게 된다. 예를 들어서 아래 그림과 같이 프라이빗 서브넷에서 SQS과 프라이빗과 통신을 하고 싶다고 하면 먼저 인터페이스 엔드포인트를 생성하게되면 프라이빗 서브넷에 네트워크 인터페이스가 만들어지게 되고 여기에 설정된 프라이빗 아이피로 SQS의 DNS 주소가 업데이트가 된다. 예를 들어서 아래 그림에 10.0.50.210과 10.0.51.148 네트워크 인터페이스가 되겠고 이거를 통해서 SQS로 통신을 하게된다. 이 인터페이스 방식은 네트워크 인터페이스의 보안그룹으로 네트워크 접근을 관리할수도 있고 VPC의 엔드포인트 policy를 통해서 접근제어도 할 수 있다.

그러면 AWS의 다른 VPC나 다른계정의 VPC와 연결하기 위해서는 VPC peering이나 transit gateway를 사용하면 된다.

두개의 VPC간의 VPC peering을 하는 경우에는 연결할 VPC에 연결을 요청후 그쪽에서 수락을하면 연결이 되게 된다. 이때도 라우팅 테이블에 연결한 VPC의 정보를 추가해줘야 한다.

만약에 4개의 VPC가 있다고 가정하자. VPC1과 VPC2가 상호간에 통신을 위해서 peering이 필요하다. 마찬가지로 VPC 1과 3이 통신을 하기 위해서 피어링을 했다고 하자. 그리고 1과 4도 피어링을 했다고 하자. 아래 그림과 같은 형태로 피어링이 된건데 이때 VPC4와 VPC2는 통신이 가능할까?? VPC 피어링은 VPC4 –> VPC1 –> VPC2로 가는것을 허용하지 않는다. 그렇기 때문에 VPC2와 VPC4가 통신이 필요하다면 이 둘간에도 피어링을 해줘야 한다.

다시말해서 다수의 VPC간에 연결을 위해 피어링을 했다면 이는 아래와 같이 full mesh 형태가 될 것이다. 또한 이 VPC들이 VPN이나 DX를 활용해서 온프레미스 연결이 필요하다면 모든 VPC들이 개별로 VPG(Virtual Private Gateway)를 구성하고 또 연결을 각각 다 해줘야 하는 상당히 번거로운 단점이 있다. VPC가 많아지고 VPN이나 전용선 연결이 필요한 경우에 피어링을 채택한다는 것은 복잡도가 올라가고 관리도 어렵게 된다.

이런경우에 트랜짓 게이트웨이를 사용하면 위와 같은 복잡도를 확 줄일수 있다. VPC간에 복잡한 피어링 관계를 제거하여 네트워크를 간소화하게 관리할 수 있다. 예를 들어서 아래 그림과 같이 VPC1,2,3,4가 같은 트랜짓 게이트웨이에 물려있다면 이 4개의 VPC들끼리는 서로 통신이 모두 가능하게 된다. 또한 전용선 및 VPN 연결도 트랜짓 게이트웨이를 연결해주면 모든 VPC와 연결될수 있다. 이외에도 트랜짓 게이트웨이는 ECMP나 멀티캐스트 기능을 추가적으로 제공하고 있다.

만약에 사내 데이터 센터와 연결을 한다면 어떤 서비스를 활용하면 좋을까. VPN과 Direct Connect를 활용하면 된다.

우선 VPC에 다이렉트하게 VPN이나 DX를 연결하는 경우 VPC에서는 Virtual private gateway를 활용해서 연결할 수 있다. 간단하게는 VPC의 VGW를 활용해서 site to site VPN 기반으로 VPN을 연결하는 방식이 있다. 자동으로 터널이 2개가 열려서 하나는 active, 다른하나는 standby로 연결된다. VPC에서는 사설아이피 경로를 라우팅 테이블에 추가하여 구성을 완료하게 된다. 이렇게 데이터 센터와 VPC간에 전용선을 연결할 수 있다.

보다 안전한 네트워크 밴드위스가 필요하다면 온프라미스 데이터센터에서 전용선을 연결할 수 있다. DX에서는 프라이빗 VIF라는 물리적 터널을 통해서 VPC의 VGW와 연결할수 있다. 만약에 4개의 VPC와 연결이 필요하다면 Private VIF를 4개 생성하고 물리적으로 각각 따로 연결할 수 있다. 다수의 VPC와 연결이 필요하다면 트랜짓 게이트웨이를 활용해서 4개의 VPC를 트랜짓 게이트웨이에 연결하고 이 트랜짓 게이트웨이에 하나의 DX Transit VIF를 생성해서 전용선으로 연결하도록 구성하면 된다. site to site VPN을 연결하는 경우에도 VGW만 연결하면 간단하게 전용선 연결을 할 수 있다.

지금까지 배운 기본적인 VPC 구성의 아키텍처는 아래와 같다.