💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

1. VPC 네트워킹 기초와 트러블슈팅 개요

클라우드 환경에서 네트워크 문제는 가장 빈번하면서도 진단이 어려운 이슈 중 하나입니다. 온프레미스와 달리 물리적 장비에 직접 접근할 수 없기 때문에, 클라우드 제공자가 제공하는 도구와 로그를 활용한 체계적인 접근이 필요합니다.

1.1 VPC(Virtual Private Cloud) 기본 구조

VPC는 클라우드 내 논리적으로 격리된 네트워크 공간입니다. 각 클라우드 벤더별 용어는 다르지만 핵심 개념은 동일합니다.

| 개념 | AWS | GCP | Azure |

| ---------------- | -------------- | ----------------- | ----------------- |

| 가상 네트워크 | VPC | VPC | VNet |

1.2 체계적인 트러블슈팅 접근법

네트워크 문제를 진단할 때는 OSI 7계층 모델을 역으로 따라가는 것이 효과적입니다.

트러블슈팅 순서:

1. 애플리케이션 계층 (L7) — DNS 확인, HTTP 응답 코드

2. 전송 계층 (L4) — 포트 연결성, TCP handshake

3. 네트워크 계층 (L3) — IP 라우팅, 서브넷 CIDR

4. 보안 계층 — Security Group, NACL, 방화벽 규칙

5. 인프라 계층 — IGW, NAT GW, VPN, Peering 상태

1.3 기본 연결성 테스트 명령어

기본 연결 테스트

ping -c 4 10.0.1.50

특정 포트 연결성 확인

nc -zv 10.0.1.50 443 -w 5

TCP 연결 상세 추적

traceroute -T -p 443 10.0.1.50

DNS 조회 테스트

dig +trace example.com

nslookup example.com 10.0.0.2

curl을 이용한 HTTP 레벨 디버깅

curl -vvv --connect-timeout 5 https://api.internal.example.com/health

2. Security Groups vs NACLs 디버깅

2.1 Security Group과 NACL의 핵심 차이

두 보안 메커니즘의 차이를 정확히 이해하지 못하면 트러블슈팅에서 많은 시간을 낭비하게 됩니다.

Security Group (상태 저장형 - Stateful):

✓ 인바운드 허용 시, 해당 응답 트래픽 자동 허용

✓ 인스턴스(ENI) 레벨에서 적용

✓ 허용 규칙만 지정 (암묵적 거부)

✓ 규칙 평가: 모든 규칙을 평가하여 허용 여부 결정

NACL (상태 비저장형 - Stateless):

✓ 인바운드/아웃바운드 규칙을 각각 별도로 설정해야 함

✓ 서브넷 레벨에서 적용

✓ 허용 및 거부 규칙 모두 지정 가능

✓ 규칙 평가: 규칙 번호 순서대로 평가 (첫 번째 매칭 적용)

2.2 흔한 Security Group 문제와 해결

AWS CLI로 Security Group 규칙 확인

aws ec2 describe-security-groups \

--group-ids sg-0abc1234def56789 \

--query 'SecurityGroups[*].{

GroupId:GroupId,

Ingress:IpPermissions,

Egress:IpPermissionsEgress

}' \

--output json

특정 인스턴스에 연결된 Security Group 확인

aws ec2 describe-instances \

--instance-ids i-0abcdef1234567890 \

--query 'Reservations[*].Instances[*].SecurityGroups' \

--output table

**사례 1: 아웃바운드 규칙 누락**

문제: EC2에서 외부 API 호출 실패

원인: Security Group의 기본 아웃바운드 규칙(0.0.0.0/0 허용)이 삭제됨

해결:

aws ec2 authorize-security-group-egress \

--group-id sg-0abc1234def56789 \

--protocol tcp --port 443 \

--cidr 0.0.0.0/0

**사례 2: 자기 참조 규칙 미설정**

문제: 같은 Security Group 내 인스턴스 간 통신 실패

원인: SG가 자기 자신을 소스로 허용하는 규칙이 없음

해결:

aws ec2 authorize-security-group-ingress \

--group-id sg-0abc1234def56789 \

--protocol -1 \

