네트워크 ACL을 사용하여 서브넷에 대한 트래픽 제어 - Amazon Virtual Private Cloud

네트워크 ACL을 사용하여 서브넷에 대한 트래픽 제어

네트워크 액세스 제어 목록(ACL)은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부합니다. VPC에 대한 기본 네트워크 ACL을 사용하거나 보안 그룹에 대한 규칙과 유사한 규칙을 사용하여 VPC에 대한 사용자 지정 네트워크 ACL을 생성하여 VPC에 보안 계층을 추가할 수 있습니다.

네트워크 ACL을 사용해도 추가 요금이 부과되지 않습니다.

다음 다이어그램에서는 서브넷이 2개인 VPC를 보여줍니다. 각 서브넷에 네트워크 ACL이 있습니다. 트래픽이 VPC로 들어오면(예: 피어링된 VPC, VPN 연결 또는 인터넷의 트래픽) 라우터에서 트래픽을 대상으로 보냅니다. 네트워크 ACL A에서는 서브넷 1로 향하는 트래픽 중 서브넷 1로 들어가도록 허용되는 트래픽과 서브넷 1 외부 위치로 향하는 트래픽 중 서브넷 1에서 나가도록 허용되는 트래픽을 결정합니다. 마찬가지로, 네트워크 ACL B에서는 서브넷 2에 들어오고 나갈 수 있는 트래픽을 결정합니다.

서브넷 2개와 각 서브넷의 네트워크 ACL이 있는 VPC.

보안 그룹과 네트워크 ACL의 차이점에 대한 자세한 내용은 보안 그룹 및 네트워크 ACL 비교를 참조하세요.

네트워크 ACL 기본 사항

다음은 네트워크 ACL에 대해 알아야 할 기본 사항입니다.

  • VPC는 수정 가능한 기본 네트워크 ACL과 함께 자동으로 제공됩니다. 기본적으로 모든 인바운드 및 아웃바운드 IPv4 트래픽을 허용하며, 해당되는 경우 IPv6 트래픽도 허용합니다.

  • 사용자 지정 네트워크 ACL을 생성하고 서브넷과 연결하여 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부할 수 있습니다.

  • VPC에 있는 각 서브넷을 네트워크 ACL과 연결해야 합니다. 서브넷을 네트워크 ACL에 명시적으로 연결하지 않을 경우, 서브넷은 기본 네트워크 ACL에 자동적으로 연결됩니다.

  • 네트워크 ACL을 여러 서브넷과 연결할 수 있습니다. 그러나 서브넷은 한 번에 하나의 네트워크 ACL에만 연결할 수 있습니다. 네트워크 ACL을 서브넷과 연결하면 이전 연결은 제거됩니다.

  • 네트워크 ACL에는 인바운드 규칙과 아웃바운드 규칙이 있습니다. 각 규칙에서는 트래픽을 허용하거나 거부할 수 있습니다. 각 규칙에는 1부터 32766까지 번호가 있습니다. 규칙은 트래픽 허용 또는 거부가 결정될 때 가장 낮은 번호의 규칙부터 순서대로 평가됩니다. 트래픽이 규칙과 일치하면 규칙이 적용되며 추가 규칙은 평가되지 않습니다. 필요한 경우 나중에 새 규칙을 삽입할 수 있도록 증분 방식으로(예: 10 또는 100 단위씩 증분) 규칙을 생성하여 시작하는 것이 좋습니다.

  • 네트워크 ACL 규칙은 트래픽이 서브넷 내에서 라우팅될 때가 아니라 서브넷에 들어오고 나갈 때 평가됩니다.

  • NACL은 상태 비저장 목록이므로 이전에 전송했거나 수신한 트래픽에 대한 정보가 저장되지 않습니다. 예를 들어, 서브넷에 대한 특정 인바운드 트래픽을 허용하는 NACL 규칙을 생성하는 경우 해당 트래픽에 대한 응답이 자동으로 허용되지 않습니다. 이는 보안 그룹의 작동 방식과 대조적입니다. 보안 그룹은 상태 저장 그룹이므로 이전에 전송했거나 수신한 트래픽에 대한 정보가 저장됩니다. 예를 들어, 보안 그룹이 EC2 인스턴스에 대한 인바운드 트래픽을 허용하는 경우 아웃바운드 보안 그룹 규칙에 관계없이 응답이 자동으로 허용됩니다.

  • 네트워크 ACL은 Route 53 Resolver(VPC+2 IP 주소 또는 AmazonProvidedDNS라고도 함)에서 송수신되는 DNS 요청을 차단할 수 없습니다. Route 53 Resolver를 통해 DNS 요청을 필터링하려면 Route 53 Resolver DNS 방화벽을 활성화합니다(Amazon Route 53 개발자 안내서 참조).

  • 네트워크 ACL은 인스턴스 메타데이터 서비스(IMDS)에 대한 트래픽을 차단할 수 없습니다. IMDS에 대한 액세스를 관리하려면 Amazon EC2 사용 설명서의 인스턴스 메타데이터 옵션 구성을 참조하세요.

  • 네트워크 ACL은 다음에서 송수신되는 트래픽을 필터링하지 않습니다.

    • Amazon Domain Name Services(DNS)

    • Amazon Dynamic Host Configuration Protocol(DHCP)

    • Amazon EC2 인스턴스 메타데이터

    • Amazon ECS 태스크 메타데이터 엔드포인트

    • Windows 인스턴스에 대한 라이선스 활성화

    • Amazon Time Sync Service

    • 기본 VPC 라우터에서 사용하는 예약된 IP 주소

  • VPC당 네트워크 ACL 수 및 네트워크 ACL당 규칙 수에 대한 할당량(제한이라고도 함)이 있습니다. 자세한 내용은 Amazon VPC 할당량 단원을 참조하십시오.

