전역 리전 모니터링의 한계와 도전 이전 글(실전 편)에서 테라폼을 이용해 2-AZ 기반의 탄탄한 네트워크 기반을 마련했습니다. 이번에는 이렇게 구축된 인프라 위에서 발생하는 중요한 이벤트들을 전역 리전 단위로 어떻게 효율적으로 관리할 수 있는지 다뤄보겠습니다. AWS에서 다중 리전을 운영하다 보면, 각 리전에서 발생하는 중요한 이벤트(GuardDuty 위협 감지, AWS Health의 점검 공지, 루팅 로그인 등)를 개별적으로 관리하는 것이 매우 번거롭다는 것을 알게 됩니다. 리전마다 람다(Lambda)를 띄우고 알림 채널(SNS/Slack)을 연동하는 것은 이른바 “노가다"에 가깝습니다. 이를 해결하기 위해 EventBridge의 리전 간 포워딩 기능을 활용한 효율적인 아키텍처를 소개합니다. ...
이론을 넘어 실전으로 VPC 세팅과 Peering vs TGW 글 내용을 기반으로, 2AZ VPC 를 terraform 으로 구성해 보겠습니다. 1. 변수 정의와 리전 설정 먼저 확장성을 위해 AZ 목록을 변수화하고 리전을 정의합니다. variable "region" { default = "ap-northeast-2" } variable "azs" { description = "사용할 가용 영역 리스트" type = list(string) default = ["ap-northeast-2a", "ap-northeast-2c"] # 2-AZ 전략 } variable "vpc_cidr" { default = "10.0.0.0/16" } 2. VPC와 서브넷: cidrsubnet과 count의 활용 서브넷을 하드코딩하는 것은 가장 피해야 할 습관입니다. 테라폼의 내장 함수를 사용하여 자동으로 계산되게 구성합니다. ...
네트워크 레이어 설계의 핵심 클라우드 인프라의 뼈대인 VPC를 설계할 때, “가용영역(AZ)은 무조건 최대로 쓸수록 좋다"는 생각에 빠지기 쉽습니다. 하지만 실전 아키텍처에서는 비용, 성능, 관리 복잡성 사이의 균형점이 필요하다고 생각합니다. AZ(Availability Zone) 전략: 3AZ? 2AZ? 대부분의 가이드에서는 고가용성(HA)을 위해 3개 이상의 AZ를 쓰라고 권장합니다. 하지만 실제 운영 환경, 특히 **EKS(Kubernetes)**를 운영할 때는 2개의 AZ가 더 효율적인 경우도 얼마든지 있습니다. 1. Topology Aware Routing(TAR)의 수학적 한계와 Fallback Kubernetes의 Topology Aware Routing은 트래픽을 같은 AZ 내로 유지해 비용절감에 효율적입니다. 하지만 여기에는 ‘버그’처럼 보이는 기술적 **안전장치(Safeguard)**가 있습니다. ...
“딸깍의 함정” 테라폼을 처음 접하면 모든 리소스(VPC, DB, EC2 등)를 하나의 .tf 파일 혹은 하나의 프로젝트 폴더에 몰아넣고 terraform apply를 날리고 싶다는 유혹에 빠지기 쉽다고 생각합니다. 하지만 프로덕션 환경에서 이런 방식은 매우 위험합니다. 인프라의 규모가 커질수록 **폭발 반경(Blast Radius)**을 최소화하고 관리 효율을 높이기 위한 Layered Architecture 도입이 필수적입니다. 레이어(Layer) 도입의 계기와 의의 모든 인프라를 한 곳에서 관리하면 특정 리소스(예: 보안 그룹 규칙)를 수정하다가 실수로 VPC 전체를 재생성하거나, 상태(State) 파일이 꼬여 전체 인프라가 마비되는 리스크가 존재합니다. ...