--source-group sg-0abc1234def56789

2.3 NACL 디버깅 패턴

NACL 규칙 확인

aws ec2 describe-network-acls \

--network-acl-ids acl-0abc1234 \

--query 'NetworkAcls[*].Entries' \

--output json

**임시 포트(Ephemeral Port) 문제 — 가장 흔한 NACL 이슈:**

문제: 아웃바운드 HTTP 요청의 응답을 받지 못함

원인: NACL에서 임시 포트 범위(1024-65535)에 대한 인바운드 규칙이 없음

NACL 규칙 예시 (올바른 설정):

인바운드:

Rule 100: TCP 443 허용 (0.0.0.0/0)

Rule 110: TCP 1024-65535 허용 (0.0.0.0/0) ← 이것이 반드시 필요

Rule *: 모든 트래픽 거부

아웃바운드:

Rule 100: TCP 443 허용 (0.0.0.0/0)

Rule 110: TCP 1024-65535 허용 (0.0.0.0/0) ← 응답 트래픽

Rule *: 모든 트래픽 거부

3. VPC Peering과 Transit Gateway 이슈

3.1 VPC Peering 트러블슈팅

VPC Peering은 두 VPC 간 프라이빗 네트워크 연결을 제공하지만, 여러 제약 사항이 있습니다.

VPC Peering 제약사항:

✗ 전이적 피어링(Transitive Peering) 불가

VPC-A ↔ VPC-B ↔ VPC-C 에서 A→C 직접 통신 불가

✗ CIDR 중복 불가

✗ 리전 간 피어링 시 Security Group 참조 불가(일부 리전)

VPC Peering 상태 확인

aws ec2 describe-vpc-peering-connections \

--filters "Name=status-code,Values=active,pending-acceptance" \

--query 'VpcPeeringConnections[*].{

PeeringId:VpcPeeringConnectionId,

Status:Status.Code,

Requester:RequesterVpcInfo.{VpcId:VpcId,CidrBlock:CidrBlock},

Accepter:AccepterVpcInfo.{VpcId:VpcId,CidrBlock:CidrBlock}

라우팅 테이블에 피어링 경로 확인

aws ec2 describe-route-tables \

--filters "Name=vpc-id,Values=vpc-0abc1234" \

--query 'RouteTables[*].Routes[?GatewayId!=`local`]'

**흔한 실수: 라우팅 테이블 미설정**

문제: Peering 연결은 Active 상태이지만 통신 불가

원인: 양쪽 VPC의 라우팅 테이블에 피어링 경로를 추가하지 않음

해결:

VPC-A의 라우팅 테이블에 VPC-B CIDR 추가

aws ec2 create-route \

--route-table-id rtb-aaa111 \

--destination-cidr-block 10.1.0.0/16 \

--vpc-peering-connection-id pcx-0abc1234

VPC-B의 라우팅 테이블에 VPC-A CIDR 추가

aws ec2 create-route \

--route-table-id rtb-bbb222 \

--destination-cidr-block 10.0.0.0/16 \

--vpc-peering-connection-id pcx-0abc1234

3.2 Transit Gateway 문제 해결

Transit Gateway는 허브-스포크 모델로 여러 VPC와 온프레미스 네트워크를 연결합니다.

Transit Gateway 라우팅 테이블 확인

aws ec2 describe-transit-gateway-route-tables \

--transit-gateway-route-table-ids tgw-rtb-0abc1234

Transit Gateway 연결(Attachment) 상태 확인

aws ec2 describe-transit-gateway-attachments \

--filters "Name=transit-gateway-id,Values=tgw-0abc1234" \

--query 'TransitGatewayAttachments[*].{

AttachmentId:TransitGatewayAttachmentId,

ResourceType:ResourceType,

State:State

TGW 라우팅 테이블의 경로 조회

aws ec2 search-transit-gateway-routes \

--transit-gateway-route-table-id tgw-rtb-0abc1234 \

--filters "Name=type,Values=static,propagated"

**TGW 라우팅 전파(Propagation) 문제:**

문제: TGW에 연결된 VPC 간 통신 실패

체크리스트:

□ TGW Attachment가 available 상태인가?

