3. VPC — 네트워크와 연결 경로

결론부터

VPC 통신은 주소·경로·허용 규칙이 모두 맞아야 하며, 서브넷 이름만으로 공개 여부가 정해지지 않는다.

이 장에서 처음 나오는 말4개

VPCVirtual Private Cloud

AWS 자원을 배치하고 주소와 통신 경로를 정하는 논리적으로 분리된 가상 네트워크.

서브넷Subnet

VPC 주소 범위의 일부. 하나의 가용 영역 안에 만들고 자원을 배치한다.

AZAvailability Zone

한 리전 안에서 장애를 분리하도록 구성된 가용 영역.

라우트 테이블Route table

목적지 IP 범위에 따라 트래픽을 어디로 보낼지 정하는 경로 목록.

EC2를 만들었는데 접속되지 않거나, 서버는 살아 있는데 외부 API 호출만 실패할 수 있다. 이때 포트를 무작정 열기보다 자원이 어디에 있고 → 어디로 가며 → 어떤 규칙이 허용하는지를 순서대로 보면 원인을 좁힐 수 있다.

질문	담당 구성	확인할 것
어디에 배치했나?	VPC · 서브넷 · 네트워크 인터페이스	계정·리전·AZ·IP 주소
목적지까지 어떻게 가나?	라우트 테이블 · Gateway · Endpoint	서브넷 연결과 목적지별 경로
그 통신을 허용하나?	Security Group · Network ACL	프로토콜·포트·출발지·응답 방향
경로가 있는데 왜 실패하나?	DNS · OS 방화벽 · 애플리케이션	이름 해석·리스닝 주소·서비스 상태

이 장은 IPv4 기반 단일 VPC의 기초와 운영 점검에 집중한다. VPC 간 연결과 VPN·Direct Connect는 추후 별도 장으로 확장할 주제다. IAM은 AWS API 작업 권한을, VPC는 네트워크 통신을 다룬다. 관리자가 EC2를 생성할 수 있다고 그 서버의 TCP 포트에도 연결되는 것은 아니다.

리전·AZ와 자원의 위치부터 정리하고 싶다면 큰 그림의 배치 구조를 먼저 본다. 사진 앱에서도 EC2·EBS를 배치하는 경계와 S3 API에 접근하는 경로를 구분한다.

VPC·서브넷·주소 범위

리전과 AZ의 경계

VPC는 한 리전에 속하며 여러 AZ의 서브넷을 포함할 수 있다. 서브넷 하나는 AZ 하나에만 속한다. 같은 AZ에 public·private 서브넷을 각각 둘 수도 있다. 서브넷을 두 개 만들었다고 자동으로 다중 AZ 구성이 되는 것은 아니다. (VPC 개요, 서브넷의 범위)

EC2의 IP는 ENI(Elastic Network Interface, 가상 네트워크 인터페이스)에 연결된다. 서브넷을 확인할 때 인스턴스 이름뿐 아니라 실제 ENI·서브넷 ID·사설 IP를 같이 본다. (ENI 개념)

CIDR은 주소를 나누는 단위

CIDR(Classless Inter-Domain Routing)의 /숫자는 IP 주소의 네트워크 부분 길이다. IPv4에서 /24는 256개 주소 범위이며 /16보다 작다. 다음은 크기를 이해하기 위한 예시이고, 모든 계정에 이 크기가 필요하다는 뜻은 아니다.

범위	예시 CIDR	배치
VPC	10.20.0.0/16	한 리전
public-a	10.20.0.0/24	AZ A
private-a	10.20.10.0/24	AZ A
public-b	10.20.1.0/24	AZ B
private-b	10.20.11.0/24	AZ B

서브넷 범위는 VPC 범위 안에 있어야 하고 서로 겹치면 안 된다. 일반적인 AWS 제공 IPv4 서브넷은 첫 4개와 마지막 1개 주소를 AWS가 예약하므로 /24에서 자원에 할당 가능한 주소는 251개다. 나중에 연결할 VPC·회사망·VPN 대역과도 겹치지 않게 계획한다. (서브넷 CIDR 규칙)

