본문으로 건너뛰기
PDF ↓
← 대표 사례로

PF-09 · AWS · Python

AWS 방화벽 요청 자동화

방화벽 요청이 이미 열려 있는지 먼저 확인하고, 막힌 것만 미리보기 뒤 적용하며, 실제 트래픽으로 검증하는 CLI입니다.

3
단계: confirm, modify, flowlog
4
입력 형식
4
식별하는 리소스 종류
역할
설계 · 구현
기간
개인 프로젝트 · 2026.11 공개
규모
3단계 CLI · 입력 형식 4종 · 리소스 4종
클라우드
AWS
기술
Python · boto3 · AWS · CloudWatch Logs · Athena · Excel
방화벽 요청출발지 · 목적지 · 포트netops confirmnetops modifynetops flowlog이미 열려 있는가막힌 흐름만 미리보기실제 트래픽으로 검증열림작업 불필요막힘다음 단계로미리보기영향받는 리소스와 규칙 출력--apply + apply 입력규칙 추가만트래픽 확인CloudWatch Logs · Athena변경은 기본으로 일어나지 않습니다
flowlog로 CloudWatch Logs나 Athena에서 실제 트래픽을 찾아 확인합니다.
문제

방화벽 요청은 이미 열린 통신을 다시 여는 경우가 많아 중복 규칙이 쌓였고, 어떤 리소스와 규칙이 걸리는지 계정마다 콘솔에서 찾아야 했습니다.

접근

netops confirm이 주소를 AWS 리소스로 식별하고 보안그룹 규칙과 라우트를 평가합니다. 막힌 통신만 modify로 넘겨 계획을 먼저 출력합니다. flowlog는 CloudWatch Logs나 Athena에서 실제 트래픽을 찾습니다.

결과

기본 실행은 아무것도 바꾸지 않습니다. 규칙 추가에는 --apply와 apply 입력이 필요하고, 규칙은 추가만 가능하며, 슬롯이 없는 보안그룹은 고르지 않습니다.

배운 점

변경 도구에서는 안전한 동작이 플래그 없이 되는 기본값이어야 한다는 점을 배웠습니다. --dry-run 방식은 누군가 한 번 깜빡하면 바로 실제 변경이 일어나지만, 기본 실행이 아무것도 바꾸지 않고 --apply와 apply 입력이 둘 다 있어야 적용되면 실수가 변경으로 이어지지 않습니다. 변경 범위를 규칙 추가로만 좁힌 것도 같은 이유입니다. 할 수 있는 일을 줄이면 잘못됐을 때의 피해도 줄어듭니다. 또 요청을 받자마자 규칙을 여는 대신 이미 열려 있는지부터 확인하고, 막혔다면 규칙 때문인지 경로 때문인지 이유를 나눠 남기니, 중복 규칙이 쌓이지 않고 실제로 필요한 조치만 남았습니다.

관련 현장 노트

Control Plane에서 전체 기록 보기 ↗

© 2026 김준현 · 이 사이트의 인프라도 코드로 관리합니다

테마 고르기

사원증을 누르면 그 테마로, 보던 내용과 같은 곳으로 이동합니다. 끌면 흔들리기만 합니다.

처음 화면으로 →