포스트

[EC2] EC2 시작하기 (VPC, Subnet 설정 등...)

AWS / EC2

AWS의 EC2를 시작하기 위한 다양한 보안 설정법과 네트워크에 관련된 개념을 정리

Spring, Django, Node.js와 같은 웹 프레임워크를 서버에서 실행할 때, 우리는 AWS에서 제공하는 서비스를 이용하여 클라우드 환경에서 쉽고 빠르게 구축할 수 있다.

AWS 계정 접속 후, 콘솔을 이용하여 서버(EC2)를 생성하는 것은 전혀 어렵지 않으며, 생성 과정에서 선택할 것이 많아 복잡해 보이지만, 모든 값을 AWS가 제공하는 기본값으로 선택한다면 아주 간편하고 빠르게 서버 생성이 가능하다.

ecc_2 인스턴스 생성

EC2 생성을 완료했다면, 웹 서버를 실행시키기 위해 해당 서버에 코드를 적재하는 과정이 필요하다.

제일 간한히 코드를 적재하기 위해서 GitHub에 올린 프로젝트를 git clone으로 다운로드 한 뒤, 실행시긴다고 가정하겠다.

이 경우에는 다음과 같은 2가지 문제가 발생한다.

  1. CLI를 입력하기 위한 SSH 터미널 연결 설정
  2. git clone으로 코드를 다운로드하기 위해 인터넷 망과 EC2 연결

AWS가 제공해주는 기본값으로만 인스턴스를 생성했다면 당연히 이 과정에서부터 막히게 된다.

여기서 나오는 용어들로는 VPC, Subnet, ACL, CIDR 등의 어려운 용어들이 너무 많이 나온다.

이러한 용어들을 알아보고 각 용어들의 개념을 정리하는 것이 이 글의 목적이며, 웹 서비스를 운영하기 위해 필요한 최소한의 AWS 인프라의 지식을 쌓기 위해 해당 게시글을 작성한다.

보안 그룹 (Security Group)

처음에 생성한 인스턴스와 같이 기본값으로만 인스턴스를 생성했다면, 모든 외부로부터의 입력이 차단된 Private 상태로 생성된다.

이렇게 생성한 서버는 SSH 터미널로 접속이 불가능하며, 콘솔로 작업을 한다고 하더라도 Inbound 포트가 열려있지 않아서, 서버로써의 동작을 수행할 수 없다.

따라서, 인스턴스는 내부/외부의 통신 중 어떤 것을 받아들이고 차단할지에 대해 규칙을 설정하는데 이를 AWS에서는 보안 그룹(Security Group)이라고 한다.

보안 그룹 (Security Group)의 특징

ecc_3 Inbound rules set

보안 그룹은 인스턴스 레벨의 접근을 제어한다.

또한 인바운드/아웃바운드 통신을 모두 제어할 수 있지만, Stateful 성질 때문에 일반적으로는 인바운드 룰만 설정한다.

Stateful 성질이란?

인바운드 룰로 허용된 경우, 해당 트래픽에 대하여 세션 테이블로 기억 후, 아웃바운드로 되돌아 갈때도 자동 허용하는 룰을 말한다.

인바운드 포트 열어주기

ecc_4

보안 그룹은 인스턴스 레벨의 통신 규칙을 정하므로 AWS 매니지드 서비스, EC2와 연결이 필요하다면 각 인스턴스마다 설정해줘야 한다.

위의 이미지는 로드 밸런서(Load Balancer)와 EC2, 그리고 MySQL의 3가지 인스턴스 사이에서 보안 그룹으로 인바운드 포트를 열어주는 과정이다.

그렇다면 SSH 접속을 허용하기 위해 보안 그룹 인바운드 룰에 22번 포트와 소스 IP를 지정해주면 된다.

특이사항으로 인스턴스와 보안 그룹의 관계는 1 : N으로 필요 시, 하나의 인스턴스에서 다수의 보안 그룹을 지정해줄 수 있다.

그렇다면, 이제 보안 그룹을 지정했으니 GitHub에서 코드를 다운받을 수 있는가?

답은 NO이다.

아직 EC2는 인터넷 망과 연결이 되어있지 않은 상태이기 때문에 불가능하다.

보안 그룹에서 아웃바운드 룰을 설정하지 않았다고 모두 허용되는 것이 아니기 때문에 인터넷 연결이 되지 않는 것이다.