라우팅과 public·private 구분

서브넷이 실제로 사용하는 테이블

서브넷마다 라우트 테이블 하나가 적용된다. 명시적으로 연결하지 않으면 VPC의 main route table을 사용하고, 하나의 테이블을 여러 서브넷이 공유할 수 있다. 이름이 비슷한 테이블을 수정하는 실수를 피하려면 VPC → Subnets → 대상 → Route table에서 실제 연결부터 본다. (라우트 테이블)

기본 구성에서 VPC 내부 주소는 local 경로로 통신한다. 외부로 갈 기본 경로는 IPv4의 0.0.0.0/0이며, 더 구체적으로 일치하는 목적지 경로가 있으면 그 경로를 우선한다.

서브넷 용도	목적지	대상
public-a	10.20.0.0/16	local
public-a	0.0.0.0/0	Internet Gateway (igw-…)
private-a	10.20.0.0/16	local
private-a	0.0.0.0/0	NAT Gateway (nat-…, 외부 IPv4 연결이 필요할 때)

Internet Gateway로 직접 가는 경로가 있으면 public subnet, 없으면 private subnet이다. 일반적인 인터넷 공개 구성은 위처럼 기본 경로를 IGW로 둔다. 외부 경로 없이 VPC 내부 통신만 하도록 구성한 서브넷은 isolated subnet이라고 부른다. (서브넷 유형, 라우팅 예시)

이름과 공인 IP 자동 할당은 라우팅을 대신하지 않는다

서브넷 이름에 public을 붙이거나 Auto-assign public IPv4를 켜도 IGW 경로는 생기지 않는다. 반대로 public subnet에 둔 EC2라도 공인 IPv4와 허용 규칙이 없으면 인터넷에서 직접 접근할 수 없다.

인터넷 연결: IGW와 NAT

직접 연결하는 EC2

IGW(Internet Gateway)는 VPC에 연결하는 인터넷 게이트웨이다. EC2가 IPv4로 인터넷과 직접 통신하려면 VPC에 연결된 IGW, 서브넷의 IGW 경로, EC2의 공인 IPv4 또는 Elastic IP, 통신을 허용하는 보안 규칙이 맞아야 한다. OS 방화벽과 애플리케이션도 별도로 확인한다. (인터넷 연결 조건)

Elastic IP는 고정 공인 IPv4다. 고정 주소가 필요할 때 쓰는 것이며 인터넷 경로·방화벽 설정을 자동으로 해결해 주지는 않는다.

private 서버에서 시작하는 외부 연결

NAT(Network Address Translation)는 주소를 변환한다. 서버에 직접 공인 IPv4를 주지 않고 패키지 다운로드·외부 API 호출을 하려면 public NAT Gateway를 경유할 수 있다. 서버가 시작한 연결의 응답은 돌아오지만, 인터넷에서 서버로 새 연결을 시작하는 입구는 아니다. (NAT Gateway 동작)

아래는 AZ 하나의 zonal public NAT를 사용하는 IPv4 요청 경로다. 라우트 테이블은 실제 장비 노드 대신 화살표에 표시했다. SG·NACL과 응답 방향은 생략했다.

private 서브넷에 NAT를 가리키는 경로만 넣어서는 부족하다. 이 구성에서는 NAT가 있는 public 서브넷에도 IGW 경로가 있어야 한다. private NAT Gateway는 사설망 간 주소 변환용이므로 인터넷 출구용 public NAT와 혼동하지 않는다. (NAT 유형과 경로)

AZ 배치와 Regional NAT

Zonal NAT 하나를 여러 AZ에서 공유하면 그 NAT의 AZ 장애가 다른 AZ의 인터넷 연결에도 영향을 준다. 운영 환경에서는 AZ별 NAT와 같은 AZ로 향하는 경로를 검토한다. (Zonal NAT의 가용성)

