AWS LandingZone

참고 사이트: https://www.lgcns.com/blog/cns-tech/aws-ambassador/40970/

 

Landing Zone(랜딩 존) 

랜딩 존은 확장성과 안전성을 갖춘 잘 설계된 다계정 AWS 환경이다.

 

매번 집을 지을 때마다 수도관, 가스관 작업을 일일이 하면서 복잡해졌다.
기존 구성의 보수작업 및 신규 작업이 더 어려워지고 시간, 비용, 효율성, 관리 면에서 문제가 발생한다.

바로 여기서 랜딩존의 장점이 나타난다.
처음 기반 작업을 할때 아예 언제든 확장이 가능한 구조로 수도관, 가스관, 전기선을 포설한다.
즉, 이후 들어오는 집은 그저 연결만 하면 된다.

 

랜딩 존도 계정 및 네트워크, 보안 요소가 이미 완성되어 있기 때문에,

랜딩 존 위에 또다른 새로운 시스템을 구축하고자할 때, 시스템 구축 속도 향상 및 구축 비용 감소가 된다.

 

랜딩 존 구성요소

집 짓기에 공통적으로 필요한 수도관, 가스관 작업이 있듯이,
랜딩 존에는 인프라 구성에 공통적으로 필요한

• 계정
• 보안(UTM, 서버접근제어, WAF, Log Archive..)
• 규칙(보안그룹 0.0.0.0/0 불가, 비밀번호 정책..)  

들이 존재한다.

 

 

랜딩 존의 장점

• 최초 구성 시 시간이 걸릴 수 있으나, 향후 빠른 구축 및 유연한 확장
• 장기적 관점에서 아키텍처 확장 시 구축 비용의 절감 가능
• 보안/운영의 관점에서 균일한 정책 반영을 통해 구현 용이 및 향후 보안 감사에도 손쉬운 대응 가능

 

단점

• 최초 구성 시 도입 비용 증가
• 최초 아키텍트에 대한 복잡성 증가

 

랜딩 존이 도입되기 전의 상황

랜딩 존이 도입되기 전, 대부분 아키텍트는 아래와 같았다.

 

보안 감사 요구 조건

1. 운영 및 개발의 네트워크를 분리할 것
2. 사용자에게 최소한의 권한만을 부여할 것
3. 모니터링 및 각종 운영용 SW 설치 시 management 및 콘솔의 위치, 로그의 누적 위치 등의 애매함의 존재

비용적 효용성을 위한 요구 조건

1. UTM / WAF 등 매우 고가의 3rd party SW 도입 개수 증가 
2. 리소스가 단일 계정에 혼재되어 비용 관리 시 정리가 어려움 

운영적 측면 요구 조건

1. 서로 다른 naming, 서로 다른 Tag 
2. 다수 서버를 운영하는 입장에서 서로 다른 형태의 시스템은 장애 대응의 리스크 상승 
3. 신규 환경 구축 시 기존 VPC에 남아 있는 IP가 많은 상태에서도 분류를 위해 신규 VPC 생성 필요 

 

 

랜딩 존이 도입된 이후 다음과 같이 아키텍트가 진화하였다.

• Account를 분리함으로서 본질적인 분리 수행
• 운영 / 개발과 같은 특수 계정을 제외하고 모두 단일 VPC 구현 및 네트워크 ip 낭비 최소화
• 인터넷 관문 통일을 통해 보안정책 단일화 및 3rd party sw 구매 대수 감소 (비용 효율화)
• 로그 저장의 단일화를 통해 로그 파일 조작과 같은 보안 사고 방지 및 관리 용이화
• 관리를 위한 콘솔 및 계정 관리의 단일화를 통한 환경 분리, 관리 용이화

 

위의 그림에서 온프렘과 랜딩 존과 연결하고,

MyService는 랜딩 존이랑만 연결되어있어도 아웃바운드 통신이 가능한데,

굳이 온프렘에서 dx를 랜딩 존과 MyService 각각 연결하는 이유가 궁금했다.

 

dx를 랜딩존, MyService  두 곳 모두 연결하는 이유는 

MyService에서 특정 서비스 포트를 열 때,
1) dx 방화벽     2) 랜딩존 
두 곳에 각각 서비스 포트를 열어야 하는 공수가 필요하다.
이러한 공수를 줄이기 위해 DX를 MyService와 바로 연결한다.

DX를 MyService에 바로 연결하면 공수가 비교적 줄어든다.