Transit Gateway와 NACL

NACL은 서브넷 단위로 적용된다.

-> 서브넷으로 들어올 때 인바운드, 서브넷에서 나갈 때 아웃바운드

AWS에서는 Transit Gateway(이하 TGW) 적용 시 전용 서브넷을 따로 만들어 연결하는 것을 권장하고 있다.

Transit Gateway 설계 모범 사례 - Amazon VPC

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

학원에서는 대충 "TGW 전용 통로를 만든다" 라고 표현했었다.

1. 별도의 서브넷 없이 EC2(서버)가 있는 서브넷에 TGW를 연결하는 방식

2. 별도의 서브넷을 만들어 TGW를 연결하는 방식

네트워크 ACL과 Transit Gateway를 함께 사용하는 방법 - Amazon VPC

docs.aws.amazon.com

대충 위 1번, 2번 경우에서 NACL이 적용되는 상황이 다르다는 내용.

1번 경우에서...

NACL은 서브넷 단위에서 적용되는 것 아닌가?

"TGW 연결 서브넷 = EC2 서브넷"인데 왜 NACL이 적용되는가?

동일한 서브넷의 내부 통신 아닌가?

일단 기준을 잡을 점 - 내부 통신의 기준은 무엇인가?

-> 서브넷 간 통신이면 내부, 아니면 외부 통신?

-> 라우팅 테이블이 다르니(서브넷 라우팅 테이블/TGW 라우팅 테이블) 외부 통신?

중요!

별도의 서브넷에 연결하지 않고 서버와 같은 서브넷에 연결 후, NACL을 적용하려면?

클라이언트든 서버든 TGW에서 서버로 가는 과정에서 NACL 규칙 평가가 한번 더 이루어진다. 이 순간에서

인바운드 규칙의 트래픽 소스 CIDR(or IP)는 어떻게 되는가?

-> 서브넷 안에 있는 TGW에서 서브넷 안에 있는 인스턴스로 트래픽이 이동하니까 소스 주소에 서브넷 CIDR이 들어간다.

어쨌건 2번 경우처럼 별도의 서브넷을 만들어 TGW를 연결하면

-> TGW용 서브넷의 NACL을 모두 열어둔다

-> EC2가 있는 서브넷의 NACL을 조정한다

결과 : 인스턴스에 들어가는 트래픽을 더 세밀하게 조절 가능

고민할 지점

-> TGW를 배울 때 내부 통신이라고 배웠었다. 내부 통신과 외부 통신의 기준은 무엇인가?

고래상자