□ TGW Route Table에 경로가 전파(propagated)되어 있는가?

□ 각 VPC의 서브넷 라우팅 테이블에 TGW 경로가 있는가?

□ TGW Route Table Association이 올바른가?

4. AWS/GCP/Azure 네트워크 트러블슈팅

4.1 AWS 고유 네트워크 문제

VPC Reachability Analyzer 사용 (강력한 진단 도구)

aws ec2 create-network-insights-path \

--source i-0abc1234 \

--destination i-0def5678 \

--protocol TCP \

--destination-port 443

aws ec2 start-network-insights-analysis \

--network-insights-path-id nip-0abc1234

결과 확인

aws ec2 describe-network-insights-analyses \

--network-insights-analysis-ids nia-0abc1234 \

--query 'NetworkInsightsAnalyses[*].{

Status:Status,

PathFound:NetworkPathFound,

Explanations:Explanations

4.2 GCP 네트워크 디버깅

GCP 방화벽 규칙 확인

gcloud compute firewall-rules list \

--filter="network=my-vpc" \

--format="table(name,direction,priority,allowed,sourceRanges,targetTags)"

Connectivity Test 실행 (GCP의 Reachability Analyzer)

gcloud network-management connectivity-tests create my-test \

--source-instance=projects/my-project/zones/us-central1-a/instances/vm-1 \

--destination-instance=projects/my-project/zones/us-central1-b/instances/vm-2 \

--protocol=TCP \

--destination-port=8080

결과 확인

gcloud network-management connectivity-tests describe my-test

4.3 Azure 네트워크 진단

NSG Flow 확인

az network nsg rule list \

--nsg-name my-nsg \

--resource-group my-rg \

--output table

Network Watcher를 이용한 연결성 확인

az network watcher test-connectivity \

--resource-group my-rg \

--source-resource vm-source \

--dest-resource vm-dest \

--dest-port 443

Effective Routes 확인

az network nic show-effective-route-table \

--name my-nic \

--resource-group my-rg

5. VPC Flow Logs 분석

5.1 Flow Logs 설정과 필드 이해

VPC Flow Logs는 네트워크 트러블슈팅의 핵심 데이터 소스입니다.

AWS VPC Flow Logs 활성화

aws ec2 create-flow-logs \

--resource-type VPC \

--resource-ids vpc-0abc1234 \

--traffic-type ALL \

--log-destination-type cloud-watch-logs \

--log-group-name /vpc/flow-logs \

--deliver-logs-permission-arn arn:aws:iam::123456789012:role/flowlogsRole \

--max-aggregation-interval 60

Flow Log 레코드 형식:

예시:

2 123456789012 eni-0abc1234 10.0.1.50 10.0.2.100 49152 443 6 20 4000 1625000000 1625000060 ACCEPT OK

2 123456789012 eni-0abc1234 203.0.113.5 10.0.1.50 0 0 1 4 336 1625000000 1625000060 REJECT OK

5.2 CloudWatch Logs Insights로 분석

-- 거부된 트래픽 Top 10 소스 IP

fields @timestamp, srcAddr, dstAddr, dstPort, action

| filter action = "REJECT"

| stats count(*) as rejectedCount by srcAddr

| sort rejectedCount desc

| limit 10

-- 특정 IP의 트래픽 패턴 분석

fields @timestamp, srcAddr, dstAddr, srcPort, dstPort, protocol, action

| filter srcAddr = "10.0.1.50" or dstAddr = "10.0.1.50"

| sort @timestamp desc

| limit 100

-- 비정상적인 포트 스캔 탐지

fields srcAddr, dstPort, action

| filter action = "REJECT"

| stats count(dstPort) as portCount by srcAddr

| filter portCount > 100

| sort portCount desc

5.3 Athena를 사용한 대용량 Flow Log 분석

-- Athena 테이블 생성

CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (

version int,

account_id string,

interface_id string,

srcaddr string,

dstaddr string,

srcport int,

dstport int,

protocol bigint,

packets bigint,

bytes bigint,

start bigint,

end bigint,

action string,

log_status string

)

PARTITIONED BY (dt string)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '

