Amazon VPC Basics

VPC 파헤치기!

References: Amazon VPC docs, 44bits.io

What is Amazon VPC?

사용자가 정의한 가상 네트워크 (Virtual Private Cloud)

• VPC는 기존 서버 호스팅과 차별화된 중요한 특징들이 있다

  • VPC를 사용하면 네트워크 환경을 직접 설계할 수 있다

• VPC에서 IPv4와 IPv6를 모두 사용하여 리소스와 애플리케이션에 안전하고 쉽게 액세스할 수 있다

• VPC는 논리적으로 격리된 공간을 프로비저닝 한다

  • 하나의 계정에서 생성하는 리소스들만의 격리된 네트워크를 만들어주는 기능이 VPC!!

    • VPC를 사용하면 특정 사용자의 리소스들이 논리적으로 격리된 네트워크에서 생성되기 때문에 다른 사람들은 접근하는 것은 물론 보는 것도 불가능하다!

  • EC2-클래식 네트워크 환경은 다른 사용자들과 함께 사용하는 공용 공간

    • 과거에는 EC2-클래식과 EC2-VPC 네트워크 환경을 선택해서 사용할 수 있었음!! (그랬군..)

    • 현재 AWS에서는 AWS 계정을 생성할 때 리전 별로 기본 VPC를 함께 생성

      • 기본 VPC를 사용하면 아마존 VPC를 크게 의식하지 않더라도 EC2-클래식 네트워크를 사용하듯이 쉽게 AWS에서 제공하는 서비스들을 이용할 수 있음

      • 기본 VPC를 사용하더라도 EC2-클래식과 달리 격리된 네트워크 환경의 장점을 누릴 수 있다!

VPC의 구성 요소들

1. VPC

• 프라이빗 클라우드를 만드는 데 가장 기본이 되는 리소스

• 논리적인 독립 네트워크를 구성하는 리소스

  • 이름과 IPv4 CIDR 블록을 필수적으로 가짐

    • CIDR (Classless Inter-Domain Routing) 블록

      • IP의 범위를 지정하는 방식

      • 구성

        • IP 주소

        • / 뒤에 오는 넷마스크 숫자

          • IP 범위를 나타냄

            • 이 숫자가 32이면 앞에 기술된 IP 정확히 하나를 가리킴

            • ex) 192.168.0.0/32는 192.168.0.0을 가리킴

            • 범위는 지정된 IP부터 2^(32-n)개

              • ex) 뒤의 숫자가 24라면, 2^(32-24)=256개의 IP 주소

              • ex) 192.168.0.0/24는 192.168.0.0에서 192.168.1.255까지의 IP

• 클라우드에서 생성하는 자원들은 기본적으로 특정 네트워크 위에서 생성되며 이에 접근하기 위한 프라이빗 IP를 가짐

  • 이 리소스들은 특정한 VPC 위에서 만들어진다!

    • VPC의 CIDR 범위 안에서 적절한 IP를 할당 받게 됨

    • ex) 192.168.0.0/24 CIDR 블록을 가진 VPC에서 생성한 EC2 인스턴스는 192.168.0.127이라는 IP를 할당 받을 수 있음

  • VPC의 범위 내에서 할당 가능한 IP가 모두 할당되면 더 이상 리소스를 만들 수 없음

    • 적절한 크기의 VPC를 만들어야함!!

      • VPC의 최대 크기는 16 (넷마스크)

        • 2^(32-16)=65536 개의 IP 사용 가능

