AI 요약관련 정보

• 이전 네트워크 구조의 문제점: 각 VPC에 분산된 NAT Gateway와 여러 개의 Transit Gateway로 인해 비효율적인 퍼블릭 접근 관리, 불필요한 리소스 중복, NACL 쿼터 제한으로 인한 관리 복잡성 증가 문제가 있었습니다. 🤯
• 네트워크 구조 개선 방안: 모든 아웃바운드 트래픽이 모이는 '네트워크 VPC'를 신설하여 Transit Gateway를 하나로 통합하고, NAT Gateway를 중앙화하여 관리 포인트를 줄이고 리소스 효율성을 높였습니다. 🌐
• AWS Network Firewall 도입: NACL 쿼터 문제를 해결하고 세밀한 규칙 작성을 위해 AWS Network Firewall(NFW)을 채택했습니다. 중앙화된 규칙 관리와 트래픽 검열을 위해 'Centralized' 배포 방식을 선택했습니다. 🔥
• Transit Gateway 마이그레이션 전략: 파트너사와의 복잡한 회선(Direct Connect, Site-to-Site VPN)을 유지하는 것이 가장 효율적이라고 판단, 기존 '파트너 Transit Gateway'를 중심으로 모든 연결을 통합했습니다. 🛣️
• NAT Gateway 마이그레이션 및 IP 보존: 다운타임을 최소화하고 파트너사 방화벽 업데이트 부담을 줄이기 위해 기존 퍼블릭 IP(EIP)를 보존하면서 새로운 네트워크 VPC로 NAT Gateway를 단계적으로 이전했습니다. 🚀
• 개선 결과 - 관리 효율성 증대: 분산되어 있던 DNS Firewall 및 NACL 관리 포인트를 Network Firewall 하나로 통합하여 관리 효율성을 극대화했습니다. 🎯
• 개선 결과 - 룰 쿼터 확장 및 책임 분리: Network Firewall의 Suricata 룰 도입으로 룰 쿼터가 40개에서 3만 개로 대폭 확장되었으며, 보안 팀이 방화벽 룰을 관리하여 보안 정책과 네트워크 설정을 분리했습니다. 🤝
• 아쉬웠던 점 - RAM 의존성 및 권한 문제: AWS Resource Access Manager(RAM)를 통한 계정 간 리소스 공유 시 방화벽 대시보드 및 트래픽 경로 파악에 필요한 권한이 부족하여 관리의 어려움이 있었습니다. 😔
• 아쉬웠던 점 - Site-to-Site VPN 종속성: Site-to-Site VPN이 Transit Gateway와 동일 계정에서만 생성 가능하다는 점을 뒤늦게 파악하여 아키텍처 선택의 폭이 제한되었습니다. 🔗
• 향후 과제 - 비용 최적화: Transit Gateway를 통한 데이터 전송 비용 발생 문제를 인지하고 있으며, 향후 VPC 간 통신은 무료인 VPC 피어링으로 전환하여 비용을 절감할 계획입니다. 💸
• 최종 아키텍처 완성: 분산된 NAT Gateway와 Transit Gateway를 제거하고 Network Firewall을 추가하여 리소스와 트래픽을 중앙화한 통합 네트워크 아키텍처를 성공적으로 구축했습니다. 🏆