LOCATION 's3://my-flow-logs-bucket/AWSLogs/123456789012/vpcflowlogs/';

-- 시간대별 거부 트래픽 추이

SELECT

from_unixtime(start) as event_time,

srcaddr,

dstaddr,

dstport,

protocol,

sum(packets) as total_packets,

sum(bytes) as total_bytes

FROM vpc_flow_logs

WHERE action = 'REJECT'

AND dt = '2026/03/08'

GROUP BY 1, 2, 3, 4, 5

ORDER BY total_packets DESC

LIMIT 50;

6. NAT Gateway와 Internet Gateway 이슈

6.1 Internet Gateway(IGW) 트러블슈팅

IGW를 통한 인터넷 접근 체크리스트:

□ VPC에 IGW가 연결(Attached)되어 있는가?

□ 퍼블릭 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW 경로가 있는가?

□ 인스턴스에 퍼블릭 IP 또는 Elastic IP가 할당되어 있는가?

□ Security Group 아웃바운드에 해당 트래픽이 허용되어 있는가?

□ NACL에서 인바운드/아웃바운드 모두 허용되어 있는가?

IGW 연결 상태 확인

aws ec2 describe-internet-gateways \

--filters "Name=attachment.vpc-id,Values=vpc-0abc1234" \

--query 'InternetGateways[*].{IGWId:InternetGatewayId,State:Attachments[0].State}'

퍼블릭 서브넷 라우팅 확인

aws ec2 describe-route-tables \

--filters "Name=association.subnet-id,Values=subnet-pub123" \

--query 'RouteTables[*].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

6.2 NAT Gateway 문제 해결

NAT Gateway 상태 확인

aws ec2 describe-nat-gateways \

--filter "Name=vpc-id,Values=vpc-0abc1234" \

--query 'NatGateways[*].{

NatGatewayId:NatGatewayId,

State:State,

SubnetId:SubnetId,

PublicIp:NatGatewayAddresses[0].PublicIp,

PrivateIp:NatGatewayAddresses[0].PrivateIp

**NAT Gateway 일반적인 문제:**

문제 1: NAT Gateway를 통한 인터넷 접속 불가

원인: NAT Gateway가 프라이빗 서브넷에 배치됨

해결: NAT Gateway는 반드시 퍼블릭 서브넷에 위치해야 함

문제 2: 간헐적 연결 끊김

원인: NAT Gateway의 연결 추적 한도(Conntrack limit) 초과

확인: CloudWatch 메트릭 > ErrorPortAllocation

해결: 여러 NAT Gateway로 분산하거나 대상 서비스의 엔드포인트를 사용

문제 3: NAT Gateway 비용 폭증

원인: S3, DynamoDB 등 AWS 서비스 트래픽이 NAT를 경유

해결: VPC Endpoint(Gateway 타입)를 생성하여 프라이빗 경로 사용

VPC Endpoint 생성 (S3 예시 — NAT 비용 절감)

aws ec2 create-vpc-endpoint \

--vpc-id vpc-0abc1234 \

--service-name com.amazonaws.ap-northeast-2.s3 \

--route-table-ids rtb-priv111 rtb-priv222

NAT Gateway CloudWatch 메트릭 확인

aws cloudwatch get-metric-statistics \

--namespace AWS/NATGateway \

--metric-name ErrorPortAllocation \

--dimensions Name=NatGatewayId,Value=nat-0abc1234 \

--start-time 2026-03-07T00:00:00Z \

--end-time 2026-03-08T00:00:00Z \

--period 3600 \

--statistics Sum

7. 크로스 리전과 하이브리드 클라우드 연결

7.1 크로스 리전 VPC 연결

크로스 리전 연결 옵션:

1. Inter-Region VPC Peering — 1:1 연결, 간단한 구성

2. Transit Gateway Inter-Region Peering — 허브-스포크, 대규모 구성

3. AWS Cloud WAN — 글로벌 네트워크 관리 (최신)

Inter-Region TGW Peering 상태 확인

aws ec2 describe-transit-gateway-peering-attachments \

--filters "Name=state,Values=available,pendingAcceptance" \

--query 'TransitGatewayPeeringAttachments[*].{