• VPC를 만들 때 또 하나 고려해야할 점!

  • CIDR의 범위를 지정하는데 특별한 제약은 없지만, 인터넷과 연결되어 있는 경우 문제가 발생할 수 있음

    • ex) 이건 그냥 참고만!

      예를 들어 52.12.0.0/16을 CIDR 블록으로 지정한 경우를 생각해보겠습니다. 이 VPC에서 52.12.0.0/16로 접속하는 트래픽은 VPC 내부로 라우트 됩니다. 그런데 이 범위의 IP는 인터넷에서 사용할 수 있는 IP입니다. 따라서 이 VPC에서는 52.12.0.0/16에 속한 인터넷 IP에 접근하는 것이 원천적으로 불가능합니다. 인터넷 연결이 필요한 경우 반드시 사설망 대역을 사용해야 하며, 인터넷 연결이 필요하지 않더라도 가능하면 사설망 대역을 사용하는 것을 권장합니다. 사설망 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16가 있습니다.

  • VPC는 독립된 네트워크 환경으로 구성되기 때문에 CIDR이 같거나 겹치더라도 생성하는 것이 가능

    • 추후에 다수의 VPC를 함께 사용하는 경우 IP 대역이 겹치면 문제가 발생할 수 있음

      • VPC를 만드는 것은 쉽지만 한 번 만들고 나면 기존 CIDR을 변경하는 것은 불가능

        • 변경 불가, 새로운 CIDR 추가는 가능

      • 문제 생겨서 VPC 내부 자원 이동하게 되면 힘드므로

        • 프로덕션 환경을 구축할 때는 VPC 제약사항들을 충분히 이해하고 CIDR을 정하는 것이 좋다!!!!!

          • 기본 VPC의 CIDR 블록은 172.31.0.0/16

2. 서브넷 (Subnet)

• VPC만 가지고는 아직 아무것도 할 수 없음

  • VPC는 다시 한 번 CIDR 블록을 가지는 단위로 나눠진다

• 서브넷은 실제로 리소스가 생성되는 물리적인 공간인 가용존 (AZ: Available Zone)과 연결

  • VPC 가 논리적인 범위를 의미한다면,

  • Subnet은 VPC 안에서 실제로 리소스가 생성될 수 있는 네트워크

    • 다른 서비스의 resource 를 생성할 때 VPC만 지정하는 경우는 없다!

      • VPC 와 Subnet을 모두 지정하거나

      • Subnet을 지정하면 VPC 는 자동적으로 유추되기도 한다!

• 하나의 VPC 는 N개의 Subnet을 가질 수 있다

  • Subnet 의 최대 크기 == VPC 크기

  • VPC 와 동일한 크기의 Subnet을 하나만 만드는 것도 가능

  • subnet을 만들지 안을 수도 있지만, 이 경우 VPC 로 아무것도 할 수 없음

  • 일반적으로 사용할 수 있는 AZ를 고려해서 적절한 크기의 Subnet들을 AZ 수만큼 생성해서 사용

    • N 개의 AZ만큼 Subnet을 만들어 리소스를 분산하면 재해 대응 측면에서도 유리함!!

      • ap-northeast-2 (Asia Pacific Seoul) 에는 4개의 AZ 가 있음! - 07.17.2020

        • AWS region에 위치한 AZ는 백업 전원 장비, 네트워킹 및 인터넷 연결 기능이 있는 별도 시설을 갖춘 한 개 이상의 개별 데이터 센터로 구성됨

• Subnet의 netamask 범위는 16 (65535 개) 에서 28 (6개)을 사용할 수 있음

• VPC CIDR block 범위에 속하는 CIDR block을 지정 할 수 있음

  • 하나의 subnet은 하나의 AZ와 연결

    • 1 subnet - 1 AZ

  • Region에 따라서 사용 가능한 AZ의 개수는 다르다

    • 보통 2개 이상

    • 우리 서울은 4개! 짝짝짝!

  • 재해 대응을 위해 AZ만큼 subnet을 나누는 경우 특정 region 에서 사용 가능한 가용존의 개수를 미리 확인할 필요가 있음

    • 모든 AZ를 사용하지 않더라도 2개 이상의 AZ를 사용하는 게 일반적

      • 그래서 면접 과제에 AZ (subnet) 2개 인듯

  • 기본 VPC 에서는 AZ 개수만큼 Netmask 20의 subnet을 자동적으로 생성함

+