현재는 Regional NAT Gateway도 제공된다. 여러 AZ에서 하나의 NAT ID로 경로를 지정하며, 워크로드가 있는 AZ에 맞춰 확장한다. 위 그림과 달리 NAT를 넣을 public subnet이 필요 없고 자체 라우트 테이블을 사용한다. 따라서 “NAT는 반드시 public subnet에 만든다”는 설명은 위의 zonal public NAT 구성에 한정해 읽는다. 생성 화면에서 모드와 과금 범위를 확인한다. (Regional NAT)

IPv6는 경로를 별도로 생각한다

IPv6의 기본 경로는 ::/0이다. IPv6에서 외부로 시작한 연결만 허용하는 출구는 egress-only internet gateway를 사용할 수 있다. 이것은 IPv4 NAT와 같은 주소 변환 장치가 아니다. IPv6-only 자원에서 IPv4 목적지로 가는 NAT64·DNS64 구성은 이 장의 기본 예시와 별개다. (IPv6 외부 연결)

보안 그룹과 Network ACL

경로와 허용 규칙을 구분하기

라우트 테이블은 목적지까지 어디로 보낼지, 보안 규칙은 통과시킬지를 정한다. 같은 VPC에 local 경로가 있어도 SG(Security Group, 보안 그룹)가 허용하지 않으면 연결되지 않는다.

비교	Security Group	NACL (Network Access Control List)
적용 범위	연결된 ENI·자원	연결된 서브넷 경계
규칙	Allow만 정의	Allow와 Deny
평가	연결된 SG들의 허용 규칙을 합침	낮은 규칙 번호부터 첫 일치 적용
연결 상태	Stateful: 허용된 연결의 응답 자동 허용	Stateless: 응답 방향도 허용해야 함
주 용도	자원별 필요한 통신 제어	서브넷 단위의 추가 통제

AWS는 SG를 기본 통제 수단으로, NACL을 필요한 경우 추가 통제로 사용하도록 권장한다. (SG와 NACL 비교)

앱과 DB 사이에 필요한 포트만 열기

예를 들어 앱 EC2가 PostgreSQL DB에 접근한다면 DB의 SG에서 TCP 5432, source = 앱의 SG를 허용한다. 앱 쪽 egress도 허용돼야 한다. SG 참조는 그 SG에 연결된 자원의 사설 IP를 기준으로 접근을 허용하는 방식이며, 상대 SG의 모든 규칙을 복사하거나 경로를 만드는 기능이 아니다. (SG 규칙과 참조)

SSH 22·RDP 3389·DB 포트를 0.0.0.0/0에 열어 문제를 해결하려 하지 않는다. 관리 접속은 제한한 출발지 또는 Session Manager 같은 경로를 검토한다. Session Manager도 IAM 권한·에이전트·서비스 Endpoint 연결 조건이 있어 NAT를 지우기만 하면 작동하는 것은 아니다. (Session Manager 사전 조건)

NACL에서 응답이 막히는 경우

클라이언트가 서버의 443으로 연결하면 응답은 클라이언트의 임시 포트(ephemeral port)로 돌아간다. NACL에서 443만 양쪽에 열어 놓으면 응답이 차단될 수 있다. 실제 클라이언트의 포트 범위와 입·출력 방향을 맞춰 확인한다. 기본 NACL은 기본적으로 허용하지만, 새 custom NACL은 규칙을 추가하기 전 모두 거부한다. (NACL 동작, 임시 포트)

AWS 서비스 연결: Endpoint와 DNS

모든 요청을 NAT로 보내야 할까?

VPC Endpoint는 인터넷 출구를 거치지 않고 지원되는 AWS 서비스에 접근하는 경로다. S3·DynamoDB만 호출하려는데 NAT를 만드는 경우에는 Gateway Endpoint부터 비교한다.