AttachmentId:TransitGatewayAttachmentId,

RequesterTgw:RequesterTgwInfo.TransitGatewayId,

AccepterTgw:AccepterTgwInfo.TransitGatewayId,

State:State

7.2 하이브리드 클라우드 연결 (VPN & Direct Connect)

Site-to-Site VPN 터널 상태 확인

aws ec2 describe-vpn-connections \

--vpn-connection-ids vpn-0abc1234 \

--query 'VpnConnections[*].{

VpnId:VpnConnectionId,

State:State,

Tunnel1Status:VgwTelemetry[0].Status,

Tunnel1StatusMessage:VgwTelemetry[0].StatusMessage,

Tunnel2Status:VgwTelemetry[1].Status,

Tunnel2StatusMessage:VgwTelemetry[1].StatusMessage

**VPN 터널 다운 진단:**

VPN 터널이 DOWN인 경우 체크리스트:

□ 고객 게이트웨이(CGW) 설정 확인

- IKE 버전 (v1 또는 v2)

- Pre-shared key 일치 여부

- Phase 1/Phase 2 암호화 파라미터 일치

□ 온프레미스 방화벽에서 UDP 500, UDP 4500 허용 여부

□ NAT-Traversal 설정 확인

□ BGP 세션 상태 확인 (동적 라우팅 사용 시)

□ Dead Peer Detection(DPD) 설정 일치 여부

7.3 멀티 클라우드 네트워크 연결

AWS ↔ GCP 연결 옵션:

1. IPSec VPN (AWS VPN + GCP Cloud VPN)

2. Partner Interconnect 사용

3. 서드파티 SD-WAN 솔루션

AWS ↔ Azure 연결 옵션:

1. IPSec VPN (AWS VPN + Azure VPN Gateway)

2. ExpressRoute + Direct Connect (전용선)

3. Megaport 등 Cloud Exchange 활용

GCP VPN 터널 상태 확인

gcloud compute vpn-tunnels describe my-tunnel \

--region=us-central1 \

--format="value(status,detailedStatus)"

Azure VPN 연결 상태 확인

az network vpn-connection show \

--name my-vpn-connection \

--resource-group my-rg \

--query '{Status:connectionStatus,EgressBytes:egressBytesTransferred,IngressBytes:ingressBytesTransferred}'

8. 클라우드 DNS 트러블슈팅 (Route 53, Cloud DNS)

8.1 AWS Route 53 문제 해결

Route 53 호스팅 존 레코드 확인

aws route53 list-resource-record-sets \

--hosted-zone-id Z0123456789ABCDEFGHIJ \

--query 'ResourceRecordSets[?Name==`api.example.com.`]'

Route 53 Resolver 쿼리 로그 확인 (VPC 내부 DNS)

aws route53resolver list-resolver-query-log-configs

DNS 해석 테스트

aws route53 test-dns-answer \

--hosted-zone-id Z0123456789ABCDEFGHIJ \

--record-name api.example.com \

--record-type A

**프라이빗 호스팅 존 문제:**

문제: VPC 내에서 프라이빗 DNS 레코드가 해석되지 않음

체크리스트:

□ 프라이빗 호스팅 존이 해당 VPC에 연결되어 있는가?

□ VPC의 enableDnsSupport가 true인가?

□ VPC의 enableDnsHostnames가 true인가?

□ DHCP Options Set에서 AmazonProvidedDNS를 사용하고 있는가?

VPC DNS 설정 확인

aws ec2 describe-vpc-attribute \

--vpc-id vpc-0abc1234 \

--attribute enableDnsSupport

aws ec2 describe-vpc-attribute \

--vpc-id vpc-0abc1234 \

--attribute enableDnsHostnames

8.2 GCP Cloud DNS 디버깅

Cloud DNS 레코드 확인

gcloud dns record-sets list \

--zone=my-dns-zone \

--filter="name=api.example.com."

프라이빗 DNS 존 연결 VPC 확인

gcloud dns managed-zones describe my-private-zone \

--format="value(privateVisibilityConfig.networks)"

DNS 정책 확인

gcloud dns policies list

8.3 하이브리드 DNS 구성 문제