네트워크 ACL 규칙

기본 네트워크 ACL에 규칙을 추가 또는 제거하거나, VPC에 대한 네트워크 ACL을 추가로 생성할 수 있습니다. 네트워크 ACL에서 규칙을 추가하거나 제거할 때 네트워크 ACL이 연결되어 있는 서브넷에 변경 사항이 자동으로 적용됩니다.

다음은 네트워크 ACL 규칙 중 일부입니다.

  • 규칙 번호. 번호가 가장 낮은 규칙부터 평가됩니다. 규칙에 일치하는 트래픽이 있으면 이와 모순되는 상위 규칙이 있더라도 적용됩니다.

  • 유형. 트래픽 유형(예: SSH)입니다. 모든 트래픽 또는 사용자 지정 범위를 지정할 수도 있습니다.

  • 프로토콜 . 표준 프로토콜 번호를 가진 어떤 프로토콜이든 지정할 수 있습니다. 자세한 내용은 프로토콜 번호를 참조하십시오. ICMP를 프로토콜로 지정하면 ICMP 유형과 코드 중 일부 또는 전부를 지정할 수 있습니다.

  • 포트 범위. 트래픽에 대한 수신 포트 또는 포트 범위입니다. 예를 들어, HTTP 트래픽의 경우 80입니다.

  • 소스: . [인바운드 규칙만 해당] 트래픽의 소스(CIDR 범위)입니다.

  • 대상 [아웃바운드 규칙만 해당] 트래픽의 대상(CIDR 범위)입니다.

  • 허용/거부. 지정된 트래픽을 허용 또는 거부 할지 여부입니다.

명령줄 도구 또는 Amazon EC2 API를 사용하여 규칙을 추가하면 CIDR 범위가 표준 형식으로 자동 수정됩니다. 예를 들어 CIDR 범위에 100.68.0.18/18을 지정하면 100.68.0.0/18 CIDR 범위를 가진 규칙이 작성됩니다.

기본 네트워크 ACL

기본 네트워크 ACL은 연결된 서브넷을 드나드는 트래픽 흐름을 모두 허용하도록 구성되어 있습니다. 각 네트워크 ACL에는 규칙 번호가 별표(*)로 되어 있는 규칙도 포함되어 있습니다. 이 규칙은 패킷이 번호가 매겨진 다른 어떤 규칙과도 일치하지 않을 경우에는 거부되도록 되어 있습니다. 이 규칙을 수정하거나 제거할 수 없습니다.

다음은 IPv4만을 지원하는 VPC에 대한 기본 네트워크 ACL의 예시입니다.

인바운드
규칙 # Type 프로토콜 포트 범위 소스 허용/거부

100

모든 IPv4 트래픽

모두

모두

0.0.0.0/0

ALLOW

*

모든 IPv4 트래픽

모두

모두

0.0.0.0/0

DENY

아웃바운드
규칙 # Type 프로토콜 포트 범위 대상 주소 허용/거부

100

모든 IPv4 트래픽

모두

모두

0.0.0.0/0

ALLOW

*

모든 IPv4 트래픽

모두

모두

0.0.0.0/0

DENY

IPv6 CIDR 블록이 있는 VPC를 생성하거나 IPv6 CIDR 블록을 기존 VPC와 연결하는 경우, 모든 IPv6 트래픽이 서브넷으로 그리고 서브넷으로부터 전송되도록 허용하는 규칙이 자동으로 추가됩니다. 또한 규칙 번호가 별표로 되어 있어 패킷이 번호가 매겨진 다른 어떤 규칙과도 일치하지 않을 경우에는 거부되도록 하는 규칙도 추가합니다. 이 규칙은 수정하거나 제거할 수 없습니다. 다음은 IPv4와 IPv6를 지원하는 VPC에 대한 기본 네트워크 ACL의 예시입니다.

참고

기본 네트워크 ACL의 인바운드 규칙을 수정한 경우 IPv6 블록을 VPC에 연결할 때 인바운드 IPv6 트래픽에 대한 ALLOW 규칙이 자동으로 추가되지는 않습니다. 이와 마찬가지로 아웃바운드 규칙을 수정한 경우에는 아웃바운드 IPv6 트래픽에 대한 ALLOW 규칙이 자동으로 추가되지 않습니다.

인바운드
규칙 # Type 프로토콜 포트 범위 소스 허용/거부

100

모든 IPv4 트래픽

모두

모두

0.0.0.0/0

허용

101

모든 IPv6 트래픽

모두

모두

::/0

ALLOW

*

모든 트래픽

모두

모두

0.0.0.0/0

DENY

*

모든 IPv6 트래픽

모두

모두

::/0

DENY

아웃바운드
규칙 # Type 프로토콜 포트 범위 대상 주소 허용/거부

100

모든 트래픽

모두

모두

0.0.0.0/0

허용

101

모든 IPv6 트래픽

모두

모두

::/0

ALLOW

*

모든 트래픽