Subnet을 2개 생성하는 이유

• 가용존 하나와 연결된 하나의 서브넷만 있더라도 EC2 인스턴스를 생성하는 것은 가능!

  • but, EC2를 비롯한 많은 AWS의 서비스에서는 멀티AZ라는 개념을 지원하고 있다

  • 하나 이상의 가용존에 유사한 리소스를 동시에 배치하는 기능

• 이렇게 하는 이유는 장애 대응과 관련이 있다!

  • 하나의 리전에는 다수의 가용존들이 있음

  • 이 가용존은 단순히 가상적으로 분리되어있는 것이 아니고, 물리적인 공간도 분리되어있다!

    • 다수의 가용존에 유사한 리소스를 배치함으로써 하나의 가용존에 문제가 생기더라도 서비스에 장애가 발생하지 않도록 설계하는 것이 가능

  • AWS에서는 리전 당 2개 이상의 가용존을 제공하고, 2개 이상의 가용존(서브넷)을 전제로 네트워크를 설계하는 것을 권장한다!

3. Route Table

Subnet과 연결되어있는 resource

• Subnet에서 network를 이용할 때 Route table 을 사용해서 목적지를 찾게 됨

  • Route table은 Subnet과 연결되어 있지만 VPC를 생성할 때 만들어지고 VPC에도 연결되어 있음

  • router table은 VPC에 속한 Subnet을 만들 때 기본 route table로 사용됨

• 하나의 route table은 VPC에 속한 다수의 Subnet에서 사용할 수 있음

• 자동 생성되는 Route table에는 한 가지 rule만 정의되어 있음

  • VPC의 CIDR block을 목적지로 하는 경우 타깃이 local 인 규칙

    • ex) VPC의 CIDR Block이 127.31.0.0/16 일 때 network 안에서 목적지가 192.31.0.0/16 범위에 있는 resource 를 찾는다면 VPC 내부에서 찾는다

    • 이 규칙은 삭제할 수 없다!!!!!

      • 인터넷을 연결하거나, 다른 VPC와 통신하기 위해서는 Route table에 Route 규칙을 추가적으로 정의해야 함!

4. 인터넷 게이트웨이 (Internet Gateway)

• VPC는 기본적으로 격리된 네트워크 환경

  • VPC에서 생성된 resource들은 기본적으로 인터넷을 사용할 수가 없음

    • 인터넷에 연결하기 위해서는 Internet Gateway가 필요하다!

• Routing table에 Internet Gateway를 향하는 적절한 규칙을 추가해주면 특정 Subnet이 인터넷과 연결됨

  • but, Subnet과 Internet Gateway 를 연결하는 것 만으로는 인터넷을 사용할 수 없다!

    • Internet을 사용하고자 하는 resource는 Public IP를 가지고 있어야 함

+

NAT 게이트웨이

: Private subnet의 인터넷을 향한 Outbound 트래픽을 허용해줌 (IPv4용)

5. DHCP Option Set

TCP/IP Network 상의 Host로 설정 정보를 전달하는 DHCP 표준

• DHCP를 사용하면

  • Domain Name Server

  • Domain Name

  • NTP (Network Time Protocol) Server

  • NetBIOS Server

    • 등의 정보를 설정할 수 있음

• 일반적으로 VPC 생성 시 만들어지는 DHCP Option set을 그대로 사용

6. Network ACL (Access Control List)

주고 (outbound), 받는 (inbound) traffic을 제어하는 가상 방화벽

• 하나의 Network ACL 은 다수의 Subnet 에서 재 사용 할 수 있음

• subnet 앞 단에서 traffic을 제어하는 역할

7. Security Group

Instance의 앞 단에서 Traffic을 제어하는 가상 방화벽

• Network ACL의 규칙을 통과하더라도 Security Group의 규칙을 통과하지 못 하면 Instance와 통신하지 못 할 수 있음

Network ACL과 Security Group 을 통해서 안전한 네트워크 환경을 구축할 수 있다 !