클라우드의 개념과 책임 분계

클라우드 컴퓨팅은 IT 자원을 보유하지 않고 필요할 때 필요한 만큼만 빌려 사용한 만큼만 지불하는 이용 형태이다. 요청부터 이용 개시까지 걸리는 시간이 짧고, 반납하면 그 시점에 과금도 멈춘다. 도입 전에 필요량을 확정해 장비를 구매하는 것도, 전원과 공조까지 자사에서 관리하는 것도 온프레미스 방식이며, 양을 미리 정해야 하기 때문에 과잉 프로비저닝이나 용량 부족이 발생한다. 계약 기간 중에는 양을 변경할 수 없다는 설명은, 나중에 늘리거나 줄일 수 있다는 클라우드의 전제와 반대된다.

종량제(Pay-as-you-go)는 선불도 장기 약정도 없이, 실제로 사용한 만큼만 지불하는 원칙이다. 예측이 아니라 실제 수요에 맞춰 확장할 수 있으므로 과잉 프로비저닝의 위험을 줄일 수 있다. 기간을 정해 사용량을 약정하는 대신 단가가 낮아지는 것은 약정 시 절약(Save when you commit), 사용량이 늘어날수록 단가가 낮아지는 것은 많이 쓸수록 저렴(Pay less by using more), 월정액으로 묶어 초과 요금을 내지 않는 것은 정액제(Flat rate)이며, 모두 다른 원칙을 가리킨다.

많이 쓸수록 저렴(Pay less by using more)은 S3나 데이터 전송 등에 단계적 요금 체계가 적용되어, 사용량이 늘어날수록 GB당 단가가 낮아진다는 원칙이다. 기간을 정해 사용량을 약정해 단가를 낮추는 것은 약정 시 절약(Save when you commit)이며 Savings Plans가 이에 해당한다. 실제로 사용한 만큼을 그때그때 지불하는 것은 종량제(Pay-as-you-go), 월정액으로 묶어 초과 요금을 내지 않는 것은 정액제(Flat rate)이다. 4가지 원칙은 목적이 서로 다르므로 대립하는 것이 아니라 조합하여 사용한다.

약정 시 절약(Save when you commit)은 Savings Plans처럼 1년 또는 3년이라는 기간 동안 특정 사용량 수준을 약정하는 대신, 컴퓨팅이나 머신러닝 서비스의 요금이 할인되는 원칙이다. 월정액을 고정해 초과 요금을 내지 않는 것은 정액제(Flat rate)로, 이월 구조가 아니다. 사용량이 늘어날수록 단가가 낮아지는 단계적 체계는 많이 쓸수록 저렴(Pay less by using more)에 해당한다. 약정 없이 언제든 중단할 수 있는 것은 종량제(Pay-as-you-go)의 성질이며, 약정을 전제로 하는 이 원칙과는 전제가 반대이다.

2026년 8월 기준 공식 시험 가이드 목록에서 Foundational에 속하는 것은 AWS Certified Cloud Practitioner(CLF-C02)와 AWS Certified AI Practitioner(AIF-C01) 2가지이다. Developer - Associate(DVA-C02)와 Data Engineer - Associate(DEA-C01)는 모두 Associate, Advanced Networking - Specialty(ANS-C01)는 Specialty에 속한다. 명칭 끝에 레벨명이 붙는 인증은 그것이 단서가 되지만, Cloud Practitioner와 AI Practitioner에는 레벨명이 붙지 않으므로 이 둘이 Foundational이라고 기억해 두면 된다.

CLF-C02는 AWS Certified Cloud Practitioner의 시험 코드이다. CLF는 Cloud Practitioner를, 끝의 C02는 개정 세대를 나타낸다. AWS Certified AI Practitioner의 코드는 AIF-C01, AWS Certified Developer - Associate는 DVA-C02, AWS Certified Data Engineer - Associate는 DEA-C01이다. 인증 명칭은 개칭되는 경우가 있지만 시험 코드는 개정되기 전까지 바뀌지 않으므로, 교재가 최신판인지는 코드로 확인하는 것이 확실하다.