모두

모두

0.0.0.0/0

DENY

*

모든 IPv6 트래픽

모두

모두

::/0

DENY

사용자 지정 네트워크 ACL

다음은 IPv4만 지원하는 VPC에 대한 사용자 지정 네트워크 ACL의 예시입니다. 여기에는 HTTP 및 HTTPS 트래픽 수신을 허용하는 인바운드 규칙이 포함됩니다(100 및 110). 휘발성 포트 32768~65535를 포함하는 해당 인바운드 트래픽(140)에 대한 응답을 활성화하는 해당 아웃바운드 규칙이 있습니다. 적절한 휘발성 포트 범위를 선택하는 방법에 대한 자세한 내용은 휘발성 포트 단원을 참조하십시오.

이 네트워크 ACL에는 서브넷으로의 SSH 및 RDP 트래픽을 허용하는 인바운드 규칙도 포함됩니다. 아웃바운드 규칙 120은 응답이 서브넷을 떠날 수 있도록 합니다.

이 네트워크 ACL에는 서브넷 외부로의 아웃바운드 HTTP 및 HTTPS 트래픽을 허용하는 아웃바운드 규칙(100 및 110)이 있습니다. 휘발성 포트 32768~65535를 포함하는 해당 아웃바운드 트래픽(140)에 대한 응답을 활성화하는 해당 인바운드 규칙이 있습니다.

각 네트워크 ACL에는 규칙 번호가 별표로 된 기본 규칙이 포함되어 있습니다. 이 규칙은 패킷이 다른 어떤 규칙과도 일치하지 않을 경우에는 거부되도록 되어 있습니다. 이 규칙을 수정하거나 제거할 수 없습니다.

인바운드
규칙 # Type 프로토콜 포트 범위 소스 허용/거부 설명

100

HTTP

TCP

80

0.0.0.0/0

ALLOW

어떤 IPv4 주소에서 이루어지는 인바운드 HTTP 트래픽도 모두 허용

110

HTTPS

TCP

443

0.0.0.0/0

ALLOW

어떤 IPv4 주소에서 이루어지는 인바운드 HTTPS 트래픽도 모두 허용

120

SSH

TCP

22

192.0.2.0/24

ALLOW

홈 네트워크의 퍼블릭 IPv4 주소 범위로부터의 인바운드 SSH 트래픽 허용(인터넷 게이트웨이를 통해)

130

RDP

TCP

3389

192.0.2.0/24

ALLOW

홈 네트워크의 퍼블릭 IPv4 주소 범위로부터 웹 서버로의 인바운드 RDP 트래픽 허용(인터넷 게이트웨이를 통해)

140

사용자 지정 TCP

TCP

32768-65535

0.0.0.0/0

ALLOW

인터넷으로부터의 인바운드 리턴 IPv4 트래픽 허용(즉, 서브넷에서 시작되는 요청에 대해).

이 범위는 예시일 뿐입니다.

*

모든 트래픽

모두

모두

0.0.0.0/0

DENY

이전 규칙에서 아직 처리하지 않은 모든 인바운드 IPv4 트래픽 거부(수정 불가)

아웃바운드
규칙 # Type 프로토콜 포트 범위 대상 주소 허용/거부 설명

100

HTTP

TCP

80

0.0.0.0/0

ALLOW

서브넷에서 인터넷으로의 아웃바운드 IPv4 HTTP 트래픽 허용

110

HTTPS

TCP

443

0.0.0.0/0

ALLOW

서브넷에서 인터넷으로의 아웃바운드 IPv4 HTTPS 트래픽 허용

120 SSH

TCP

1024~65535

192.0.2.0/24

ALLOW

홈 네트워크의 퍼블릭 IPv4 주소 범위로의 아웃바운드 반환 SSH 트래픽이 허용됩니다(인터넷 게이트웨이 경유).

140

사용자 지정 TCP

TCP

32768-65535

0.0.0.0/0

ALLOW

인터넷에서 클라이언트에 대한 아웃바운드 IPv4 응답 허용(예: 서브넷에 있는 웹 서버를 방문하는 사람들에게 웹 페이지 제공).

이 범위는 예시일 뿐입니다.

*

모든 트래픽

모두

모두

0.0.0.0/0

DENY

이전 규칙에서 아직 처리하지 않은 모든 아웃바운드 IPv4 트래픽 거부(수정 불가)

패킷이 서브넷에 도착할 때, 이를 서브넷이 연결되어 있는 ACL의 인바운드 규칙에 대해 평가합니다(규칙 목록의 맨 위에서 시작하여 맨 아래로 이동). 다음은 패킷이 SSL 포트(443)로 전달되는 경우 평가가 이루어지는 방식입니다. 이 패킷은 처음으로 평가되는 규칙(규칙 100)과 일치하지 않습니다. 이 패킷은 패킷을 서브넷으로 수신되도록 허용하는 두 번째 규칙(110)과도 일치하지 않습니다. 패킷이 포트 139(NetBIOS)로 보내진 경우 어떠한 규칙과도 일치하지 않으며, * 규칙이 최종적으로 해당 패킷을 거부합니다.

광범위한 포트를 합법적으로 열어야 하지만 거부하려는 범위 내에 특정 포트가 있는 경우 거부 규칙을 추가할 수 있습니다. 광범위한 포트 트래픽을 허용하는 규칙보다 거부 규칙을 먼저 테이블에 배치하십시오.

