[클라우드 보안] 1편 - 클라우드는 무엇이 다른가? AWS와 Global Infrastructure

About this offer

AWS를 공부하다 보면 EC2, S3, VPC, IAM처럼 수많은 서비스 이름을 먼저 접하게 된다. 하지만 각각의 서비스를 외우기 전에 먼저 이해해야 할 것이 있다. 클라우드는 기존의 온프레미스 환경과 무엇이 다르고, AWS의 리소스는 어떤 물리적·논리적 구조 위에서 동작하는가? 이 구조를 이해해야 이후 EC2를 어느 Region에 생성해야 하는지, 여러 Availability Zone에 서버를 분산하는 이유는 무엇인지, 특정 지역에 데이터를 저장해야 하는 이유는 무엇인지 자연스럽게 연결된다. 이번 글에서는 AWS 서비스를 본격적으로 다루기 전에 클라우드 컴퓨팅의 기본 개념과 AWS Global Infrastructure 를 먼저 정리한다. 1. 클라우드 컴퓨팅이란? 강의자료에서는 클라우드 컴퓨팅을 다음 네 가지 키워드로 설명한다. Internet IT Resource On-demand 종량 요금제 이를 하나로 연결하면 다음과 같다. 인터넷을 통해 필요한 IT 리소스를 필요할 때 바로 사용하고, 사용한 만큼 비용을 지불하는 방식 여기서 IT 리소스는 단순히 서버만 의미하지 않는다. AWS에서는 앞으로 다음과 같은 다양한 자원을 필요할 때 생성해서 사용할 수 있다. Compute Storage Network Database Load Balancer Serverless Function Monitoring 예를 들어 서버가 필요하다고 가정해보자. 온프레미스에서는 물리 서버를 준비해야 하지만 AWS에서는 필요한 서버 리소스를 생성해서 사용할 수 있다. 서버가 필요함 ↓ AWS에 Resource 요청 ↓ 필요한 Resource 생성 ↓ 사용 ↓ 필요하지 않으면 종료 또는 삭제 이처럼 필요한 IT 리소스를 준비하여 사용할 수 있는 상태로 만드는 것을 Provisioning 이라고 한다. 2. 온프레미스와 클라우드는 무엇이 다른가? On-Premises 는 기업이나 조직이 직접 데이터센터나 전산실을 구축하고 서버, 네트워크, 스토리지 등의 장비를 운영하는 방식이다. 예를 들어 기존 서버의 처리 성능이 부족해졌다고 가정해보자. 온프레미스에서는 일반적으로 다음과 같은 과정이 필요할 수 있다. 용량 부족 ↓ 필요한 용량 산정 ↓ 예산 확보 ↓ 장비 구매 ↓ 설치 및 구성 ↓ 서비스 투입 물리 장비를 추가해야 하므로 일정한 시간과 절차가 필요하다. 반면 클라우드에서는 필요한 리소스의 크기나 수를 비교적 빠르게 변경할 수 있다. 현재 Resource ↓ 부하 증가 ↓ Resource 확대 또는 현재 Resource ↓ 사용률 감소 ↓ Resource 축소 강의에서도 온프레미스와 비교한 클라우드의 중요한 장점으로 유연성(Flexibility) 을 반복해서 강조했다. 즉 클라우드에서는 리소스를 필요할 때 생성하고, 확장하고, 축소하고, 필요하지 않으면 다시 제거할 수 있다. 3. On-demand가 중요한 이유 On-demand 는 말 그대로 필요한 시점에 바로 사용할 수 있다 는 의미다. 예를 들어 갑자기 사용자가 증가해 기존 서버로 트래픽을 처리하기 어려워졌다고 하자. 온프레미스 환경에서는 물리적인 장비 확보가 필요할 수 있지만, 클라우드 환경에서는 필요한 리소스를 비교적 빠르게 추가할 수 있다. 하지만 여기서 하나 주의해야 한다. 클라우드를 사용한다고 Capacity Planning이 필요 없어지는 것은 아니다. 처음부터 어느 정도의 CPU, Memory, Storage가 필요한지 판단해야 하고, 운영 이후에도 실제 사용량을 관찰하면서 적절한 크기로 조절해야 한다. 차이는 한 번 결정한 용량에 계속 묶이는 것이 아니라 이후에도 비교적 쉽게 변경할 수 있다는 것 이다. 이 개념은 이후 EC2 Instance Type, Auto Scaling, CloudWatch를 공부할 때 다시 연결된다. 4. 종량 요금제는 장점이면서 주의점이다 AWS는 기본적으로 사용하는 리소스와 사용량을 기준으로 비용이 발생하는 구조를 가진다. 따라서 직접 대규모 장비를 미리 구매하는 방식과 비교하면 다음과 같은 장점이 있다. 초기 대규모 투자 비용 감소 물리 Infrastructure 유지관리 부담 감소 필요한 만큼 Resource 사용 빠른 서비스 배포 전 세계 Infrastructure 활용 수요에 따른 용량 조절 하지만 종량 요금제는 반대로 말하면, 사용하지 않는 리소스를 그대로 남겨두면 불필요한 비용이 발생할 수 있다는 뜻 이기도 하다. 강의에서 반복적으로 강조된 표현이 있다. "만들면 돈이다." Free Tier가 있다고 해서 모든 AWS Resource가 무조건 무료인 것은 아니다. 특히 학습 과정에서는 리소스를 생성한 뒤 실습 목적을 달성했다면 필요하지 않은 Resource를 정리하는 습관이 중요하다. Resource 생성 ↓ 설정 ↓ 검증 ↓ 실습 목적 달성 ↓ 불필요한 Resource 삭제 앞으로 진행하는 실습에서도 Resource 정리까지 실습 과정의 일부 로 본다. 5. 클라우드 서비스 모델 클라우드 서비스는 관리 범위에 따라 일반적으로 다음과 같이 구분할 수 있다. 모델 의미 핵심 관점 IaaS Infrastructure as a Service 서버·스토리지·네트워크 같은 Infrastructure 사용 PaaS Platform as a Service Application 실행에 필요한 Platform까지 제공 SaaS Software as a Service 완성된 Software를 Service 형태로 사용 지금 단계에서는 각 모델의 세부 사항을 외우기보다 다음 정도만 이해하면 된다. 서비스마다 AWS가 관리하는 범위와 사용자가 직접 관리해야 하는 범위가 다르다. 예를 들어 뒤에서 다룰 EC2는 사용자가 OS와 Application을 상대적으로 많이 관리하지만, RDS나 Lambda처럼 AWS가 더 많은 운영 영역을 관리하는 서비스도 있다. 이 차이는 이후 Shared Responsibility Model 을 다룰 때 다시 연결한다. 6. AWS Global Infrastructure 클라우드에서는 물리 서버를 직접 보지 않지만 실제 리소스가 물리적 위치 없이 존재하는 것은 아니다. AWS 역시 전 세계에 위치한 실제 데이터센터를 기반으로 서비스를 제공한다. AWS Global Infrastructure를 이해할 때 가장 중요한 개념은 다음과 같다. AWS Global Infrastructure │ ├─ Region │ │ │ ├─ Availability Zone │ │ └─ Data Center │ │ │ ├─ Availability Zone │ │ └─ Data Center │ │ │ └─ Availability Zone │ └─ Data Center │ └─ Edge Location 앞으로 AWS Architecture를 공부하면서 Region과 Availability Zone은 계속 등장한다. 7. Region이란? Region 은 AWS가 서비스를 제공하는 지리적인 영역이다. AWS Console에서는 여러 Region 중 하나를 선택하여 리소스를 생성하게 된다. 예를 들면 다음과 같다. Asia Pacific (Seoul) Asia Pacific (Tokyo) US East ... 각 Region에는 이를 식별하기 위한 Region Code도 존재한다. 중요한 것은 Region 이름이나 Code 자체를 외우는 것이 아니다. Region을 선택한다는 것은 어느 지역의 AWS Infrastructure를 기반으로 서비스를 운영할 것인지 결정하는 것이다. 따라서 Region 선택은 단순한 Console 설정이 아니다. 8. 어떤 Region을 선택해야 할까? 강의자료에서는 Region을 선택할 때 크게 네 가지를 고려한다. 1) Latency 사용자와 물리적으로 가까운 곳에서 서비스를 제공하면 일반적으로 Network 지연 시간을 줄이는 데 유리하다. 예를 들어 서비스의 주요 사용자가 한국에 있다면 서울 Region을 고려할 수 있다. 하지만 중요한 것은 다음이다. 내가 한국에 있기 때문에 서울 Region을 선택하는 것이 아니라, 서비스를 사용하는 Client가 어디에 있는지를 기준으로 판단한다. 사용자가 미국에 집중되어 있다면 미국의 Region이 더 적합할 수도 있다. 2) 법적·규제 요구사항 서비스에서 처리하는 Data가 특정 국가나 지역 안에 저장되어야 하는 요구사항이 있을 수 있다. 따라서 Region은 성능뿐 아니라 다음과도 연결된다. Data 위치 법적 요구사항 Compliance Cloud Security 관점에서 Region 선택이 중요한 이유다. 3) Service Availability 모든 AWS Service가 항상 모든 Region에서 동일하게 제공된다고 가정해서는 안 된다. 사용하려는 서비스가 목표 Region에서 제공되는지도 확인해야 한다. 4) Cost AWS Service의 비용은 Region에 따라 차이가 발생할 수 있다. 따라서 Region을 결정할 때는 다음을 함께 고려해야 한다. Region 선택 │ ├─ Client와의 거리 ├─ 법적·규제 요구사항 ├─ 필요한 AWS Service └─ Cost 즉 Region 선택은 단순히 가장 가까운 곳을 고르는 문제만은 아니다. 9. Availability Zone이란? 하나의 Region 내부에는 여러 Availability Zone(AZ) 이 존재한다. 강의에서는 실제 데이터센터들을 일정한 단위로 묶은 영역으로 설명한다. Region │ ├─ AZ-A ├─ AZ-B └─ AZ-C 그렇다면 하나의 Region 안을 다시 여러 AZ로 나누는 이유는 무엇일까? 핵심은 장애를 예상한 Architecture를 구성하기 위해서 다. 예를 들어 Web Server 두 대를 모두 같은 AZ에 배치했다고 가정하자. AZ-A ├─ WEB 1 └─ WEB 2 Server 자체는 두 대지만 같은 장애 범위에 존재한다. 해당 AZ에 문제가 발생하면 두 Server가 동시에 영향을 받을 수 있다. 반대로 동일한 기능을 수행하는 Resource를 서로 다른 AZ에 나누어 배치할 수 있다. Region AZ-A AZ-B └─ WEB 1 └─ WEB 2 이 구조는 이후 다음 내용을 이해하는 기반이 된다. ELB Auto Scaling RDS Multi-AZ High Availability 지금은 다음 차이만 확실하게 기억하면 된다. Region은 서비스를 배치할 지리적 영역이고, Availability Zone은 하나의 Region 안에서 장애 범위를 분리할 때 중요한 단위다. 10. 장애를 예상해서 설계한다 강의자료에서는 AWS Cloud의 특징 중 하나로 장애를 예상한 설계 를 제시한다. Cloud를 사용한다고 장애가 사라지는 것은 아니다. Server에 문제가 생길 수도 있고, 특정 Availability Zone에 문제가 생길 수도 있다. 따라서 중요한 것은, 장애가 발생하지 않을 것이라고 가정하는 것이 아니라, 장애가 발생해도 서비스를 유지할 수 있도록 설계하는 것 이다. 예를 들어 하나의 Server만 운영한다면 해당 Server 장애가 곧 서비스 장애가 될 수 있다. Client ↓ WEB Server X 서비스 중단 반면 이후에는 여러 AZ와 여러 Server를 활용해 다음과 같은 구조를 만들게 된다. Client ↓ Load Balancer / \ AZ-A AZ-B WEB 1 WEB 2 이 부분은 7편에서 ELB와 Auto Scaling을 이용해 실제로 구성한다. 11. Edge Location은 무엇인가? AWS Global Infrastructure에는 Region과 AZ 외에 Edge Location 도 존재한다. Edge Location은 사용자와 가까운 위치에서 요청을 처리하기 위해 활용되는 Infrastructure다. 대표적으로 이후 다룰 CloudFront와 연결된다. Client ↓ Edge Location ↓ AWS Region ↓ Origin Resource 모든 요청이 항상 멀리 있는 Origin Resource까지 이동하지 않고 가까운 Edge Infrastructure를 활용할 수 있다. Edge Location과 CloudFront의 구체적인 역할은 이후 High Availability와 Edge Architecture를 다루는 편에서 자세히 정리한다. 12. AWS Resource마다 동작 범위가 다르다 AWS 서비스를 공부할 때는 단순히 무슨 기능을 제공하는가 만 보는 것이 아니라 해당 Resource가 어느 범위에 존재하는가 도 함께 확인해야 한다. 강의에서는 예를 들어 다음과 같이 설명한다. Availability Zone 단위 → EC2 → EBS Region 단위 → S3 왜 이것이 중요할까? Resource가 특정 AZ에 종속된다면 해당 AZ의 장애가 Architecture에 어떤 영향을 미치는지 고려해야 한다. 반대로 Region 수준에서 제공되는 서비스라면 설계 관점이 달라진다. 따라서 AWS Service를 공부할 때는 다음 두 질문을 같이 보는 것이 좋다. 이 서비스는 무엇을 하는가? 그리고 이 Resource는 어느 범위에서 동작하는가? 이 관점은 이후 VPC, S3, RDS, ELB 등을 공부할 때 계속 사용한다. 13. Global Infrastructure가 제공하는 또 하나의 유연성 AWS Global Infrastructure를 이용하면 직접 해당 국가에 데이터센터를 구축하지 않더라도 원하는 지역의 AWS Infrastructure를 활용할 수 있다. 예를 들어 한국에서 서비스를 운영하고 있더라도 서비스 요구사항에 따라 다른 Region을 사용할 수 있다. Service │ ├─ Seoul Region ├─ Tokyo Region └─ Other Region 즉 Cloud가 제공하는 유연성은 CPU와 Memory를 늘리고 줄이는 것에만 있는 것이 아니다. 필요한 지역에 필요한 Infrastructure를 빠르게 구성할 수 있다는 것 또한 Cloud의 중요한 유연성이다. 이 Global Infrastructure는 이후 다음 개념들의 기반이 된다. Multi-AZ High Availability RDS Multi-AZ Auto Scaling Route 53 Failover Cross-Region Replication Disaster Recovery 14. 첫 번째 실습 - AWS Management Console 살펴보기 첫 번째 실습에서는 아직 EC2나 S3 같은 Resource를 생성하지 않는다. 앞으로 계속 사용할 AWS Management Console의 기본 구조와 Region 선택 위치를 확인하는 것 이 목적이다. 실습 목표 이번 실습에서는 다음을 확인한다. AWS Management Console에 로그인할 수 있는가? 현재 로그인한 사용자와 Account를 확인할 수 있는가? 현재 선택된 Region을 확인할 수 있는가? 원하는 AWS Service를 검색할 수 있는가? Console Home에서 어떤 정보를 확인할 수 있는가? Console 메뉴 위치를 암기하는 것이 목적은 아니다. AWS Resource를 작업하기 전에 어떤 Account에서, 어떤 Region에서, 어떤 Service를 사용하고 있는지 확인하는 습관을 만드는 것 이 이번 실습의 핵심이다. 실습 Architecture 이번 실습에서는 별도의 AWS Resource를 생성하지 않는다. Web Browser ↓ AWS Management Console │ ├─ Account / User 확인 ├─ Region 확인 └─ AWS Service 검색 실습 환경 강의자료 기준으로 다음 환경을 사용한다. AWS Account AWS Management Console 강의에서 지정된 로그인 정보 강의에서 지정된 Region 실습자료에서는 사전에 다음 사항도 안내한다. AWS 계정 준비 청구 비용 임계치 알람 설정 계정 로그인 Region 확인 실습 완료 후 생성한 Resource 정리 이번 실습에서는 Resource를 만들지 않지만 이후부터는 실제 AWS Resource를 생성하므로 이 원칙을 계속 적용한다. 초기 상태 AWS Management Console에 로그인하기 전 상태에서 시작한다. 강의 환경에서는 여러 학습자가 동일 Account를 함께 사용할 수 있기 때문에 실습 혼선을 줄이기 위해 서로 다른 Region을 배정했다. 따라서 실습에서는 임의로 서울 Region을 선택하지 않고 강의에서 자신에게 지정된 Region을 사용한다. 실제 운영 환경에서는 앞에서 살펴본 다음 기준을 이용해 Region을 결정한다. Latency 법적·규제 요구사항 Service Availability Cost 실습 절차 1. AWS Management Console에 로그인 강의에서 제공된 Account 정보와 사용자 정보를 이용해 AWS Management Console에 로그인한다. 로그인이 완료되면 Console Home 화면을 확인한다. 2. 현재 로그인한 사용자 확인 Console 우측 상단의 Account/Profile 영역을 확인한다. 여기에서 현재 어떤 사용자로 로그인되어 있는지 확인한다. 아직 IAM의 구조는 자세히 다루지 않는다. IAM User, Root User, Role, Policy와 같은 인증·권한 구조는 3편에서 별도로 살펴본다. 3. 현재 Region 확인 Console 우측 상단의 Region Selector를 확인한다. 예를 들어 다음과 같이 표시될 수 있다. Asia Pacific (Seoul) 강의 실습에서는 자신에게 할당된 Region이 선택되어 있는지 확인한다. Region이 다르면 앞으로 생성한 Regional Resource가 다른 화면에서는 보이지 않을 수 있으므로 실습 시작 전에 Region을 확인하는 습관을 들이는 것이 좋다. 4. AWS Service 검색 Console 상단의 Service Search 기능을 확인한다. 예를 들어 다음과 같은 서비스를 검색해볼 수 있다. EC2 S3 IAM VPC 이번 실습에서는 해당 Service에서 Resource를 생성할 필요는 없다. 앞으로 대부분의 실습은 다음과 같은 흐름으로 진행된다. Service 검색 ↓ 해당 Service Console 이동 ↓ Resource 생성 및 설정 ↓ 결과 확인 5. Console Home 확인 AWS Console Home에서 다음 항목을 확인한다. 전체 Service 또는 Service Search 현재 Region 현재 User / Account 최근 방문한 Service AWS Event 관련 영역 비용 및 사용량 관련 영역 AWS Console 화면은 변경될 수 있기 때문에 정확한 버튼 위치를 암기하는 것보다 어떤 정보를 어디에서 확인해야 하는지 이해하는 것이 중요하다. 핵심 명령어 이번 실습은 AWS Management Console을 확인하는 실습이므로 CLI나 Linux 명령어는 사용하지 않는다. AWS CLI는 IAM과 Access Key를 학습한 이후 별도의 실습에서 사용한다. 확인해야 할 결과 강의자료 기준으로 다음 결과를 확인할 수 있다. AWS Management Console에 로그인할 수 있음 현재 로그인한 사용자와 Account 정보를 확인할 수 있음 현재 선택된 Region을 확인할 수 있음 사용 가능한 다른 Region 목록을 확인할 수 있음 Service Search를 통해 원하는 AWS Service를 찾을 수 있음 최근 방문 Service와 비용 관련 정보를 확인할 수 있음 이번 실습에서는 AWS Resource를 생성하지 않기 때문에 별도의 Resource 동작 결과는 발생하지 않는다. 결과 해석 이번 실습에서 가장 먼저 이해해야 할 것은 다음이다. AWS Management Console = AWS Resource를 관리하는 Interface Console에서 Region을 선택하는 것도 단순한 화면 설정이 아니다. 이후 Regional Resource를 생성하게 되면 다음과 같은 의미를 가진다. Region 선택 ↓ 해당 Region의 Infrastructure 사용 ↓ Resource 생성 따라서 앞으로 AWS를 사용할 때는 작업 전 다음 세 가지를 확인하는 습관을 들이는 것이 좋다. 나는 어떤 User로 로그인했는가? ↓ 어떤 Region을 사용하고 있는가? ↓ 어떤 Service에서 작업하고 있는가? 이 세 가지는 이후 EC2, IAM, VPC, RDS 등 대부분의 실습에서 계속 중요하게 사용된다. 보안