EC2의 상위 개체에서 설정할 것이 더 필요하다.

서브넷 (Subnet)

서브넷(Subnet)은 EC2 인스턴스들을 모은 상위 집합에 해당하는 개념이다.

ecc_5 위의 이미지처럼 하나의 서브넷에 다수의 EC2를 소유할 수 있다.

서브넷의 중요한 목적은 가용 영역(Availability Zone)을 설정하여 장애가 발생하더라도 서비스를 지속시키는 것이다.

하나의 서브넷은 하나의 가용 영역에 속하며, 인스턴스보다 넓은 범위의 권한을 가지고 있다.

또한 목적에 따라 내부 통신만 가능한 Private 서브넷으로 설정할 수도 있다.

추가적인 설명은 #서브넷 & 서브넷 마스크란?

Network ACL (Access Control List)

Network ACL(Access Control List)는 서브넷 단위의 트래픽 제어 주체를 말한다.

NACLEC2에 접근하기 전, 서브넷 레벨에서의 네트워크 룰을 정한다.

ecc_6 NACL 구조

Network ACL (Access Control List)의 특징

EC2 인스턴스 보안 그룹 설정과는 상관없이 In/Out되는 모든 트래픽에 대해 제어한다, 최초 생성 시, AWS 기본값은 모든 In/Out 트래픽을 허용한다.

또한 Stateless하기 때문에 아웃바운드 룰을 설정해줘야 한다.

Stateless하다의 의미

허용된 Inboud 트래픽에 대해서도 Outbound 포트까지도 명시적으로 해용해야 통신이 가능하다는 의미이다.

NACL의 룰은 번호를 통해 우선순위를 정한다.

낮은 번호의 정책부터 평가되며, 명시적으로 ALLOW/DENY되는 정책까지 Overriding 되는 방식으로 정책이 평가된다.

최대 32,766번의 정책 지정이 가능하며, 초기엔 100단위로 설정하는 것이 추천된다.

ecc_7

즉, 100, 200번 룰에서 동일한 룰을 작성했다면, 200번 룰만 적용된다.

이제 아웃바운드 룰을 통해 인터넷 망을 지정하면 EC2 인스턴스에 준비해둔 서버에서 인터넷 연결이 가능한가?

아직 답은 NO이다.

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

NACL은 서브넷에서의 통신만 관련이 있을 뿐, 실제로 인스턴스가 인터넷 연결을 하기 위해선 인터넷 게이트웨이를 이용해 통신한다.

ecc_8

인터넷 게이트웨이(Internet Gateway)는 서브넷 바깥에 위치해 있으며, 후술할 VPC 단위에서 관리된다.

라우팅 테이블 (Routing Table)

생성된 인터넷 게이트웨이를 사용하기 위해 서브넷이 인터넷 게이트웨이와 연결되어야 한다.

이런 작업을 하는 서비스가 라우팅 테이블(Routing Table)이다.

  • 서브넷 간의 라우팅(연결) 설정
    ecc_9
    모든 라우팅 테이블에는 VPC 내부 통신을 위한 로컬 라우팅이 포함되어 있다.
    이 라우팅은 기본적으로 모든 라우팅 테이블에 추가되며, 삭제가 불가능하다.
    라우팅 테이블에 인터넷 게이트웨이를 할당하여 외부 인터넷과의 연결이 가능하다.
    외부 인터넷과의 연결이 가능한 라우팅 테이블이 설정된 서브넷은 Public하며, 아닌 경우는 Private 서브넷이라고 부른다.

서브넷은 라우팅 테이블과 N(서브넷) : 1(라우팅 테이블)의 관계이며, 하나의 라우팅 테이블을 여러 개의 서브넷에 연결시킬 수 있다.

VPC (Virtual Private Cloud)

위의 서브넷, 라우터, 인터넷 게이트웨이 설정에서 한 가지 중요한 문제가 있다.

바로 각 인스턴스가 어떤 IP 주소를 가지고 있느냐는 것이다.

라우터를 지나는 패킷들은 모두 Source IP, Destination IP가 지정되어 있어야 올바르게 NACL, 보안 그룹의 인바운드 룰을 거치며 인스턴스에 도착할 수 있다.

이러한 IP 주소를 AWS에서는 사설 망 형태로 제공한다.