방식	연결 원리	확인할 설정	비용 관점
Gateway Endpoint	S3·DynamoDB 대상 경로를 라우트 테이블에 추가	사용할 라우트 테이블·Endpoint 정책	Endpoint 자체 추가 요금 없음
Interface Endpoint	선택한 서브넷에 사설 IP를 가진 ENI 생성, PrivateLink 사용	서비스·AZ·SG·DNS·정책	배치 시간·처리량 과금

Gateway Endpoint는 서비스 IP 범위를 나타내는 prefix list 경로를 사용한다. 더 구체적인 서비스 경로가 기본 NAT 경로보다 우선하므로 해당 요청이 NAT를 우회할 수 있다. (Gateway Endpoint)

Interface Endpoint는 필요한 서비스별로 만든다. SG의 HTTPS 인바운드와 클라이언트의 아웃바운드도 확인한다. Endpoint 정책은 IAM·자원 정책을 대신해 권한을 부여하는 것이 아니라, 그 경로에서 허용할 접근 범위를 추가로 제한한다. (Interface Endpoint 설정, Endpoint 정책)

이름이 어느 IP로 해석되는지 확인

DNS(Domain Name System)가 의도와 다르게 공인 서비스 주소를 반환하면 Endpoint를 만들었어도 NAT로 나가거나 연결이 실패할 수 있다. Interface Endpoint의 Private DNS를 사용하면 지원되는 기본 서비스 도메인이 Endpoint의 사설 IP로 해석되도록 구성할 수 있다.

VPC의 enableDnsSupport와 enableDnsHostnames를 모두 확인한다. Private DNS 사용에는 둘 다 활성화되어야 하며, 자체 DNS 서버를 사용한다면 질의 전달 경로도 확인한다. (VPC DNS 속성, Endpoint의 Private DNS)

구성과 비용을 함께 점검하기

VPC 자체를 만든다고 별도 이용료가 생기지는 않지만 NAT Gateway·Interface Endpoint·공인 IPv4· 데이터 전송·로그와 진단 도구는 비용을 만들 수 있다. 콘솔의 VPC and more 마법사에서도 NAT 수와 Endpoint 선택을 확인한다. 학습 중 필요 없는 출구를 미리 만들지 않는다. (VPC 생성, VPC 요금, PrivateLink 요금)

연결 요구	먼저 검토할 구성
VPC 안의 앱과 DB만 통신	local 경로와 자원별 SG. 인터넷 출구가 실제로 필요한지 별도 판단
private 서버가 S3·DynamoDB 사용	Gateway Endpoint와 해당 테이블 연결
private 서버가 지원 AWS API만 사용	필요한 Interface Endpoint의 기능·DNS·비용 비교
private 서버가 임의의 외부 API 사용	NAT 출구와 가용성·처리량 비용
인터넷에서 웹 요청 수신	공개 진입점과 private 앱을 분리하는 구조 검토

NAT 하나로 모으면 배치 비용은 줄 수 있지만 AZ 간 전송 비용과 장애 영향을 함께 봐야 한다. Endpoint도 여러 서비스·AZ에 만들면 고정 비용이 쌓이므로 항상 더 저렴하다고 단정하지 않는다. 사용 후에는 NAT·Endpoint·Elastic IP가 남았는지 비용 페이지의 정리 기준으로 확인한다.

연결 문제 진단

콘솔에서 확인하는 순서

1. 출발지와 목적지를 적는다. 계정·리전·IP·프로토콜·포트, DNS 이름과 해석된 IP를 확인한다.
2. 출발지 ENI와 서브넷을 찾는다. EC2의 Networking과 VPC의 Subnets 화면을 연결해 본다.
3. 실제 연결된 라우트 테이블에서 목적지와 일치하는 경로·대상 상태를 확인한다. 명시적 연결이 없으면 main table을 본다. VPC 내부인지 IGW·NAT·Endpoint 경유인지 구분한다.
4. SG와 NACL에서 요청과 응답 방향을 확인한다. IGW 직접 연결이면 공인 주소도 확인하고, 경로·규칙이 맞는데 인터넷만 막히면 VPC Block Public Access 설정도 본다.
5. 목적지 서비스가 실제 포트에서 듣는지, 127.0.0.1에만 바인딩됐는지, OS 방화벽·TLS·프록시 문제가 있는지 확인한다. 네트워크가 열려도 애플리케이션 인증은 별도로 실패할 수 있다.

