Amazon EC2 보안 그룹 연결 추적(Connection tracking)

Amazon EC2 보안 그룹 연결 추적(Connection tracking)

보안 그룹은 연결 추적을 사용해 인스턴스로 오고 가는 트래픽에 대한 정보를 추적해요. 이 절에서 연결 추적의 동작, 추적되지 않는 연결, 자동 추적 연결, 연결 추적 허용, 유휴 연결 추적 타임아웃을 살펴볼게요.

출처: 문서

본문

내 보안 그룹은 연결 추적을 사용해 인스턴스로 오고 가는 트래픽에 대한 정보를 추적해요. 트래픽의 연결 상태를 기반으로 규칙이 적용되어 트래픽을 허용할지 거부할지 결정해요. 이 접근 방식으로 보안 그룹은 상태 저장(stateful)이에요. 즉, 인바운드 트래픽에 대한 응답은 아웃바운드 보안 그룹 규칙과 관계없이 인스턴스에서 흘러나가는 것이 허용되고, 그 반대도 마찬가지예요.

예를 들어 홈 컴퓨터에서 netcat 같은 명령을 인스턴스로 시작하고 인바운드 보안 그룹 규칙이 ICMP 트래픽을 허용한다고 가정해 봐요. 연결에 대한 정보(포트 정보 포함)가 추적돼요. 명령에 대한 인스턴스의 응답 트래픽은 새 요청이 아니라 설정된 연결로 추적되어, 아웃바운드 보안 그룹 규칙이 아웃바운드 ICMP 트래픽을 제한해도 인스턴스에서 흘러나가는 것이 허용돼요.

TCP, UDP, ICMP가 아닌 프로토콜의 경우 IP 주소와 프로토콜 번호만 추적돼요. 인스턴스가 다른 호스트로 트래픽을 보내고 호스트가 600초 안에 같은 유형의 트래픽을 인스턴스로 보내면, 인스턴스의 보안 그룹은 인바운드 보안 그룹 규칙과 관계없이 이를 수락해요. 원래 트래픽의 응답 트래픽으로 간주되기 때문이에요.

보안 그룹 규칙을 변경해도 추적된 연결이 즉시 중단되지는 않아요. 보안 그룹은 기존 연결이 타임아웃될 때까지 패킷을 계속 허용해요. 트래픽을 즉시 중단하거나 추적 상태와 관계없이 모든 트래픽에 방화벽 규칙을 적용하려면 서브넷에 네트워크 ACL을 사용할 수 있어요. 네트워크 ACL은 무상태(stateless)라서 응답 트래픽을 자동으로 허용하지 않아요. 어느 방향이든 트래픽을 차단하는 네트워크 ACL을 추가하면 기존 연결이 끊겨요. 자세한 내용은 Amazon VPC User Guide의 Network ACLs을 참고하세요.

참고

보안 그룹은 'VPC+2 IP address'라고도 하는 Route 53 Resolver(자세한 내용은 Amazon Route 53 Developer Guide의 What is Amazon Route 53 Resolver? 참고) 또는 'AmazonProvidedDNS'(Amazon Virtual Private Cloud User Guide의 Work with DHCP option sets 참고)로 오가는 DNS 트래픽에는 영향을 주지 않아요. Route 53 Resolver를 통한 DNS 요청을 필터링하려면 Route 53 Resolver DNS Firewall(Amazon Route 53 Developer Guide의 Route 53 Resolver DNS Firewall 참고)을 활성화할 수 있어요.

추적되지 않는 연결

모든 트래픽 흐름이 추적되는 것은 아니에요. 보안 그룹 규칙이 모든 트래픽(0.0.0.0/0 또는 ::/0)에 대한 TCP 또는 UDP 흐름을 허용하고, 다른 방향에 모든 응답 트래픽(0.0.0.0/0 또는 ::/0)을 모든 포트(0-65535)에 대해 허용하는 대응 규칙이 있으면, 해당 트래픽 흐름은 자동 추적 연결의 일부가 아닌 한 추적되지 않아요. 추적되지 않는 흐름의 응답 트래픽은 추적 정보가 아니라 응답 트래픽을 허용하는 인바운드 또는 아웃바운드 규칙에 기반해 허용돼요.

추적되지 않는 트래픽 흐름은 흐름을 허용하는 규칙이 제거되거나 수정되면 즉시 중단돼요. 예를 들어 열린(0.0.0.0/0) 아웃바운드 규칙이 있고, 인스턴스로의 모든(0.0.0.0/0) 인바운드 SSH(TCP 포트 22) 트래픽을 허용하는 규칙을 제거하면(또는 연결이 더 이상 허용되지 않도록 수정하면) 인스턴스에 대한 기존 SSH 연결이 즉시 끊겨요. 이 연결은 이전에 추적되지 않았으므로 변경이 연결을 끊게 돼요. 반면에 처음에 SSH 연결을 허용하는 더 좁은 인바운드 규칙(즉, 연결이 추적되었음을 의미)이 있고, 현재 SSH 클라이언트의 주소에서 새 연결을 더 이상 허용하지 않도록 그 규칙을 변경하면, 기존 SSH 연결은 추적되므로 중단되지 않아요.