사용 사례에 따라 허용 규칙을 추가합니다. 예를 들어 DNS 확인을 위해 포트 53에서 아웃바운드 TCP 및 UDP 액세스를 허용하는 규칙을 추가할 수 있습니다. 추가하는 모든 규칙에 대해 응답 트래픽을 허용하는 해당 인바운드 또는 아웃바운드 규칙이 있는지 확인합니다.

다음은 연결된 IPv6 CIDR 블록이 있는 VPC에 대한 사용자 지정 네트워크 ACL의 예시입니다. 이 네트워크 ACL에는 모든 IPv6 HTTP 및 HTTPS 트래픽에 대한 규칙이 포함됩니다. 이 경우 IPv4 트래픽에 대한 기존 규칙 사이에 새 규칙이 삽입되었습니다. IPv4 규칙 다음에 규칙을 더 높은 번호의 규칙으로 추가할 수도 있습니다. IPv4 및 IPv6 트래픽은 분리되어 있습니다. 따라서 IPv4 트래픽에 대한 규칙 중 어느 것도 IPv6 트래픽에 적용되지 않습니다.

인바운드
규칙 # Type 프로토콜 포트 범위 소스 허용/거부 설명

100

HTTP

TCP

80

0.0.0.0/0

ALLOW

어떤 IPv4 주소에서 이루어지는 인바운드 HTTP 트래픽도 모두 허용

105

HTTP

TCP

80

::/0

허용

어떤 IPv6 주소에서 이루어지는 인바운드 HTTP 트래픽도 모두 허용

110

HTTPS

TCP

443

0.0.0.0/0

ALLOW

어떤 IPv4 주소에서 이루어지는 인바운드 HTTPS 트래픽도 모두 허용

115

HTTPS

TCP

443

::/0

허용

어떤 IPv6 주소에서 이루어지는 인바운드 HTTPS 트래픽도 모두 허용

120

SSH

TCP

22

192.0.2.0/24

ALLOW

홈 네트워크의 퍼블릭 IPv4 주소 범위로부터의 인바운드 SSH 트래픽 허용(인터넷 게이트웨이를 통해)

130

RDP

TCP

3389

192.0.2.0/24

ALLOW

홈 네트워크의 퍼블릭 IPv4 주소 범위로부터 웹 서버로의 인바운드 RDP 트래픽 허용(인터넷 게이트웨이를 통해)

140

사용자 지정 TCP

TCP

32768-65535

0.0.0.0/0

ALLOW

인터넷으로부터의 인바운드 리턴 IPv4 트래픽 허용(즉, 서브넷에서 시작되는 요청에 대해).

이 범위는 예시일 뿐입니다.

145

사용자 지정 TCP TCP 32768-65535 ::/0 ALLOW

인터넷으로부터의 인바운드 리턴 IPv6 트래픽 허용(즉, 서브넷에서 시작되는 요청에 대해).

이 범위는 예시일 뿐입니다.

*

모든 트래픽

모두

모두

0.0.0.0/0

DENY

이전 규칙에서 아직 처리하지 않은 모든 인바운드 IPv4 트래픽 거부(수정 불가)

*

모든 트래픽

모두

모두

::/0

DENY

이전 규칙에서 아직 처리하지 않은 모든 인바운드 IPv6 트래픽 거부(수정 불가)

아웃바운드
규칙 # Type 프로토콜 포트 범위 대상 주소 허용/거부 설명

100

HTTP

TCP

80

0.0.0.0/0

ALLOW

서브넷에서 인터넷으로의 아웃바운드 IPv4 HTTP 트래픽 허용

105

HTTP

TCP

80

::/0

허용

서브넷에서 인터넷으로의 아웃바운드 IPv6 HTTP 트래픽 허용

110

HTTPS

TCP

443

0.0.0.0/0

ALLOW

서브넷에서 인터넷으로의 아웃바운드 IPv4 HTTPS 트래픽 허용

115

HTTPS

TCP

443

::/0

허용

서브넷에서 인터넷으로의 아웃바운드 IPv6 HTTPS 트래픽 허용

140

사용자 지정 TCP

TCP

32768-65535

0.0.0.0/0

ALLOW

인터넷에서 클라이언트에 대한 아웃바운드 IPv4 응답 허용(예: 서브넷에 있는 웹 서버를 방문하는 사람들에게 웹 페이지 제공).

이 범위는 예시일 뿐입니다.

145

사용자 지정 TCP

TCP

32768-65535

::/0

허용

인터넷에서 클라이언트에 대한 아웃바운드 IPv6 응답 허용(예: 서브넷에 있는 웹 서버를 방문하는 사람들에게 웹 페이지 제공).

이 범위는 예시일 뿐입니다.

*

모든 트래픽

모두

모두

0.0.0.0/0

DENY

이전 규칙에서 아직 처리하지 않은 모든 아웃바운드 IPv4 트래픽 거부(수정 불가)

*

모든 트래픽

모두

모두

::/0

DENY

이전 규칙에서 아직 처리하지 않은 모든 아웃바운드 IPv6 트래픽 거부(수정 불가)

사용자 지정 네트워크 ACL 및 기타 AWS 서비스

사용자 지정 네트워크 ACL을 생성하는 경우 다른 AWS 서비스를 사용하여 생성하는 리소스에 미칠 수 있는 영향에 주의해야 합니다.

