지난 글 https://infondgndg91.blogspot.com/2020/08/aws-vpc.html 에서 서울 리전에 VPC 및 서브넷을 생성해 보았다.
이전 글에서 만들었던 VPC 를 기준으로 인터넷 게이트웨이와 NAT 게이트웨이, 라우팅 테이블, 탄력적 IP, 네트워크 ACL, 보안 그룹을 실습 하면서 아래와 같이 정리해보겠다.
우선, 라우팅 테이블은 VPC 생성 시 자동으로 생성 된다. 기본 VPC 를 통해 확인이 가능하다.
먼저, 기본 VPC
기본 VPC 에 매핑 된 라우팅 테이블
기본 VPC 의 CIDR 블록을 172.31.0.0/16 의 대상은 local 로 기본 VPC 에 속한 모든 Subnet 에 대하여 라우팅을 제어하는 역할은 한다.

그리고 기본 VPC 가 아닌 새로 VPC 를 생성하는 것과의 차이는 바로 Internet Gateway. 기본 VPC 에는
Routing table 에 자동으로 Internet Gateway 가 붙어 있다.
Internet Gateway 가 하는 역할은 VPC 내의 Instance 와 인터넷 간의 통신이 가능하게 만들어 준다.
하지만 기본 VPC 가 아닌 새롭게 생성한 VPC 의 경우에는 Internet Gateway 가 자동으로 생성되지 않고 라우팅 테이블에 추가 되지 않기에, 새롭게 Internet Gateway 를 생성해주고 새로 생성한 VPC 라우팅 테이블에 추가해줘야 인터넷과 새로 생성한 VPC 내의 Instance 간의 통신이 가능하게 된다.
아래와 같이 Internet Gateway 를 생성하고, 새로 생성한 giri-vpc 에 attach 했다.
Destination 0.0.0.0/0 Target 은 새로 생성한 Internet Gateway 가 새로 생선한 giri-vpc 라우팅 테이블에 추가 되었다.
여기서 중요한 점은 이전 글에서 생성한 Public Subnet 과 Private Subnet 에 대해서 같이 정리해보자.
Public Subnet 은 인터넷과 연결될 수 있도록 하기 위함이고 (EX. webservers),
Private Subnet 은 인터넷과 같이 외부에서는 바로 접근이 불가능하지만, Private Subnet 안에서 밖으로의 통신은 가능하도록 하는것이 일반적이다. (EX. database, back-end server)
따라서, Private Subnet 통신은 Public Subnet 에 NAT(Network Address Translation) Gateway 를 통해서 인터넷에 엑세스 할 수 있도록 한다.
결론적으로, 위에서 생성한 Internet Gateway 를 attach 한 routing table 은 public subnet 의 routing table 이다.
그렇다면, 이제 private subnet 을 위한 routing table 에 NAT Gateway 를 attach 해보자.
아래와 같이 NAT Gateway 를 생성했다. 생성하는 과정에서 EIP(탄력적 아이피)를 동시에 생성했다.
프라이빗 IP 를 통해 해당 NAT Gateway 는 Public Subnet 에 위치함을 알 수 있다.
이제 생성한 NAT Gateway 를 Routing Table 편집해준다.
마지막으로, NACL(Network Access Control List) 와 보안 그룹(Security Group) 에 대해서 정리하고 이번 정리를 마치겠다.
NACL 은 앞서 정리한 Routing Table 과 마찬가지로 VPC 생성시 자동 생성된다. 하지만, 생성된 NACL 은 새로 생성한 VPC 의 Subnet 들이 추가가 되어 있지 않기 때문에 기본 ACL 에 자동적으로 연결된다. 기본 ACL 은 기본 VPC 의 Subnet 에 대한 ACL 을 관리하기 때문에 새로 생성한 VPC 의 Subnet 에 대한 모든 트래픽이 당연하게도 거부된다. 따라서 새로 생성한 ACL 에 새로 생성한 VPC 의 Subnet 들을 먼저 연결해줘야 한다.
아래와 같이 subnet 들을 연결했다.
기본적으로 ACL 규칙은 번호가 낮은 순서부터 적용되며, 규칙에 일치하는 트래픽이 있다면 이와 모순되는 상위 규칙이 있더라도 적용된다.
아래는 기본 인바운드 규칙과 아웃바운드 규칙이다. 이는 ACL 에 연결된 서브넷을 드나드는 트래픽 흐름을 모두 허용하도록 구성되어 있다. 규칙 100의 경우 모든 트래픽과 모든 프로토콜 모든 포트를 허용하는 것을 나타낸다. 여기서 의문인점은 아래에 * 로 되어있는 규칙이다. * 가 붙은 규칙은 ACL 의 다른 어떤 규칙과 일치하지 않을 경우에 적용된다고 보면 된다.
따라서, 아래의 2개의 규칙이라면 * 규칙은 절대로 도달하지 않는 규칙이라고 볼 수 있으며, 이는 100 번 규칙을 통해 모든 트래픽을 허용한다고 볼 수 있다.
이제 진짜 마지막으로 보안 그룹 (Security Group) 에 대해 정리하겠다.
보안 그룹은 간단하게 말해서 인스턴스 레벨에서 인바운드와 아웃바운드 트래픽을 제어하는 방화벽으로 보면된다.
Network Access Control List 는 Subnet 레벨에서 방화벽 역할을 했다면, 보안 그룹은 작은 범위로, 인스턴스 레벨에서 방화벽 역할을 한다.
NACL 과 Security Group 의 차이점을 보다 자세히 확인하고 싶다면 아래 링크를 참고하면 된다.
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Security.html#VPC_Security_Comparison
이번글에서 인스턴스를 생성하고 인스턴스마다 혹은 인스턴스 관계에 대한 방화벽 설정을 하지 않기 때문에 보안 그룹에 대해서는 여기까지만 다루어 보겠다.
댓글
댓글 쓰기