VPC Block Public Access는 IGW 등을 통한 인터넷 통신을 추가로 차단할 수 있는 통제다. (VPC BPA)

CLI로 현재 구성을 조회하기

아래 vpc-… 값은 실제 VPC ID로 바꾼다. 프로파일은 IAM 장에서 만든 예시이며, 리전도 자기 자원의 리전으로 바꾼다. 이 명령들은 구성 조회용이다.

aws sts get-caller-identity --profile tf-study
aws ec2 describe-vpcs --profile tf-study --region ap-northeast-2
aws ec2 describe-subnets --profile tf-study --region ap-northeast-2 \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0
aws ec2 describe-route-tables --profile tf-study --region ap-northeast-2 \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0
aws ec2 describe-security-groups --profile tf-study --region ap-northeast-2 \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0

Associations에서 서브넷 ID와 Main 여부를, Routes에서 목적지·대상·State를 본다. blackhole이면 삭제된 대상 등으로 경로를 사용할 수 없는 상태를 의심한다. (라우트 테이블 조회)

분석 도구가 답하는 질문

Reachability Analyzer는 지원되는 출발지·목적지 사이의 설정을 분석해 막힌 구성 요소를 찾는다. 실제 패킷을 보내거나 프로세스의 리스닝 상태를 검사하는 도구는 아니다. (Reachability Analyzer)

VPC Flow Logs는 ENI의 IP 트래픽 메타데이터를 기록한다. ACCEPT·REJECT와 출발지·목적지·포트로 통신 흔적을 좁힐 수 있지만 패킷 본문을 캡처하지 않는다. ACCEPT도 애플리케이션 요청의 성공을 보장하지 않는다. 모든 트래픽이 기록되지는 않으며 수집·저장 비용과 보존 기간을 정해야 한다. (VPC Flow Logs)

VPC 구축 실습 해설

AWS Training의 실습 2: Amazon VPC 인프라 구축을 따라 했다면, 다음에는 설정 하나를 바꿨을 때 어떤 요청이 실패할지 먼저 예측해 본다. 아래는 제공된 실습 버전 7.12.4의 단일 AZ·IPv4·Zonal public NAT 구성을 바탕으로 쓴 해설이다. 콘솔 절차를 재현하는 대신 설계자가 고른 값과 통신에 필요한 조건을 구분한다.

세 가지 요청으로 구성 읽기

다음 표는 요청 방향을 보여준다. 기본 NACL과 SG 아웃바운드 허용을 유지하고, 웹 서버가 실행 중이라고 가정한다.

요청	선택되는 경로	확인할 조건
내 브라우저 → Public EC2의 HTTP	인터넷 → IGW → EC2	EC2 공인 IPv4, public 서브넷의 IGW 경로, Public SG의 TCP 80 인바운드
Public EC2 → Private EC2의 사설 IP로 HTTP	VPC 내부 local	Private SG의 TCP 80 출발지가 Public SG
Private EC2 → 외부 HTTPS 사이트	EC2 → NAT → IGW → 인터넷	private 서브넷의 NAT 경로, NAT가 있는 public 서브넷의 IGW 경로와 NAT의 Elastic IP

두 EC2 사이의 사설 IP 통신은 NAT나 IGW를 거치지 않는다. 목적지 10.0.2.x에는 0.0.0.0/0보다 구체적인 10.0.0.0/16 → local 경로가 우선한다. (라우팅 우선순위, IGW 연결 조건, NAT 경로)

