전역 리전 모니터링의 한계와 도전

이전 글(실전 편)에서 테라폼을 이용해 2-AZ 기반의 탄탄한 네트워크 기반을 마련했습니다. 이번에는 이렇게 구축된 인프라 위에서 발생하는 중요한 이벤트들을 전역 리전 단위로 어떻게 효율적으로 관리할 수 있는지 다뤄보겠습니다.

AWS에서 다중 리전을 운영하다 보면, 각 리전에서 발생하는 중요한 이벤트(GuardDuty 위협 감지, AWS Health의 점검 공지, 루팅 로그인 등)를 개별적으로 관리하는 것이 매우 번거롭다는 것을 알게 됩니다.

리전마다 람다(Lambda)를 띄우고 알림 채널(SNS/Slack)을 연동하는 것은 이른바 “노가다"에 가깝습니다. 이를 해결하기 위해 EventBridge의 리전 간 포워딩 기능을 활용한 효율적인 아키텍처를 소개합니다.

아키텍처 설계: Centralized Global Event Bus

핵심 아이디어는 간단합니다. 모든 리전의 이벤트를 하나의 메인 리전(Global 리전)으로 모아서 처리하는 것입니다.

1. 전역 리전 (Regional Event Bus)

  • GuardDuty, AWS Health, IAM Login 등 리저널 이벤트를 감지합니다.
  • EventBridge Rule을 통해 감지된 이벤트를 메인 리전의 Event Bus로 포워딩합니다.

2. 메인 리전 (Main Event Bus)

  • 다른 모든 리전에서 포워딩된 이벤트를 수신합니다.
  • 여기서만 단 한 번, 알림용 Lambda나 SNS를 연결하여 통합 모니터링을 수행합니다.

이 구성을 통해 리전이 늘어나도 알림 로직은 단 한 곳에서만 관리하면 되는 압도적인 효율성을 얻을 수 있습니다.

Terraform 전략: Aliased Provider와 반복문

이러한 전역 리전 배포를 테라폼에서 처리할 때, 일일이 리소스를 복사해 붙여넣는 것은 최악의 안티패턴입니다.

1. Provider Aliasing

복수의 리전을 하나의 테라폼 코드에서 제어하기 위해 alias를 활용합니다.

# 서울 리전
provider "aws" {
  region = "ap-northeast-2"
}

# 버지니아 북부 리전 (Global 알림 수신용)
provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}

2. Multi-Region Resource Deployment

for_each와 모듈화를 결합하면, 지원하는 모든 리전에 원클릭으로 알림 룰을 배포할 수 있습니다.

locals {
  target_regions = ["ap-northeast-2", "ap-northeast-1", "us-west-2"]
}

module "regional_forwarder" {
  for_each = toset(local.target_regions)
  source   = "./modules/event-forwarder"
  
  target_event_bus_arn = aws_cloudwatch_event_bus.main.arn
  # ... Provider는 레이어 설계에 따라 명시적으로 넘길 수 있습니다.
}

전문적인 운영 포인트: 주요 감지 대상

  • AWS Health (Scheduled Actions): AWS 인프라 점검 일정을 미리 받아 대비합니다.
  • GuardDuty: 허용되지 않은 IP에서의 접속이나 비정상적인 리소스 사용을 실시간으로 감지합니다.
  • IAM (Console Login): 관리자 계정 로그인을 즉시 알림으로 받아 무단 접속을 차단합니다.

마치며: 아키텍처가 곧 코드다

지금까지 3편에 걸쳐 인프라 계층화(Layering), 전략적 네트워크 설계, 그리고 전역 통합 모니터링까지 다뤄보았습니다.

인프라를 코드로 관리한다는 것은 단순한 자동화를 넘어, 우리의 철학이 담긴 아키텍처를 문법적 오류 없이 안전하게 세상에 배포하는 과정입니다. 이 연재가 여러분의 클라우드 여정에 단단한 밑거름이 되길 바랍니다.