VPC Peering 환경의 DNS 해석 문제:

- Route 53 Resolver 인바운드/아웃바운드 엔드포인트 설정 필요

- 온프레미스 → AWS: Inbound Endpoint 사용

- AWS → 온프레미스: Outbound Endpoint + Forwarding Rule 설정

┌─────────────────────────────┐

│ Route 53 Resolver │

온프레미스 ──→ │ Inbound Outbound │ ──→ 온프레미스 DNS

DNS 쿼리 │ Endpoint Endpoint │ 포워딩

└─────────────────────────────┘

Route 53 Resolver 엔드포인트 상태 확인

aws route53resolver list-resolver-endpoints \

--query 'ResolverEndpoints[*].{

Id:Id,

Name:Name,

Direction:Direction,

Status:Status,

IpAddressCount:IpAddressCount

포워딩 규칙 확인

aws route53resolver list-resolver-rules \

--query 'ResolverRules[*].{

Id:Id,

DomainName:DomainName,

RuleType:RuleType,

Status:Status,

TargetIps:TargetIps

9. 실전 클라우드 네트워크 디버깅 시나리오

시나리오 1: ECS 서비스에서 외부 API 호출 타임아웃

증상: ECS Fargate 태스크에서 외부 API 호출 시 연결 타임아웃 발생

환경: 프라이빗 서브넷에 배치된 Fargate 태스크

디버깅 순서:

1. 태스크의 네트워크 모드 확인 (awsvpc)

2. 태스크의 ENI에 연결된 Security Group 아웃바운드 규칙 확인

3. 서브넷 라우팅 테이블에 NAT Gateway 경로 확인

4. NAT Gateway 상태 및 위치(퍼블릭 서브넷) 확인

5. NACL 규칙 확인 (아웃바운드 + 임시 포트 인바운드)

근본 원인: NAT Gateway가 삭제되었으나 라우팅 테이블에 블랙홀 경로가 남아있었음

해결: 새 NAT Gateway 생성 후 라우팅 테이블 업데이트

시나리오 2: VPC Peering 환경에서 RDS 접근 불가

증상: VPC-A의 애플리케이션에서 VPC-B의 RDS에 TCP 3306 연결 불가

환경: VPC-A(10.0.0.0/16) ↔ Peering ↔ VPC-B(10.1.0.0/16)

디버깅 순서:

1. Peering 상태 확인 → Active ✓

2. VPC-A 라우팅 테이블 → 10.1.0.0/16 → pcx-xxx ✓

3. VPC-B 라우팅 테이블 → 10.0.0.0/16 → pcx-xxx ✓

4. RDS Security Group 인바운드 확인 → 10.0.0.0/16에서 3306 허용 ✗ ← 문제 발견!

5. RDS가 VPC-B의 SG 참조만 허용하고 있었음

해결: RDS Security Group에 VPC-A CIDR(10.0.0.0/16)에서 3306 인바운드 허용 추가

시나리오 3: Lambda 함수의 VPC 내 리소스 접근 실패

증상: VPC에 연결된 Lambda 함수에서 ElastiCache 접근 불가, 인터넷도 불가

환경: Lambda가 프라이빗 서브넷에 연결

디버깅 순서:

1. Lambda 실행 역할에 VPC 관련 권한 확인

- ec2:CreateNetworkInterface

- ec2:DescribeNetworkInterfaces

- ec2:DeleteNetworkInterface

2. Lambda에 할당된 서브넷 확인 (최소 2개 AZ 권장)

3. Lambda Security Group → ElastiCache Security Group 허용 확인

4. 인터넷 접근: 프라이빗 서브넷 + NAT Gateway 필요

근본 원인: Lambda의 Security Group 아웃바운드가 제한적이어서

ElastiCache 포트(6379)가 허용되지 않았음

해결: Lambda SG 아웃바운드에 TCP 6379 허용 추가

시나리오 4: 크로스 리전 데이터 전송 지연

증상: us-east-1과 ap-northeast-2 간 데이터 복제 지연 급증

환경: Inter-Region VPC Peering 사용

디버깅 순서:

1. VPC Peering 상태 확인 → Active ✓