이러한 사설 망을 가진 커다란 하나의 단위를 VPC(Virtual Private Cloud)라고 하며, 이는 마치 독립된 클라우드 환경으로 여겨진다.

VPC (Virtual Private Cloud)의 특징

ecc_10

하나의 구역처럼 여겨지는 독립된 가상의 클라우드 네트워크이다.

계정 생성 시, Default VPC가 1개가 할당되지만, 별도의 커스텀 VPC를 추가하여 작업하는 것이 좋다.

또한 VPC 내의 모든 인스턴스들은 VPC 내에서 통용되는 Private IP가 부여된다.

만약 외부로 공개할 IP가 필요하다면, EC2Public IP 또는 Elastic IP 할당이 가능하다.

  • Public IP
    재시작 시, IP가 변경됨
  • Elastic IP
    재시작 시, IP가 변경되지 않음

VPC 없이 클라우드를 구성할 수 있을까?

VPC를 사용하지 않는 서비스로만 구성할 수는 있다.

하지만, 서버리스 서비스인 LambdaVPC 내부에 생성이 필요하며, 사실상 VPC는 거의 모든 서비스에 필수인 셈이다.

서브넷이 EC2를 묶은 개념이라면, VPC는 굳이 필요한가?

ecc_11

VPC 이외에 서브넷을 추가로 설정한 이유는 가용 영역(Availability Zone)을 설정한다는 점에 있다.

각 Region의 VPC는 가용 영역을 할당받게 되고, 서브넷 생성 시, 가용 영역을 설정하여 서비스 신뢰도를 높일 수 있다.

그렇다면 Private IP는 임의로 부여되는 것인가?

Private IPVPC를 생성할 때에 CIDR를 입력하여 블록을 지정해줄 수 있다.

CIDR (Classless Inter-Domain Routing)

쉽게 사이더라고 부를 예정이며, 추가적인 설명은 #CIDR이란? 참고

사이더란, 클래스 간의 구분을 하지 않는다는 개념이다.

ecc_12 Classful addresing IPv4

위의 이미지처럼 최초 설계된 Classful 방식은 네트워크 구분을 A, B, C와 같이 클래스 형태로 구분하기 떄문에 IP 고갈 현상이 발생했다.

이러한 IP 고갈 현상을 해소하기 위해 등장한 개념이 사이더로, 서브넷 마스크와 동일한 뜻이다.

  • IP 뒤에 192.168.10.0/24에서 /24와 같은 것이 사이더 표기법이다.
  • 143.7.65.203/24라고 표현되었다면, 24비트 이후에 오는 4번째 옥텟1을 전부 사용할 수 있다는 표현이다.
  • 143.7.65.0 ~ 143.7.65.255까지 사용이 가능하다는 뜻이다.
  • VPC 생성 시에는 사이더 블록으로 반드시 지정해야 하며, 공인 IP와의 충돌을 방지하기 위해 사이더 블록은 RFC 1918에서 정의한 Private 대역을 사용할 것이 권장된다.
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 한 번 생성된 CIDR는 변경이 불가능하다.
    • 따라서 IP 중복을 고려, 필요에 따라 CIDR 블록 숫자를 조절하여 서브넷팅(더 적게 쓰기) or 슈퍼넷팅(더 많이 쓰기) 할 수 있다.
  • AWS의 모든 사이더 블록에서 5개의 IPReserved이며, 사용할 수 없다.

어차피 CIDR 블록의 내부 IPVPC 내부에서만 쓰일 텐데, IP 중복을 고려할 필요가 없지 않은가?

VPC Peering 이라는 서로 다른 VPC 간의 통신 서비스가 존재한다.

이 서비스를 사용 시, Peering 연결 방식(active, pending-acceptance)에 따라 CIDR 블록 중복 이슈가 발생할 수 있다.

사설망 (프라이빗 네트워크)

사설망 또는 프라이빗 네트워크(Private Network)는 인터넷 어드레싱 아키텍쳐에서 사설 IP 주소 공간을 이용하는 네트워크이며, RFC 1918RFC 4193 표준을 준수한다.