Private SG에서 Public SG를 참조해도 Public EC2가 브라우저 요청을 자동으로 전달하지는 않는다. SG 참조는 해당 SG가 연결된 ENI의 사설 IP에서 오는 지정 포트 통신을 허용할 뿐이다. 브라우저 → Public EC2 → Private EC2로 앱 요청을 전달하려면 별도의 앱 호출이나 프록시 구성이 필요하다. (SG 참조의 의미)

주소 크기는 설계 선택이다

실습의 주소 범위	전체 주소 수	선택 이유
VPC 10.0.0.0/16	65,536	여러 서브넷을 배치할 주소 공간 확보
Public 10.0.0.0/24	256	공개 자원용 주소 공간
Private 10.0.2.0/23	512	내부 자원을 더 많이 둔다는 실습의 가정

IPv4 CIDR의 주소 수는 2^(32 − prefix 길이)다. 일반적인 AWS IPv4 서브넷의 예약 주소 5개를 빼면 /24는 251개, /23은 507개를 자원에 할당할 수 있다. 프라이빗 서브넷이 반드시 두 배여야 하는 것은 아니다. VPC 범위 안에서 서로 겹치지 않게 만들고, 필요한 자원 수와 확장 여유로 크기를 고른다. (서브넷 CIDR 규칙)

10.0.2.0/23은 10.0.2.0부터 10.0.3.255까지다. /23은 세 번째 숫자가 0·1, 2·3, 4·5처럼 두 칸씩 묶이므로 10.0.1.0/23을 지정해도 1·2 범위가 되지 않는다. 정규화하면 10.0.0.0/23이어서 기존 public 서브넷과 겹친다. 남은 10.0.1.0/24는 나중을 위해 비워 두어도 된다. 같은 AZ에 두 서브넷을 둔 것은 실습을 단순화한 선택이며 다중 AZ 구성이 아니다.

같은 값도 설정 위치에 따라 뜻이 다르다

라우트 테이블에서 0.0.0.0/0은 모든 IPv4 목적지에 대한 기본 경로이고, SG 인바운드에서 같은 값은 모든 IPv4 출발지에서 오는 지정 프로토콜·포트를 허용한다는 뜻이다. 경로 추가와 포트 허용을 각각 해야 하는 이유다. (경로 선택, SG 규칙의 필드)

서브넷의 공인 IPv4 자동 할당은 인스턴스를 시작할 때 쓸 기본값이다. EC2 시작 화면에서도 Enable을 선택하는 것은 그 인스턴스가 공인 주소를 받도록 명시하는 것이다. 어느 설정도 IGW 경로를 만들지는 않는다. (공인 IPv4 할당)

DNS hostnames를 켜는 것은 이 실습에서 공인 IPv4가 있는 EC2에 공인 DNS 이름을 제공하기 위해서다. DNS support도 활성화되어야 한다. 모든 EC2에 공인 DNS가 생기거나 인터넷 경로가 열리는 설정은 아니다. (VPC DNS 속성)

Session Manager는 인스턴스가 시작한 연결을 쓴다

프라이빗 EC2에 공인 IP와 SSH 키가 없는데 셸 접속이 가능한 이유는 SSM Agent가 AWS 서비스로 아웃바운드 HTTPS 연결을 만들기 때문이다. 이 구성에서는 NAT·IGW를 통해 서비스 Endpoint에 도달한다. SSH 22 인바운드는 필요 없지만 에이전트, 인스턴스의 IAM 권한, 사용자의 세션 시작 권한, 서비스까지의 네트워크 연결은 모두 필요하다. (Session Manager 사전 조건)

실습의 EC2InstProfile은 EC2에 IAM 역할을 전달하는 instance profile이다. 필요한 SSM 권한이 그 역할에 있어야 하며, 프로파일을 붙이는 것만으로 네트워크 경로가 생기지는 않는다. 가이드가 Public Instance와 Private Instance 이름을 정확히 요구하는 것은 실습 환경의 태그 기반 SSM 권한 조건이다. 일반적인 AWS 네트워크의 필수 이름이 아니다. (인스턴스 프로파일과 SSM 권한)