2. 네트워크 대역폭 확인 → CloudWatch BytesIn/BytesOut 메트릭

3. 인스턴스 타입별 네트워크 성능 한도 확인

4. TCP Window Scaling 및 버퍼 크기 최적화

5. AWS Global Accelerator 또는 CloudFront 활용 검토

최적화:

- 대용량 전송 시 병렬 스트림 사용

- TCP 윈도우 크기 튜닝: sysctl -w net.core.rmem_max=16777216

- S3 Transfer Acceleration 활용 (파일 전송의 경우)

10. 트러블슈팅 도구 모음과 자동화

10.1 종합 진단 스크립트

#!/bin/bash

cloud-network-diag.sh — 클라우드 네트워크 종합 진단 스크립트

TARGET_IP=$1

TARGET_PORT=${2:-443}

VPC_ID=${3:-"auto"}

echo "=== 클라우드 네트워크 진단 시작 ==="

echo "대상: ${TARGET_IP}:${TARGET_PORT}"

echo ""

1. 기본 연결성 확인

echo "--- 1. 기본 연결성 확인 ---"

ping -c 3 -W 2 $TARGET_IP 2>/dev/null

nc -zv -w 3 $TARGET_IP $TARGET_PORT 2>&1

2. DNS 해석 확인

echo "--- 2. DNS 해석 확인 ---"

dig +short $TARGET_IP 2>/dev/null || echo "IP 주소로 DNS 조회 생략"

3. 경로 추적

echo "--- 3. 경로 추적 ---"

traceroute -m 15 -w 2 $TARGET_IP 2>/dev/null

4. AWS 보안 그룹 확인 (인스턴스에서 실행 시)

echo "--- 4. 메타데이터 기반 보안 그룹 확인 ---"

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \

-H "X-aws-ec2-metadata-token-ttl-seconds: 60" 2>/dev/null)

if [ ! -z "$TOKEN" ]; then

SG_IDS=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \

http://169.254.169.254/latest/meta-data/security-groups 2>/dev/null)

echo "연결된 Security Groups: $SG_IDS"

echo "=== 진단 완료 ==="

10.2 CloudWatch 경보 설정 (네트워크 모니터링)

NAT Gateway ErrorPortAllocation 경보

aws cloudwatch put-metric-alarm \

--alarm-name "NATGateway-PortAllocation-Error" \

--metric-name ErrorPortAllocation \

--namespace AWS/NATGateway \

--dimensions Name=NatGatewayId,Value=nat-0abc1234 \

--statistic Sum \

--period 300 \

--threshold 100 \

--comparison-operator GreaterThanThreshold \

--evaluation-periods 2 \

--alarm-actions arn:aws:sns:ap-northeast-2:123456789012:network-alerts

VPN 터널 다운 경보

aws cloudwatch put-metric-alarm \

--alarm-name "VPN-Tunnel-Down" \

--metric-name TunnelState \

--namespace AWS/VPN \

--dimensions Name=VpnId,Value=vpn-0abc1234 \

--statistic Maximum \

--period 300 \

--threshold 0.5 \

--comparison-operator LessThanThreshold \

--evaluation-periods 2 \

--alarm-actions arn:aws:sns:ap-northeast-2:123456789012:network-alerts

마무리

클라우드 네트워크 트러블슈팅은 체계적인 접근법이 핵심입니다. 주요 포인트를 정리하면:

1. **계층적 접근**: OSI 모델을 기반으로 상위 계층에서 하위 계층으로 진단

2. **로그 활용**: VPC Flow Logs, DNS Query Logs를 항상 활성화

3. **도구 활용**: 각 클라우드의 Reachability Analyzer, Connectivity Test 적극 활용

4. **보안 규칙 이해**: Stateful(SG) vs Stateless(NACL) 차이를 명확히 이해

5. **비용 최적화**: VPC Endpoint를 활용하여 NAT Gateway 비용 절감

6. **모니터링**: CloudWatch 경보를 통한 사전 감지 체계 구축

네트워크 문제는 재현이 어려운 경우가 많으므로, 평소에 모니터링과 로깅을 충실히 설정해 두는 것이 가장 중요합니다.