이러한 주소는 가정, 사무실, 기업 랜(Lan)에 쓰인다.

  • 사설 IPv4 주소 공간
    IETF2RFC 1918에 출판된 대로 다음의 IPv4 주소 범위를 사설망에 보존하기 위해 IANA3를 지도하고 있다.
    RFC 1918 이름IP 주소 범위주소 개수클래스 내용최대 사이더 블록 (서브넷 마스크)호스트 IP 크기
    24비트 블록10.0.0.0 - 10.255.255.25516,777,216클래스 A 하나10.0.0.0/8 (255.0.0.0)24비트
    20비트 블록172.16.0.0 - 172.31.255.2551,048,57616개의 인접 클래스 B172.16.0.0/12 (255.240.0.0)20비트
    16비트 블록192.168.0.0 - 192.168.255.25565,536256개의 인접 클래스 C192.168.0.0/8 (255.255.0.0)16비트

VPC Peering, VPC Endpoint

VPC 내부에 존재하는 인스턴스들끼리는 라우터를 이용하여 통신한다는 것을 위의 설명을 통해 알게 되었다.

그렇다면 다른 VPC 혹은 외부의 온프레미스와의 통신은 어떻게 할 수 있을까?

ecc_13 VPC Peering

위의 이미지와 같이 VPC Peering은 리전/AWS 계정에 상관없이 VPC 간의 통신을 지원하는 서비스이다.

VPC Peering이 진행되면, 하나의 VPC처럼 취급되는 만큼 라우팅 테이블을 이용하여 서브넷 간의 연결을 할 수 있다.

ecc_14 VPC Peering

위의 이미지처럼 만약 VPC 외부에 있는 서비스와 통신이 필요하다면, VPC Endpoint를 사용할 수 있다.

VPC Endpoint를 이용하면 인터넷망이 아닌 안전한 연결이 보장된다.

이외에도, 연결 주체에 따라 #Direct Connect, #VPN Connections와 같은 방식으로 연결하는 등, 서비스마다 제공하는 방식으로 연결할 수 있다.

Route 53

VPC에 서브넷과 EC2 인스턴스를 생성했다면, 이제 EC2에 접속하기 위해서는 공인 IP를 할당 받은 뒤, 보안 그룹 Inbound 룰을 설정하여 SSH 접속을 하면 된다.

하지만, 당연히 일반 사용자들이 IP를 이용해서 서버에 접속하지 않는다.

인터넷 상의 서비스들은 모두 도메인을 가지고 있으며, 도메인 주소는 DNS(Domain Name System) 과정을 가지며 IP를 휙득 후, 해당되는 주소로 접속하게 된다.

AWS에서 제공하는 Route 53은 이러한 도메인을 구입/등록할 수 있는 서비스4이다.

Route 53에 도메인을 등록하면 해당 도메인은 SLD 업체 → TLD 업체를 거치며 도메인으로 등록되게 되고, ISP(Internet Service Provider) 통신사 네임 서버에 캐시로 일정 기간 동안 보관5된다.

DNS에 등록된 도메인 주소가 존재할 시, 사용자 OSDNS Resolver가 도메인으로부터 IP 주소를 휙득할 수 있으며, 그제서야 EC2 인스턴스로 접속을 하여 원하는 리소스를 가져올 수 있다.

Route 53에서는 도메인의 하위 도메인 트래픽을 라우팅하며, A 레코드를 생성 후, 로드 밸런서와 연결할 수 있다.

로드 밸런서와 연결되는 EC2Elastic IP(탄력적 IP)6를 사용할 수 없음에 주의해야 한다.

참고 사이트

말랑카우 - 초보자를 위한 AWS VPC, Subnet, EC2 개념 정리

위키백과 - 사설망


  1. 컴퓨팅과 전기 통신에서 8개의 비트가 한데 모인 것을 말하며, “정확하게 8비트”임을 명시해야 하는 경유애 사용하는 용어이다. (Byte와 같은 용어로 취급) ↩︎

  2. 국제 인터넷 표준화 기구 ↩︎

  3. 인터넷 할당 번호 기관 ↩︎

  4. 정확히는 GandiAuthoritative 업체의 리셀러 ↩︎

  5. 보통 2일이 걸린다. ↩︎

  6. 탄력적 IP 주소는 동적 클라우드 컴퓨팅을 위해 고안된 정적 IPv4 주소로, 탄력적 IP 주소는 AWS 계정에 할당되며 릴리스할 때까지 할당된 상태로 유지된다. ↩︎

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.