Elastic Load Balancing을 사용하는 경우 사용자의 백엔드 인스턴스에 대한 서브넷에 소스가 0.0.0.0/0 또는 서브넷의 CIDR인 모든 트래픽에 대해 거부 규칙을 추가한 네트워크 ACL이 있으면 로드 밸런서가 인스턴스에 대한 상태 확인을 수행할 수 없습니다. 로드 밸런서 및 백엔드 인스턴스에 권장되는 네트워크 ACL 규칙에 대한 자세한 내용은 Classic Load Balancer 사용 설명서VPC의 로드 밸런서를 위한 네트워크 ACL을 참조하십시오.

휘발성 포트

이전 단원에서 예로 든 네트워크 ACL에는 32768-65535 범위의 휘발성 포트가 사용됩니다. 하지만 사용하거나 통신하는 클라이언트의 유형에 따라 다른 범위의 네트워크 ACL을 사용할 수 있습니다.

요청을 시작하는 클라이언트가 휘발성 포트 범위를 선택합니다. 범위는 클라이언트의 운영 체제에 따라 다릅니다.

  • 다수의 Linux 커널(Amazon Linux 커널 포함)이 포트 32768-61000을 사용합니다.

  • Elastic Load Balancing에서 시작된 요청은 포트 1024-65535를 사용합니다.

  • Windows Server 2003까지의 Windows 운영 체제에서는 포트 1025-5000을 사용합니다.

  • Windows Server 2008 이상 버전은 포트 49152-65535를 사용합니다.

  • NAT 게이트웨이는 포트 1024 - 65535를 사용합니다.

  • AWS Lambda 함수는 포트 1024-65535를 사용합니다.

예를 들어, 인터넷을 통해 Windows 10 클라이언트로부터 VPC에 있는 웹 서버로 요청이 수신되는 경우, 네트워크 ACL에는 포트 49152-65535로 트래픽을 전달할 수 있도록 하는 아웃바운드 규칙이 있어야 합니다.

VPC의 인스턴스가 요청을 시작하는 클라이언트인 경우, 사용자의 네트워크 ACL에 인스턴스의 유형(Amazon Linux, Windows Server 2008 등)에 특정한 휘발성 포트로 트래픽을 전달할 수 있도록 하는 인바운드 규칙이 있어야 합니다.

실제로는 VPC에서 퍼블릭 쪽 인스턴스로 향하는 트래픽을 시작할 수도 있는 다양한 유형의 클라이언트를 포괄하기 위해, 휘발성 포트 1024-65535를 열 수 있습니다. 하지만 그 범위 내에 있는 악성 포트의 트래픽을 거부하기 위한 규칙을 ACL에 추가할 수도 있습니다. 광범위한 임시 포트를 여는 허용 규칙보다 거부 규칙을 먼저 테이블에 배치해야 합니다.

경로 MTU 검색

경로 MTU 검색을 사용하여 두 디바이스 간의 경로 MTU를 확인할 수 있습니다. 경로 MTU는 발신 호스트와 수신 호스트 간의 경로에서 지원되는 최대 패킷 사이즈입니다.

IPv4의 경우 호스트가 수신 호스트의 MTU 또는 경로를 따르는 디바이스의 MTU보다 큰 패킷을 전송하는 경우 수신 호스트 또는 디바이스가 패킷을 삭제한 다음 Destination Unreachable: Fragmentation Needed and Don't Fragment was Set(유형 3, 코드 4)과 같은 ICMP 메시지를 반환합니다. 이렇게 하면 전송 호스트에 페이로드를 여러 개의 작은 패킷으로 분할한 다음 다시 전송하도록 지시합니다.

IPv6 프로토콜은 네트워크의 조각화를 지원하지 않습니다. 호스트가 수신 호스트의 MTU 또는 경로를 따르는 디바이스의 MTU보다 큰 패킷을 전송하는 경우 수신 호스트 또는 디바이스가 패킷을 삭제한 다음 ICMPv6 Packet Too Big (PTB)(유형 2)과 같은 ICMP 메시지를 반환합니다. 이렇게 하면 전송 호스트에 페이로드를 여러 개의 작은 패킷으로 분할한 다음 다시 전송하도록 지시합니다.

서브넷에 있는 호스트 간의 최대 MTU(전송 단위)가 다르거나 인스턴스가 인터넷을 통해 피어와 통신하는 경우 인바운드 및 아웃바운드 네트워크 ACL 규칙을 추가해야 합니다. 이렇게 하면 경로 MTU 검색이 올바르게 작동하고 패킷 손실을 방지할 수 있습니다. 유형에 대해 사용자 지정 ICMP 규칙을 선택하고 포트 범위(유형 3, 코드 4)에 대해 대상에 연결할 수 없음, 조각화 필요, DF 플래그 설정을 선택합니다. traceroute를 사용할 경우에는 다음 규칙도 추가합니다. 즉, 유형에 사용자 지정 ICMP 규칙, 포트 범위에 시간 초과, TTL 전송 만료(유형 11, 코드 0)를 선택합니다. 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서EC2 인스턴스에 대한 네트워크 MTU(최대 전송 단위)를 참조하십시오.

네트워크 ACL 작업

다음 작업은 Amazon VPC 콘솔을 사용한 네트워크 ACL 작업 방법을 보여 줍니다.

네트워크 ACL 연결 확인