AWS Certified Solutions Architect - Professional의 시험 코드는 SAP-C02이다. SAA-C03은 같은 Solutions Architect라도 Associate 레벨의 코드이고, SOA-C03은 CloudOps Engineer - Associate, SCS-C03은 Security - Specialty의 코드이다. 앞 세 글자가 비슷해 헷갈리기 쉽지만, SAA는 Associate, SAP는 Professional에 대응한다고 기억해두면 좋다.

CLF-C02의 Exam Guide는 Cloud Concepts 24퍼센트, Security and Compliance 30퍼센트, Cloud Technology and Services 34퍼센트, Billing, Pricing, and Support 12퍼센트로 정하고 있다. 따라서 가장 큰 것은 Cloud Technology and Services, 가장 작은 것은 Billing, Pricing, and Support이다. 입문용 인증이라 개념이 가장 두꺼울 것 같지만, 실제로는 서비스 지식을 묻는 도메인이 가장 크고 다음이 보안이다. 학습 시간 배분도 이 비율에 맞추면 좋다.

SAA-C03의 Exam Guide는 Design Secure Architectures 30퍼센트, Design Resilient Architectures 26퍼센트, Design High-Performing Architectures 24퍼센트, Design Cost-Optimized Architectures 20퍼센트로 정하고 있다. 가장 큰 것은 보안 아키텍처 설계이다. 4개 도메인 이름은 Well-Architected의 기둥과 연결지어 읽으면 외우기 쉬우며, 보안, 안정성, 성능 효율성, 비용 최적화 순으로 나열되어 있음을 알 수 있다.

운영 계열 Associate 인증은 명칭이 SysOps Administrator에서 CloudOps Engineer로 바뀌고, 시험 코드도 SOA-C02에서 SOA-C03이 되었다. 구 코드의 마지막 응시일은 2025년 9월 29일, 신 코드의 시작은 2025년 9월 30일이다. Data Engineer - Associate와 Machine Learning Engineer - Associate는 운영 계열의 후속이 아니라 각각 데이터와 ML 영역에서 신설된 별개의 인증이다. DevOps Engineer - Professional은 이전부터 존재한 Professional 레벨 인증으로, 레벨도 다르다.

AWS 공식은 AWS 측의 책임을 'Security of the Cloud'라고 부르며, AWS 클라우드에서 제공되는 모든 서비스를 실행하는 인프라스트럭처의 보호, 즉 하드웨어·소프트웨어·네트워킹·시설의 보호라고 정의한다. 인스턴스에 설치한 애플리케이션의 취약점 대응은 EC2를 선택했을 때 이용자의 책임이다. 데이터 암호화 옵션 선택과 IAM을 통한 권한 부여는 어떤 서비스를 선택하든 이용자 측에 남는 작업이며, 모두 'Security in the Cloud' 쪽에 속한다.

공식은 '고객의 책임은 고객이 선택하는 AWS 클라우드 서비스에 따라 정해진다'고 명시하고 있다. 선택한 서비스에 따라 보안 책임의 일부로서 이용자가 수행해야 할 설정 작업의 양이 달라진다는 의미이다. 지원 플랜은 기술 지원을 받는 방식을 정하는 것이며 책임의 경계를 움직이는 것이 아니다. 리전과 가용 영역은 배치의 문제, 이용 기간과 이용 금액은 과금의 문제로, 어느 쪽도 책임 범위의 크기를 정하는 요인이 아니다.

공식은 EC2처럼 구성이 필요한 서비스에서는 이용자가 '게스트 OS 관리(업데이트와 보안 패치 포함), 인스턴스에 설치한 애플리케이션 소프트웨어와 유틸리티, 보안 그룹 설정'을 담당한다고 밝히고 있다. 따라서 OS 패치 적용은 이용자의 책임이다. EC2에서 AWS가 운영하는 것은 물리 기반과 가상화 계층까지이며, 인스턴스 내부의 OS는 포함되지 않는다. 지원 플랜은 기술 지원을 받는 계약일 뿐, 책임 소재를 이전하는 것이 아니다.