자동 추적 연결

다음을 통한 연결은 보안 그룹 구성이 그렇지 않으면 추적을 요구하지 않아도 자동으로 추적돼요.

  • Egress-only internet gateways
  • Global Accelerator accelerators
  • NAT gateways
  • Network Firewall firewall endpoints
  • Network Load Balancers
  • AWS PrivateLink(interface VPC endpoints)
  • AWS Lambda(Hyperplane elastic network interfaces)
  • DynamoDB gateway endpoints – DynamoDB에 대한 각 연결은 conntrack 항목 2개를 소비해요.

연결 추적 허용량

Amazon EC2는 인스턴스당 추적할 수 있는 최대 연결 수를 정의해요. 최대에 도달하면 새 연결을 설정할 수 없으므로 보내거나 받는 모든 패킷이 버려져요. 이렇게 되면 패킷을 보내고 받는 애플리케이션이 제대로 통신할 수 없어요. conntrack_allowance_available 네트워크 성능 지표를 사용해 해당 인스턴스 유형에 대해 여전히 사용 가능한 추적 연결 수를 확인하세요.

인스턴스의 네트워크 트래픽이 추적할 수 있는 최대 연결 수를 초과해 패킷이 버려졌는지 확인하려면 conntrack_allowance_exceeded 네트워크 성능 지표를 사용하세요. 자세한 내용은 Monitor network performance for ENA settings on your EC2 instance을 참고하세요.

Elastic Load Balancing 사용 시 인스턴스당 추적할 수 있는 최대 연결 수를 초과하면, 로드 밸런서에 등록된 인스턴스 수를 확장하거나 로드 밸런서에 등록된 인스턴스 크기를 확장할 것을 권장해요.

연결 추적 모범 사례

트래픽이 한 네트워크 인터페이스를 통해 인스턴스로 들어오고 다른 네트워크 인터페이스를 통해 나가는 비대칭 라우팅은, 흐름이 추적되면 인스턴스가 달성할 수 있는 최고 성능을 떨어뜨릴 수 있어요.

보안 그룹에서 연결 추적이 활성화된 상태에서 최고 성능을 유지하고 연결 관리를 최적화하려면 다음 구성을 권장해요.

  • 가능하면 비대칭 라우팅 토폴로지를 피하세요.
  • 필터링에 보안 그룹을 사용하는 대신 네트워크 ACL을 사용하세요.
  • 연결 추적과 함께 보안 그룹을 사용해야 한다면 가능한 가장 짧은 유휴 연결 추적 타임아웃을 구성하세요. 유휴 연결 추적 타임아웃에 대한 자세한 내용은 다음 섹션을 참고하세요.
  • Nitrov6 인스턴스의 짧은 기본 타임아웃으로 인해 DB 연결 풀, 영구 HTTP 연결, 스트리밍 워크로드 같은 장수명 연결이 있는 애플리케이션은 인스턴스 시작 시 적절한 TcpEstablishedTimeout 값을 구성해야 해요.
  • 장수명 연결의 경우 5분 미만 간격으로 TCP keepalive를 보내도록 구성해 연결이 열린 상태를 유지하고 추적 상태를 유지하세요. 이는 유휴 타임아웃으로 연결이 끊기는 것을 방지하고 연결 재수립의 오버헤드를 줄이는 데 도움이 돼요.

Nitro 시스템의 성능 튜닝에 대한 자세한 내용은 Nitro system considerations for performance tuning을 참고하세요.

유휴 연결 추적 타임아웃

보안 그룹은 반환 패킷이 예상대로 전달되도록 설정된 각 연결을 추적해요. 인스턴스당 추적할 수 있는 최대 연결 수가 있어요. 유휴 상태로 남는 연결은 연결 추적 고갈로 이어져 연결이 추적되지 않고 패킷이 버려질 수 있어요. 탄력적 네트워크 인터페이스에서 유휴 연결 추적 타임아웃을 설정할 수 있어요.

참고

이 기능은 Nitro 기반 인스턴스에서만 사용할 수 있어요. 프로덕션에 배포하기 전에 350초 기본 연결 추적 타임아웃이 적용된 Nitrov6 세대 인스턴스에서 애플리케이션을 테스트해야 해요.