Amazon VPC 콘솔을 사용하여 특정 서브넷과 연결되어 있는 네트워크 ACL을 확인할 수 있습니다. 네트워크 ACL은 복수의 서브넷과 연결될 수 있으므로 특정 네트워크 ACL과 연결되어 있는 서브넷을 확인할 수도 있습니다.

서브넷과 연결되어 있는 네트워크 ACL을 확인하려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Subnets]를 선택한 후 서브넷을 선택합니다.

    서브넷과 연결된 네트워크 ACL은 네트워크 ACL의 규칙과 함께 [Network ACL] 탭에 포함되어 있습니다.

네트워크 ACL과 연결되어 있는 서브넷을 확인하려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Network ACLs]를 선택합니다. [Associated With] 열에 각 네트워크 ACL에 연결된 서브넷의 수가 표시됩니다.

  3. 네트워크 ACL을 선택합니다.

  4. 세부 정보 창에서 서브넷 연결을 선택하여 네트워크 ACL과 연결된 서브넷을 표시합니다.

네트워크 ACL 생성

VPC에 대한 사용자 지정 네트워크 ACL을 생성할 수 있습니다. 기본적으로, 생성된 네트워크 ACL은 사용자가 규칙을 추가할 때까지는 모든 인바운드 및 아웃바운드 트래픽을 차단하며, 사용자가 명시적으로 특정 서브넷과 연결할 때까지는 서브넷과 연결되지 않습니다.

네트워크 ACL을 생성하려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Network ACLs]를 선택합니다.

  3. [Create Network ACL]을 선택합니다.

  4. 네트워크 ACL 생성 대화 상자에서 선택적으로 네트워크 ACL의 이름을 지정한 다음 VPC 목록에서 VPC의 ID를 선택합니다. 그런 다음 예, 생성을 선택합니다.

규칙 추가 및 삭제

ACL에서 규칙을 추가하거나 삭제할 때 ACL과 연관된 서브넷이 변경될 수 있습니다. 서브넷의 인스턴스를 종료하고 다시 시작할 필요가 없습니다. 변경 사항은 잠시 후 적용됩니다.

중요

동시에 규칙을 추가하고 삭제하는 경우 매우 주의하세요. 네트워크 ACL 규칙은 VPC에 들어가거나 나올 수 있는 네트워크 트래픽 유형을 정의합니다. 인바운드 또는 아웃바운드 규칙을 삭제한 다음 Amazon VPC 할당량에서 허용된 항목보다 많은 새 항목을 추가하면 삭제하도록 선택한 항목이 제거되고 새 항목이 추가되지 않습니다. 이로 인해 예기치 않은 연결 문제가 발생하고 의도하지 않게 VPC에 대한 액세스가 차단될 수 있습니다.

Amazon EC2 API 또는 명령줄 도구를 사용하는 경우에는 규칙을 수정할 수 없습니다. 규칙을 추가 및 삭제할 수만 있습니다. Amazon VPC 콘솔을 사용하는 경우에는 기존 규칙의 항목을 수정할 수 있습니다. 콘솔은 기존 규칙을 제거하고 새 규칙을 추가합니다. ACL에서 규칙의 순서를 변경할 필요가 있는 경우에는 새 규칙 번호와 함께 새 규칙을 추가한 후에 원래 규칙은 삭제해야 합니다.

네트워크 ACL에 규칙을 추가하려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Network ACLs]를 선택합니다.

  3. 세부 정보 창에서 추가해야 할 규칙의 유형에 따라 [Inbound Rules] 또는 [Outbound Rules] 탭을 선택한 후 [Edit]를 선택합니다.

  4. [Rule #]에서 규칙 번호를 입력합니다(예: 100). 규칙 번호가 네트워크 ACL에서 이미 사용되고 있는 번호이면 안 됩니다. 규칙은 가장 낮은 번호부터 시작해서 순서대로 처리됩니다.

    순차 번호(101, 102, 103)를 사용하는 대신 규칙 번호 간에 간격을 두는 것이 좋습니다(예: 100, 200, 300). 그러면 기존 규칙의 번호를 다시 매길 필요 없이 새 규칙을 더 쉽게 추가할 수 있습니다.

  5. [Type] 목록에서 규칙을 선택합니다. 예를 들어 HTTP에 대한 규칙을 추가하려면 [HTTP]를 선택합니다. 모든 TCP 트래픽을 허용하는 규칙을 추가하려면 [All TCP]를 선택합니다. 이런 옵션 중 일부에 대해서는(예: HTTP) 포트가 자동으로 입력됩니다. 나열되지 않은 프로토콜을 사용하려면 [Custom Protocol Rule]을 선택합니다.

  6. (선택 사항) 사용자 지정 프로토콜 규칙을 생성할 경우 [Protocol] 목록에서 프로토콜의 번호와 이름을 선택합니다. 자세한 내용은 프로토콜 번호의 IANA 목록을 참조하십시오.

  7. (선택 사항) 선택한 프로토콜에 포트 번호가 필요한 경우 해당 포트 번호를 입력하거나 하이픈으로 구분된 포트 범위(예: 49152-65535)를 입력합니다.

  8. (인바운드 또는 아웃바운드 규칙인지에 따라) [Source] 또는 [Destination] 필드에 규칙이 적용되는 CIDR 범위를 입력합니다.

  9. [Allow/Deny] 목록에서 지정된 트래픽을 허용하려면 [ALLOW]를, 지정된 트래픽을 거부하려면 [DENY]를 선택합니다.

  10. (선택 사항) 또 다른 규칙을 추가하려면 [Add another rule]을 선택하고 필요에 따라 4~9단계를 반복합니다.

  11. 마치면 [Save]를 선택합니다.

네트워크 ACL에서 규칙을 삭제하려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Network ACLs]를 선택한 후 네트워크 ACL을 선택합니다.

  3. 세부 정보 창에서 [Inbound Rules] 또는 [Outbound Rules] 탭을 선택한 후 [Edit]를 선택합니다. 삭제하려는 규칙에서 [Remove]를 선택한 후 [Save]를 선택합니다.

