AWS 방화벽 요청 자동화 GitHub ↗
- Python
- boto3
- AWS
- CloudWatch Logs
- Athena
- Excel
- 3
- 단계: confirm, modify, flowlog
- 4
- 입력 형식
- 4
- 식별하는 리소스 종류
방화벽 요청이 이미 열려 있는지 먼저 확인하고, 막힌 것만 미리보기 뒤 적용하며, 실제 트래픽으로 검증하는 CLI입니다.
규모: 3단계 CLI · 입력 형식 4종 · 리소스 4종
개요
-
문제
방화벽 요청은 이미 열린 통신을 다시 여는 경우가 많아 중복 규칙이 쌓였고, 어떤 리소스와 규칙이 걸리는지 계정마다 콘솔에서 찾아야 했습니다.
-
접근
netops confirm이 주소를 AWS 리소스로 식별하고 보안그룹 규칙과 라우트를 평가합니다. 막힌 통신만 modify로 넘겨 계획을 먼저 출력합니다. flowlog는 CloudWatch Logs나 Athena에서 실제 트래픽을 찾습니다.
-
결과
기본 실행은 아무것도 바꾸지 않습니다. 규칙 추가에는 --apply와 apply 입력이 필요하고, 규칙은 추가만 가능하며, 슬롯이 없는 보안그룹은 고르지 않습니다.
-
배운 점
변경 도구에서는 안전한 동작이 플래그 없이 되는 기본값이어야 한다는 점을 배웠습니다. --dry-run 방식은 누군가 한 번 깜빡하면 바로 실제 변경이 일어나지만, 기본 실행이 아무것도 바꾸지 않고 --apply와 apply 입력이 둘 다 있어야 적용되면 실수가 변경으로 이어지지 않습니다. 변경 범위를 규칙 추가로만 좁힌 것도 같은 이유입니다. 할 수 있는 일을 줄이면 잘못됐을 때의 피해도 줄어듭니다. 또 요청을 받자마자 규칙을 여는 대신 이미 열려 있는지부터 확인하고, 막혔다면 규칙 때문인지 경로 때문인지 이유를 나눠 남기니, 중복 규칙이 쌓이지 않고 실제로 필요한 조치만 남았습니다.