추상화된, 즉 매니지드 서비스에 대해 공식은 'AWS가 인프라스트럭처 계층, OS, 플랫폼을 운영하고, 고객은 엔드포인트에 접속해 데이터를 저장·조회한다'고 설명한다. 이용자에게 남는 것은 자신의 데이터 관리(암호화 옵션 포함), 자산 분류, IAM 도구를 통한 적절한 권한 적용이다. OS 업데이트도 플랫폼 운영도 이용자가 하지 않지만, 데이터 분류와 권한 설정은 어떤 서비스에서도 이용자에게서 떠나지 않는다.

책임 공유 모델의 경계는 고정되어 있지 않고 선택한 서비스에 따라 움직인다. EC2처럼 이용자가 게스트 OS를 관리하는 서비스에서는 패치 적용이 이용자의 책임이지만, S3나 DynamoDB처럼 AWS가 OS와 플랫폼까지 운영하는 서비스에서는 AWS의 책임이 된다. 따라서 '항상 AWS'도 '항상 이용자'도 틀렸다. 리전은 배치 장소의 선택일 뿐 책임 분담을 바꾸는 것이 아니다. 이 한 가지를 알아두면 처음 보는 서비스라도 EC2에 가까운지 S3에 가까운지만 생각하면 경계를 추측할 수 있다.

시설은 AWS 클라우드 서비스를 실행하는 인프라스트럭처의 일부로서 'Security of the Cloud'에 명시되어 있으며, 어떤 서비스를 사용하든 항상 AWS의 책임이다. 이용자는 이 범위를 직접 감사하거나 출입해 점검할 수 없으며, AWS가 공개하는 제3자 인증이나 감사 보고서를 통해 확인한다. 이는 3가지 통제 분류 중 상속된 통제(Inherited Controls)에 해당하며, 이용자가 AWS로부터 완전히 물려받는 부분이다. 선택한 서비스에 따라 달라지는 것은 OS나 미들웨어 계층이며 물리 계층이 아니다.

자신의 데이터 관리(암호화 옵션 포함), 자산 분류, IAM 도구를 통한 적절한 권한 적용은 추상화된 서비스를 사용하더라도 이용자에게 남는다고 공식적으로 명시되어 있다. 어떤 서비스를 선택하든 떠나지 않으므로 경계를 생각할 때의 고정점이 된다. 물리 서버 교체도 백본 네트워크 보호도 시설과 하드웨어의 문제로, 항상 AWS 쪽이다. 매니지드 서비스의 기반이 되는 OS는 AWS가 운영하므로 그 패치 적용은 이용자의 작업이 아니다.

상속된 통제는 이용자가 AWS로부터 완전히 상속받는 것으로, 물리적·환경적 통제가 해당한다고 공식적으로 정의되어 있다. 인프라 계층과 이용자 계층 양쪽에 각각 별도로 적용되는 것은 공유 통제(Shared Controls), 완전히 이용자의 책임으로 서비스와 존의 보안이 해당하는 것은 고객 특화 통제(Customer Specific Controls)이다. 상속의 방향은 AWS에서 이용자로 향하는 일방향이며, 이용자의 설정을 AWS가 이어받는 관계가 아니다.

공유 통제로 공식이 제시하는 것은 패치 관리, 구성 관리, 의식 향상과 교육 3가지이다. 모두 같은 활동이 인프라 계층과 이용자 계층 양쪽에서 병행하여 이루어진다는 점이 특징으로, 예를 들어 패치 관리라면 AWS가 자사 인프라에, 이용자가 게스트 OS와 애플리케이션에 각각 별도로 적용한다. 출입 관리, 전원 이중화, 하드웨어 조달과 폐기는 물리적·환경적 통제로 이용자가 AWS로부터 상속받는 쪽에 해당한다. 서비스와 존의 보안은 고객 특화 통제의 예이다.