서브넷을 네트워크 ACL과 연결

특정 서브넷에 네트워크 ACL의 규칙을 적용하려면 서브넷을 네트워크 ACL과 연결해야 합니다. 네트워크 ACL을 여러 서브넷과 연결할 수 있습니다. 그러나 서브넷은 하나의 네트워크 ACL에만 연결될 수 있습니다. 기본적으로, 특정 ACL과 연결되지 않은 서브넷은 기본 네트워크 ACL과 연결됩니다.

서브넷을 네트워크 ACL과 연결하려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Network ACLs]를 선택한 후 네트워크 ACL을 선택합니다.

  3. 세부 정보 창의 [Subnet Associations] 탭에서 [Edit]를 선택합니다. 네트워크 ACL과 연결할 서브넷에 대한 [Associate] 확인란을 선택한 후 [Save]를 선택합니다.

서브넷에서 네트워크 ACL 연결 해제

서브넷에서 사용자 지정 네트워크 ACL을 연결 해제할 수 있습니다. 서브넷이 사용자 지정 네트워크 ACL과의 연결이 끊어지면 기본 네트워크 ACL과 자동으로 연결됩니다.

네트워크 ACL에서 서브넷의 연결을 끊으려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Network ACLs]를 선택한 후 네트워크 ACL을 선택합니다.

  3. 세부 정보 창에서 [Subnet Associations] 탭을 선택합니다.

  4. [Edit]를 선택한 다음, 서브넷에 대한 [Associate] 확인란을 선택 취소합니다. Save를 선택합니다.

서브넷의 네트워크 ACL 변경

서브넷과 연결되어 있는 네트워크 ACL을 변경할 수 있습니다. 예를 들어 서브넷을 생성하면 생성된 서브넷이 처음에는 기본 네트워크 ACL과 연결됩니다. 서브넷을 사용자가 생성한 사용자 지정 네트워크 ACL과 대신 연결할 수도 있을 것입니다.

서브넷의 네트워크 ACL을 변경한 후에는 서브넷의 인스턴스를 종료했다가 다시 시작할 필요가 없습니다. 변경 사항은 잠시 후 적용됩니다.

서브넷의 네트워크 ACL 연결을 변경하려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Subnets]를 선택한 후 서브넷을 선택합니다.

  3. [Network ACL] 탭을 선택한 후 [Edit]를 선택합니다.

  4. 를 로 변경 목록에서 서브넷과 연결할 네트워크 ACL을 선택한 다음 저장을 선택합니다.

네트워크 ACL 삭제

네트워크 ACL과 연결된 서브넷이 없는 경우에만 네트워크 ACL을 삭제할 수 있습니다. 기본 네트워크 ACL은 삭제할 수 없습니다.

네트워크 ACL을 삭제하려면
  1. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  2. 탐색 창에서 [Network ACLs]를 선택합니다.

  3. 네트워크 ACL을 선택한 후 [Delete]를 선택합니다.

  4. 확인 대화 상자에서 [Yes, Delete]를 선택합니다.

API 및 명령 개요

명령줄 또는 API를 사용하여 이 페이지에서 설명하는 작업을 수행할 수 있습니다. 명령줄 인터페이스 및 사용 가능한 API 목록에 대한 자세한 내용은 Amazon VPC 작업 섹션을 참조하십시오.

VPC에 대한 네트워크 ACL 만들기
한 개 이상의 네트워크 ACL에 대해 설명
네트워크 ACL에 규칙 추가
네트워크 ACL에서 규칙 삭제
네트워크 ACL에 있는 기존 규칙 바꾸기
네트워크 ACL 연결 바꾸기
네트워크 ACL 삭제

Firewall Manager를 사용하여 네트워크 ACL 관리

AWS Firewall Manager는 여러 계정과 리소스 간에 네트워크 ACL 관리 및 유지 관리 작업을 간소화합니다. Firewall Manager를 사용하여 조직의 계정 및 서브넷을 모니터링하고 정의한 네트워크 ACL 구성을 자동으로 적용할 수 있습니다. Firewall Manager는 조직 전체를 보호해야 하거나 중앙 관리자 계정으로 자동 보호할 새 서브넷을 자주 추가하는 경우에 특히 유용합니다.

Firewall Manager 네트워크 ACL 정책을 사용하면 단일 관리자 계정을 사용하여 조직 전체에서 사용하는 네트워크 ACL에 정의하려는 최소 규칙 세트를 구성, 모니터링 및 관리할 수 있습니다. 조직의 어떤 계정과 서브넷이 Firewall Manager 정책 범위 내에 속하는지 지정합니다. Firewall Manager는 범위 내 서브넷에 대한 네트워크 ACL의 규정 준수 상태를 보고하며, 비준수 네트워크 ACL을 자동으로 수정하여 규정을 준수하도록 Firewall Manager를 구성할 수 있습니다.

