<aside> ☁️
클라우드웨이브 네트워크 1주차 · 3/5 · 약 5분
클라우드웨이브 부트캠프: 네트워크에서 클라우드 네이티브까지
</aside>
셋째 날은 유독 비슷한 용어가 많이 나왔다. ACL, 보안 그룹, 네트워크 ACL, NAT 모두 트래픽에 관여하니 처음에는 전부 “접근을 막거나 열어 주는 기능”처럼 보였다.
이날 가장 중요했던 건 기능을 외우는 것이 아니라, 각각이 어떤 질문에 답하는지 구분하는 일이었다.
| 기능 | 확인하는 질문 |
|---|---|
| 라우팅 | 이 목적지로 가려면 어디로 보내야 할까? |
| ACL·보안 정책 | 이 트래픽을 통과시켜도 될까? |
| NAT | 외부에서는 어떤 주소와 포트로 보일까? |
경로가 있다고 통신이 자동으로 허용되는 것은 아니다. 보안 그룹에 포트를 열었다고 목적지까지 가는 경로가 생기는 것도 아니다. NAT로 주소가 바뀐다고 트래픽이 암호화되는 것도 아니다.
Cisco ACL에서는 표준 ACL과 확장 ACL을 구분했다.
규칙은 위에서부터 평가되기 때문에 순서가 중요하다. 너무 넓은 규칙을 위에 두면 아래의 세밀한 규칙이 사용되지 않을 수 있다.
wildcard mask도 처음에는 서브넷 마스크와 같은 값처럼 보였다. 하지만 Cisco ACL에서 0 비트는 반드시 일치해야 하고, 1 비트는 비교하지 않는다는 뜻이다. 단순한 경우 서브넷 마스크 255.255.255.0에 대응하는 wildcard mask는 0.0.0.255가 된다.
다만 Cisco ACL의 문법을 AWS 보안 그룹에 그대로 옮길 수는 없다. 정책의 의도는 비슷해도 적용 범위와 상태 추적 방식이 다르기 때문이다.
AWS에서는 두 기능의 경계를 먼저 구분해야 한다.