DynamoDB는 추상화된 서비스이므로 AWS가 인프라 계층, OS, 플랫폼까지 운영한다. EC2에서는 이용자가 담당하던 게스트 OS 패치 적용이 이전으로 인해 AWS 측의 작업이 된다. 한편 데이터 분류와 암호화 옵션 선택, IAM을 통한 권한 부여는 어떤 서비스를 선택하든 이용자에게 남는다. 물리 시설 보호는 원래 항상 AWS의 책임이므로 이전해도 이용자로 옮겨가지 않는다. '움직이는 부분은 OS나 플랫폼 계층, 움직이지 않는 부분은 데이터와 권한'이라고 정리하면 헷갈리지 않는다.

현행 기둥은 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성의 6개이다. 지속 가능성은 2021년에 6번째로 추가된 것으로, 이것이 빠진 5개짜리 목록은 추가 이전의 오래된 정보에 해당한다. 상호운용성과 이식성은 프레임워크의 기둥으로 제시된 적이 없는 용어로, 공식 목록 어디에도 존재하지 않는다. 기둥 수가 오래된 해설 자료는 서비스명이나 시험 코드도 오래되었을 가능성이 높으므로, 교재의 신선도를 판별하는 단서도 된다.

운영 우수성은 시스템 실행과 모니터링, 그리고 프로세스와 절차의 지속적 개선에 초점을 맞추는 기둥이다. 배포 자동화, 장애 발생 후 회고를 통한 절차 갱신, 변경을 작고 빈번하게 하는 것 등이 해당한다. 정보와 시스템의 보호는 보안, 리소스 할당 최적화와 리소스 유형 선택은 성능 효율성, 불필요한 지출 제거와 리소스 적정화는 비용 최적화의 초점이며, 모두 다른 기둥을 가리킨다.

보안 기둥은 정보와 시스템의 보호에 초점을 맞추며 데이터의 완전성과 접근 제어가 핵심이다. 암호화와 최소 권한에 기반한 접근 제어는 그대로 해당한다. 사용하지 않는 리소스 정지와 크기 적정화는 비용 최적화, 배포 자동화와 회고를 통한 절차 갱신은 운영 우수성, 환경 영향 측정과 감소는 지속 가능성의 관심사이다. 책임 공유 모델에서 이용자 측에 남는 범위의 대부분은 이 보안 기둥에서 다루게 된다.

안정성은 워크로드가 의도한 기능을 수행하는 것, 그리고 장애로부터 얼마나 신속하게 복구하는가에 초점을 맞추는 기둥이다. 여러 가용 영역으로의 분산, 자동 복구, 백업과 복구 절차 검증이 여기에 속한다. 망가지지 않게 하는 것뿐 아니라 망가졌을 때 빨리 되돌리는 것까지 포함하는 점이 특징이다. 리소스 할당 최적화는 성능 효율성, 실행과 모니터링 및 절차 개선은 운영 우수성, 환경 영향 최소화는 지속 가능성의 초점이다.

성능 효율성은 IT 리소스 할당의 최적화와, 워크로드 요구에 맞는 리소스 유형 선택에 초점을 맞추는 기둥이다. 요건을 충족하기 위해 리소스 유형을 다시 선택하는 활동은 그대로 해당한다. 비용 최적화도 비슷한 작업처럼 보이지만, 그쪽은 지출 낭비를 없애는 것이 목적이며 이 상황에서는 지연 시간 요건 충족이 동기이므로 초점이 다르다. 안정성은 장애에 대한 강건함, 운영 우수성은 절차 개선을 보는 기둥으로, 둘 다 여기서의 주안점이 아니다.

비용 최적화는 불필요한 지출을 없애고 비즈니스 요건에 맞게 리소스를 적정화하는 데 초점을 맞추는 기둥이다. 사용하지 않는 자원을 멈추거나, 과대한 인스턴스를 적정 크기로 조정하거나, 요금 모델을 구분해 사용하는 판단이 해당한다. 단순히 저렴하게 만드는 것이 목적이 아니라 지불한 만큼의 가치가 나오는지를 묻는 것이 핵심이다. 정보와 시스템의 보호는 보안, 의도한 기능 수행과 복구는 안정성, 환경 영향 최소화는 지속 가능성의 초점이다.