Firewall Manager를 사용하여 네트워크 ACL을 관리하는 방법에 대한 자세한 내용은 AWS Firewall Manager 개발자 안내서의 다음 리소스를 참조하세요.

예: 서브넷의 인스턴스에 대한 액세스 제어

이 예에서는 서브넷의 인스턴스가 서로 통신할 수 있으며, 신뢰할 수 있는 원격 컴퓨터로부터 액세스될 수 있습니다. 원격 컴퓨터는 로컬 네트워크의 컴퓨터이거나 다른 서브넷 또는 VPC의 인스턴스일 수 있습니다. 원격 컴퓨터를 통해 인스턴스에 연결하여 관리 작업을 수행할 수 있습니다. 사용자의 보안 그룹 규칙 및 네트워크 ACL 규칙이 원격 컴퓨터의 IP 주소(172.31.1.2/32)로부터의 액세스를 허용합니다. 인터넷 또는 다른 네트워크로부터의 다른 모든 트래픽은 거부됩니다. 이 시나리오는 인스턴스에 대한 보안 그룹 또는 보안 그룹 규칙을 변경할 수 있고 네트워크 ACL을 방어의 백업 계층으로 사용할 수 있는 유연성을 제공합니다.

보안 그룹 및 NACL 사용

다음은 인스턴스와 연결할 보안 그룹의 예입니다. 보안 그룹은 상태가 저장됩니다. 따라서 인바운드 트래픽에 대한 응답을 허용하는 규칙은 필요하지 않습니다.

인바운드
프로토콜 유형 프로토콜 포트 범위 소스 설명
모든 트래픽 모두 모두 sg-1234567890abcdef0 이 보안 그룹과 연결된 모든 인스턴스는 서로 통신할 수 있습니다.
SSH TCP 22 172.31.1.2/32 원격 컴퓨터로부터의 인바운드 SSH 액세스를 허용합니다.
아웃바운드
프로토콜 유형 프로토콜 포트 범위 대상 주소 설명
모든 트래픽 모두 모두 sg-1234567890abcdef0 이 보안 그룹과 연결된 모든 인스턴스는 서로 통신할 수 있습니다.

다음은 인스턴스의 서브넷과 연결할 네트워크 ACL 예제입니다. 네트워크 ACL 규칙은 서브넷의 모든 인스턴스에 적용됩니다. 네트워크 ACL은 상태가 저장되지 않습니다. 따라서 인바운드 트래픽에 대한 응답을 허용하는 규칙이 필요합니다.

인바운드
규칙 # Type 프로토콜 포트 범위 소스 허용/거부 설명
100 SSH TCP 22 172.31.1.2/32 허용 원격 컴퓨터로부터의 인바운드 트래픽을 허용합니다.
* 모든 트래픽 모두 모두 0.0.0.0/0 DENY 다른 모든 인바운드 트래픽을 거부합니다.
아웃바운드
규칙 # Type 프로토콜 포트 범위 대상 주소 허용/거부 설명
100 사용자 지정 TCP TCP 1024~65535 172.31.1.2/32 허용 원격 컴퓨터에 대한 아웃바운드 응답을 허용합니다.
* 모든 트래픽 모두 모두 0.0.0.0/0 DENY 다른 모든 아웃바운드 트래픽을 거부합니다.

잘못하여 보안 그룹 규칙을 너무 허용하는 경우, 이 예제의 네트워크 ACL 규칙이 지정된 IP 주소의 액세스만 계속 허용하게 됩니다. 예를 들어 다음 보안 그룹에는 모든 IP 주소에서 인바운드 SSH 액세스를 허용하는 규칙이 포함되어 있습니다. 그러나 네트워크 ACL을 사용하는 서브넷의 인스턴스와 이 보안 그룹을 연결하면 서브넷과 원격 컴퓨터 내의 다른 인스턴스만 인스턴스에 액세스할 수 있습니다. 네트워크 ACL 규칙이 서브넷에 대한 다른 인바운드 트래픽을 거부하기 때문입니다.

인바운드
유형 프로토콜 포트 범위 소스 설명
모든 트래픽 모두 모두 sg-1234567890abcdef0 이 보안 그룹과 연결된 모든 인스턴스는 서로 통신할 수 있습니다.
SSH TCP 22 0.0.0.0/0 모든 IP 주소로부터의 SSH 액세스를 허용합니다.
아웃바운드
유형 프로토콜 포트 범위 대상 주소 설명
모든 트래픽 모두 모두 0.0.0.0/0 모든 아웃바운드 트래픽을 허용합니다.

연결 문제 해결

Reachability Analyzer는 정적 구성 분석 도구입니다. Reachability Analyzer를 사용하여 VPC의 두 리소스 간 네트워크 연결성을 분석하고 디버깅할 수 있습니다. Reachability Analyzer에서는 연결할 수 있는 경우 이러한 리소스 간 가상 경로에 대한 홉별 세부 정보가 생성되고, 그렇지 않다면 차단 구성 요소가 식별됩니다. 예를 들면 누락되거나 잘못 구성된 네트워크 ACL 규칙이 식별될 수 있습니다.

자세한 내용은 Reachability Analyzer 사용 설명서를 참조하십시오.