첫 부팅의 설치도 네트워크에 의존한다

실습에서 NAT를 먼저 준비하고 Private EC2를 만드는 이유는 첫 부팅의 사용자 데이터가 패키지와 웹 파일을 다운로드하기 때문이다. t3.micro·AMI·스토리지 선택은 실행 환경을 정하고, 사용자 데이터는 그 안에 웹 서버를 설치한다. 이 값들이 public·private 여부를 정하지는 않는다.

EC2의 Running·상태 검사 통과와 사용자 데이터 완료·웹 서버 정상 응답은 구분한다. 페이지가 안 열리면 sudo cloud-init status, sudo tail -n 80 /var/log/cloud-init-output.log, systemctl status httpd로 초기화와 서비스를 확인한다. 사용자 데이터는 기본적으로 최초 부팅 때 실행되므로, 다운로드 실패 뒤 경로만 복구했다고 설치가 자동으로 다시 실행된다고 가정하지 않는다. (사용자 데이터 실행과 로그, EC2 상태 검사 범위)

설정 하나를 바꾸고 결과 예측하기

다른 설정과 서비스는 정상이라는 가정으로 읽는다. 실제로 시험한다면 한 항목씩 바꾸고 복구한 뒤 다음 항목으로 넘어간다. NAT 경로를 제거하면 이 실습의 Session Manager 연결도 영향을 받으므로 인스턴스 셸이 아닌 VPC 콘솔에서 경로를 복구한다.

변경·관찰	예상 결과와 이유
Private 서브넷의 NAT 기본 경로 제거	외부 IPv4 요청 실패. Public → Private 사설 IP HTTP는 local 경로라 계속 가능
Private SG의 HTTP 인바운드 제거	Public → Private HTTP 실패. Private에서 시작하는 외부 요청은 아웃바운드 허용으로 계속 가능
HTTP 허용 상태에서 Private IP에 ping	HTTP와 달리 ICMP는 허용하지 않았으므로 실패. ping 실패만으로 모든 통신이 막혔다고 판단할 수 없음
Private SG에 Public SG 출발지의 ICMP Echo Request 허용	Public EC2에서 보내는 ping 가능. TCP 포트를 추가하는 설정이 아님
Public EC2의 웹 서버 중지	주소·라우팅·SG가 맞아도 HTTP 서비스에 접속 불가
외부 curl -I에서 HTTP 응답 수신	해당 목적지까지 요청·응답이 오갔다는 증거. 외부에서 이 EC2로 새 연결을 시작할 수 있다는 증거는 아님

SG는 허용된 연결의 응답을 자동 허용하므로, Private EC2가 시작한 HTTPS 요청의 응답을 받기 위해 인바운드 443을 따로 열 필요는 없다. ICMP 허용과 아웃바운드 기본값도 함께 확인한다. (SG의 상태 추적, 프로토콜·ICMP 규칙)

운영 체크리스트

• VPC 리전과 서브넷 AZ, CIDR과 남은 IP를 확인했다.
• 서브넷 이름이 아닌 실제 연결 테이블로 public·private을 판단한다.
• 인터넷 연결에 필요한 공인 주소·IGW·NAT 경로를 구분한다.
• SG는 자원별 최소 통신만 허용하고, NACL은 응답 방향까지 확인한다.
• Endpoint 사용 시 DNS·SG·IAM·Endpoint 정책을 함께 본다.
• 다중 AZ의 NAT 경로와 비용·장애 영향을 설명할 수 있다.
• 실습 후 NAT·Endpoint·Elastic IP와 로그 보존을 점검한다.

2. 비용 확인과 과금 방지NAT·Endpoint·공인 IPv4 비용을 추적하고 남은 자원을 정리한다.

4. 컴퓨팅 — EC2·컨테이너·Lambda네트워크 위에서 앱을 실행할 단위와 관리 책임을 고른다.