지속 가능성은 클라우드 워크로드 실행에 따른 환경 영향을 최소화하는 데 초점을 맞추는 기둥이다. 2021년에 6번째로 추가된 가장 새로운 기둥으로, 이 기둥의 유무가 오래된 교재와의 구분점이 된다. 리소스 할당 최적화와 리소스 유형 선택은 성능 효율성, 실행과 모니터링 및 절차의 지속적 개선은 운영 우수성, 의도한 기능 수행과 장애로부터의 복구는 안정성의 초점이며, 모두 다른 기둥을 가리킨다.

빠진 것은 지속 가능성(Sustainability)으로, 클라우드 워크로드 실행에 따른 환경 영향의 최소화를 다루는 기둥이다. 2021년에 6번째로 추가되었기 때문에 그 이전에 작성된 해설은 5개인 채로 남아 있다. 운영 우수성, 성능 효율성, 안정성은 추가되기 전부터 존재한 기둥이므로 5개라고 적힌 기사에도 실려 있다. 기둥 수처럼 기본적인 부분이 오래된 기사는 다른 서술도 오래되었을 가능성이 높다고 보는 것이 좋다.

현행 기둥은 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성의 6개이며, 상호운용성은 이 목록에 포함되지 않는다. 서로 다른 시스템이 연결되는 것은 설계상 중요한 관심사이지만, Well-Architected 프레임워크에서는 그것만 따로 기둥을 세우지 않는다. 비용 최적화, 운영 우수성, 성능 효율성은 모두 6개 중 정식 기둥이다. 프레임워크에 없는 용어를 기둥으로 외워버리면 선택지 소거 과정에서 헷갈리는 원인이 된다.

불필요한 지출을 없애고 비즈니스 요건에 맞게 리소스를 적정화하는 것은 비용 최적화의 초점이며 안정성의 초점이 아니다. 안정성은 워크로드가 의도한 기능을 수행하는 것과 장애로부터 얼마나 신속하게 복구하는가에 초점을 맞추는 기둥이다. 나머지 3개는 공식 서술 그대로의 조합이다. 기둥의 이름은 일상어에 가까워서 글자의 인상만으로 연결하면 헷갈리기 쉽다. 초점을 나타내는 한 문장과 세트로 외워두면 이런 유형의 문제에서 걸려 넘어지지 않는다.

리전은 AWS가 여러 가용 영역을 갖는 세계 각지의 물리적 장소이다. us-east-1이나 ap-northeast-1 같은 이름이 붙어 있으며, 데이터 소재지와 법규제, 이용자와의 거리, 요금을 보고 선택한다. 1개 이상의 독립된 데이터센터로 구성되는 장애 분리 단위는 가용 영역에 대한 설명이다. CloudFront가 캐싱해 전송하는 거점은 에지 로케이션, 통신사업자 네트워크 안에 배치되는 것은 Wavelength Zones이다.

가용 영역은 1개 이상의 독립된 데이터센터로 구성되며, 각각 이중화된 전원·네트워크·연결성을 갖추고 별도의 시설에 수용되어 있다고 정의된다. 데이터센터 1동과 동일한 것이 아니라 하나의 묶음을 가리킨다는 점과, 다른 존과는 별개의 건물에 있다는 점이 핵심이다. 에지 로케이션과 오리진 사이의 계층은 리전별 엣지 캐시, 이용자와 가까운 도시에서 애플리케이션을 실행할 수 있는 것은 Local Zones에 대한 설명으로, 모두 다른 구조를 가리킨다.

공식은 각 리전이 '적어도 3개의, 독립적으로 물리적으로 분리된 가용 영역'으로 구성된다고 밝히고 있다. 리전 총수와 존 총수는 계속 늘어나므로 외울 의미가 적지만, 리전 하나가 최소 몇 개의 존을 갖는가 하는 구성 규칙은 안정적이어서 그대로 설계의 전제로 사용할 수 있다. 동일한 시설 내에 배치된다는 설명은 별도의 시설에 수용된다는 정의와 모순된다. 존은 이용자가 신청해서 늘리는 것도, 리전마다 1개뿐인 것도 아니다.

