클라우드 성장에는 명확한 경계가 필요합니다.

계정, 환경, 관리 권한은 실제 조직 구조와 맞아야 합니다. 현업 부서를 기준으로 한 구분이 애플리케이션이나 운영 책임을 기준으로 한 구분과 항상 같지는 않습니다. 그렇기 때문에 저희는 누가 리소스를 요청하고, 누가 이를 관리하며, 비용을 누구에게 배정해야 하는지를 함께 검토합니다. 기존 환경도 함께 고려합니다. 그런 다음 목표 상태에 의도한 경계와 그 이유를 기술하여, 향후 변경이 우연히 생긴 이름이나 과거의 책임 소재만을 근거로 이루어지지 않도록 합니다.

개발, 테스트, 프로덕션 환경은 각각 필요한 만큼 분리됩니다. 이 밖에도 공통 서비스를 어떻게 사용하고 어떤 예외를 허용할 수 있는지를 정합니다. 구현의 목적은 모든 특수한 사례를 막는 것이 아니라 이를 투명하게 다룰 수 있게 하는 것입니다. 정해진 예외 절차는 결정과 책임 소재를 명시합니다. 이를 통해 개별 애플리케이션에 특수한 요구 사항이 있거나 기존 워크로드를 처음에는 단계적으로만 공통 구조에 편입할 수 있는 경우에도 아키텍처는 계속 설명 가능한 상태로 유지됩니다.

문서화된 정책만으로는 어떤 리소스도 바뀌지 않습니다. 그렇기 때문에 합의된 규정 가운데 어떤 것을 기술적으로 구현할 수 있고 어떤 것이 여전히 조직적 결정을 필요로 하는지를 검토합니다. 여기에는 역할, 네트워크 접근 권한, 로깅, 비용 태깅이 포함됩니다. 구성은 어떤 규칙이 필수적으로 적용되고 어디에서 승인이 필요한지를 드러내야 합니다. 동시에 변경을 위한 절차도 함께 기술하여, 이후의 조정이 공통 기반을 벗어나 이루어지지 않도록 합니다.

버전 관리되는 구성을 사용하면 변경 사항을 검토하고 의도한 상태를 추적 가능하게 기록할 수 있습니다. 합의된 범위 내에서 이를 바탕으로 반복 가능한 프로비저닝 경로를 구축합니다. 이 경로는 필요한 점검과 접근 권한을 포함하여 구체적인 환경에서 시험합니다. 귀사의 팀은 구성과 그 사용 절차를 함께 전달받습니다. 이를 통해 한 번 구축된 플랫폼은 이후 프로젝트도 참고할 수 있는 기반이 되며, 그 유지 관리가 최초 프로젝트 참여자에게만 남아 있지 않게 됩니다.

Landing Zone이 실용적인지는 실제 애플리케이션을 통해 드러납니다. 귀사의 팀은 예정된 리소스를 받고, 필요한 시스템에 접근하며, 배정된 권한으로 작업을 수행할 수 있어야 합니다. 이 첫 실행을 통해 부족한 정보와 불필요한 장애 요소가 드러납니다. 저희는 이때 반드시 필요한 규정과 단순화해야 할 절차를 구분합니다. 이러한 관찰 내용은 다른 팀이 합류하기 전에 구성과 문서에 반영됩니다.

인계에는 플랫폼 유지보수에 대한 책임, 새로운 프로젝트의 편입, 변경 사항의 승인이 포함됩니다. 미해결 사항도 그 결과와 함께 문서화됩니다. Landing Zone은 이후 그 위에서 운영되는 모든 애플리케이션에 대한 최종적인 보안 또는 컴플라이언스 확인이 아닙니다. 각 애플리케이션의 구성과 사용은 별도로 검토해야 합니다. 이렇게 마련된 기반은 공통 절차를 제공하고 확장 및 예외에 대한 책임을 명확하게 드러냄으로써 이러한 작업을 지원합니다.