구성 가능한 타임아웃은 세 가지가 있어요.

  • TCP established 타임아웃: established 상태의 유휴 TCP 연결에 대한 타임아웃(초).
    • 최소: 60초
    • 최대: 432000초
    • 기본: Nitro v6 인스턴스 유형(P6e-GB200 제외)의 경우 350초; 그 외 모든 인스턴스 유형(P6e-GB200 포함)의 경우 432000초
    • 권장: 432000초 미만
  • UDP 타임아웃: 단일 방향 또는 단일 요청-응답 트랜잭션에서만 트래픽을 본 유휴 UDP 흐름에 대한 타임아웃(초).
    • 최소: 30초
    • 최대: 60초
    • 기본: 30초
  • UDP stream 타임아웃: 둘 이상의 요청-응답 트랜잭션을 본 스트림으로 분류된 유휴 UDP 흐름에 대한 타임아웃(초).
    • 최소: 60초
    • 최대: 180초
    • 기본: 180초

다음 경우 중 하나에 해당하면 기본 타임아웃을 수정하고 싶을 수 있어요.

  • Amazon EC2 네트워크 성능 지표로 추적 연결을 모니터링한다면, conntrack_allowance_exceeded와 conntrack_allowance_available 지표를 사용해 버려진 패킷과 추적 연결 사용률을 모니터링할 수 있어요. 이는 패킷을 버리기 전에 확장(scale up/out) 작업으로 EC2 인스턴스 용량을 사전에 관리해 네트워크 연결 수요를 충족하는 데 도움이 돼요. EC2 인스턴스에서 conntrack_allowance_exceeded 드랍을 관찰하고 있다면, 부적절한 클라이언트나 네트워크 미들박스로 인한 오래된 TCP/UDP 세션을 처리하기 위해 더 낮은 TCP established 타임아웃을 설정하는 것이 도움이 될 수 있어요.
  • 일반적으로 로드 밸런서나 방화벽은 TCP Established 유휴 타임아웃이 60~90분 범위예요. 네트워크 방화벽 같은 어플라이언스에서 10만 개 이상의 매우 많은 연결 수를 처리할 것으로 예상되는 워크로드를 실행한다면 EC2 네트워크 인터페이스에 비슷한 타임아웃을 구성하는 것이 좋아요.
  • 비대칭 라우팅 토폴로지를 사용하는 워크로드를 실행한다면 TCP Established 유휴 타임아웃을 60초로 구성할 것을 권장해요.
  • DNS, SIP, SNMP, Syslog, Radius 및 주로 UDP로 요청을 서비스하는 기타 서비스처럼 높은 연결 수를 가진 워크로드를 실행한다면 'UDP-stream' 타임아웃을 60초로 설정하면 기존 용량의 확장/성능을 높이고 그레이 실패를 방지하는 데 도움이 돼요.
  • Network Load Balancers를 통한 TCP/UDP 연결의 경우 모든 연결이 추적돼요. TCP 흐름의 유휴 타임아웃 값은 350초, UDP 흐름은 120초이며 인터페이스 수준 타임아웃 값과 달라요. 로드 밸런서의 기본값보다 더 유연한 타임아웃을 허용하려면 네트워크 인터페이스 수준에서 타임아웃을 구성하고 싶을 수 있어요.

다음을 수행할 때 연결 추적 타임아웃을 구성할 수 있어요.

예시

다음 예시에서 보안 그룹에는 TCP와 ICMP 트래픽을 허용하는 인바운드 규칙과 모든 아웃바운드 트래픽을 허용하는 아웃바운드 규칙이 있어요.

인바운드

프로토콜 유형 포트 번호 소스
TCP 22 (SSH) 203.0.113.1/32
TCP 80 (HTTP) 0.0.0.0/0
TCP 80 (HTTP) ::/0
ICMP All 0.0.0.0/0

아웃바운드

프로토콜 유형 포트 번호 대상
All All 0.0.0.0/0
All All ::/0

인스턴스나 네트워크 인터페이스에 직접 네트워크 연결이 있다면 추적 동작은 다음과 같아요.

  • 포트 22(SSH)의 인바운드·아웃바운드 TCP 트래픽은 추적돼요. 인바운드 규칙이 모든 IP 주소(0.0.0.0/0)가 아닌 203.0.113.1/32에서만 트래픽을 허용하기 때문이에요.
  • 포트 80(HTTP)의 인바운드·아웃바운드 TCP 트래픽은 추적되지 않아요. 인바운드·아웃바운드 규칙이 모든 IP 주소의 트래픽을 허용하기 때문이에요.
  • ICMP 트래픽은 항상 추적돼요.

IPv4 트래픽용 아웃바운드 규칙을 제거하면 포트 80(HTTP) 트래픽을 포함한 모든 인바운드·아웃바운드 IPv4 트래픽이 추적돼요. IPv6 트래픽용 아웃바운드 규칙을 제거해도 IPv6 트래픽에 대해 같은 것이 적용돼요.

더 알아보기