에지 로케이션은 CloudFront가 콘텐츠를 전송하는 전 세계 규모의 데이터센터 네트워크이다. 요청은 가장 지연이 낮은 에지 로케이션으로 라우팅되어 그곳에서 전송된다. 가용성을 높이기 위한 이중화 단위가 아니라 이용자와 가까운 곳에서 다시 나눠주기 위한 캐시 거점이라는 점이 핵심이다. 장애 분리는 가용 영역, IP 주소 범위 구분은 서브넷, 통신사업자 설비 안에서의 실행은 Wavelength Zones의 역할이다.

요청은 가장 지연이 낮은 에지 로케이션으로 라우팅되며, 그곳에 콘텐츠가 있으면 즉시 전송된다. 없으면 S3 버킷이나 HTTP 서버 같은 오리진에서 가져와 전송하고, 동시에 캐시에 남긴다. 그래서 두 번째 이후의 요청은 가까운 거점에서 직접 반환된다. 캐시가 없는 것이 오류가 되거나 이용자가 방치된 채 기다리게 되는 일은 없다. 가용 영역으로의 전달은 장애 분리 구조이며 콘텐츠 전송 흐름과는 별개의 이야기이다.

리전별 엣지 캐시는 에지 로케이션과 오리진 사이에 위치하는 캐시 계층이다. 에지에서 찾지 못했을 때 오리진까지 가지러 가는 횟수를 줄이는 역할을 한다. 가용 영역을 묶는 관리 단위는 리전, 통신사업자 네트워크 안에 배치되는 존은 Wavelength Zones로, 모두 다른 개념이다. 이용자 단말 측 캐시는 AWS의 구조가 아니라 브라우저나 OS가 갖는 기능에 해당한다.

가용 영역은 별도의 시설에 수용되고 이중화된 전원과 네트워크를 갖춘 장애 분리 단위이다. 동일한 역할의 리소스를 여러 존에 나누어 두면, 한쪽 존이 통째로 정지해도 나머지로 처리를 계속할 수 있다. 이것이 멀티 AZ 구성이며 가용성 설계의 출발점이 된다. 가장 가까운 거점에서의 전송은 에지 로케이션의 역할, 데이터 소재지는 리전 선택의 판단 재료, 사용량 약정에 따른 단가 인하는 요금 모델의 이야기로, 어느 것도 존을 나누는 동기가 아니다.

Local Zones는 최종 사용자나 워크로드와 더 가까운 AWS 인프라에서 애플리케이션을 실행할 수 있게 하는 구조로, 리전에서 떨어진 도시에 배치된다. 에지 로케이션과 비슷하게 '가까운 곳'을 다루지만, 이쪽은 애플리케이션 자체를 실행하는 장소이지 콘텐츠를 배포하는 캐시가 아니라는 점이 다르다. 리전 내 장애 분리는 가용 영역, 배포 전용 거점은 에지 로케이션, 오리진 앞의 중간 캐시는 리전별 엣지 캐시를 가리킨다.

Wavelength Zones는 통신사업자의 네트워크 안에 배치되는 존이다. Local Zones와 마찬가지로 이용자와 가까운 곳에서 애플리케이션 자체를 실행하기 위한 구조로, 콘텐츠를 배포하는 캐시 거점인 에지 로케이션과는 목적이 다르다. 에지 로케이션과 오리진 사이에 놓이는 것은 리전별 엣지 캐시, 리전 안에서 장애를 분리하는 단위는 가용 영역, VPC의 IP 주소 범위를 나누는 것은 서브넷이다.

가용 영역은 별도의 시설에 수용된 장애 분리 단위이므로, 존 전체가 멈추는 사태에 대비하려면 존을 넘나들며 배치하는 수밖에 없다. 각 리전은 적어도 3개의 분리된 존으로 구성되므로 같은 리전 내에서 여러 존으로 분산이 가능하다. 같은 존 안에서 대수를 늘려도 그 존이 다운되면 전멸하므로 요건을 충족하지 못한다. CloudFront는 전송을 빠르게 하는 구조이며 오리진이 멈추면 동적 처리는 계속할 수 없다. 요금 플랜 변경은 비용의 문제이며 가용성과는 무관하다.