AWS SAA 자격증 준비 (2) - 클라우드 개념, 인프라, 보안 및 다중계정

클라우드 자격증 시리즈 첫 번째 글로, 개괄적인 클라우드 이야기를 정리하려고 한다. 클라우드란 어떻게 정의할 수 있는지, 어떤 주요 서비스들이 있는지를 살펴볼 것이다.

​

클라우드란

클라우드 서비스란 무엇일까? 클라우드 플랫폼들은 대부분 큰 회사에서 주도하고 있다. Amazon, Microsoft와 같이 평소에도 본사의 서비스를 운영하기 위해 여러 대의 큰 서버들을 운영하는 곳이다. 이 회사들은 늘 구비하고 있는 모든 서버를 사용하지 않는다. 즉 유휴 서버들이 있다. 이러한 유휴 서버들을 다른 회사에 대여해주면 어떨까 하는 아이디어에서 클라우드가 시작했다. 클라우드 서비스가 있기 전에는 모든 회사가 어떤 서비스를 개발하거나 컴퓨팅 자원이 필요할 경우 직접 서버를 구매해서 구비해두었다. 이를 '온프레미스(On-premise)'라고 부른다. 하지만 이러한 서버를 운영하고 관리하는 데에는 많은 비용이 든다. 서버를 두기 위한 물리적인 공간, 예를 들어 사무실에 어떤 공간은 서버실로 두어야한다. 그리고 서버가 다운되거나 인터넷 혹은 전류 공급에는 문제가 없는지 등의 물리적인 관리부터 서버 내에서 해킹은 없는지 부하는 없는지 내부 관리도 함께 필요하다. 이에 따라 대형 회사들은 보유하고 있는 서버들 중에서 잉여 서버들이 남기 시작하면서 이러한 귀찮은 관리를 모두 대신해주면서 서버를 사용하는 비용만을 지불하라고 타사에게 판매하기 시작한 것이다.

​

클라우드 컴퓨팅이란

그럼 클라우드 컴퓨팅은 어떻게 정의할 수 있을까? AWS에서는 3가지 키워드로 클라우드 컴퓨팅에 대해 설명하고 있다. 첫째는 인터넷이다. 인터넷을 통해 통신하는 컴퓨팅 자원이라는 것이다. 두 번째는 종량제이다. 클라우드를 사용하는 가장 큰 이유이기도 한데 사용하는 만큼 (Pay as you go) 지불하는 것이다. 예를 들어 내가 서버를 구비해두고 서버를 실제로 사용하지 않았다면 (중지해두거나 종료하였다면) 그 양/시간만큼은 지불하지 않는다. 마지막은 온디맨드이다. 내가 필요할 때마다 필요한 만큼 사용하는 것이다. 내가 필요한만큼 자원을 요청하고 받을 수 있다.

​

클라우드의 이점

이러한 클라우드 서비스의 이점은 여러 가지가 있다. 첫 번째는 사용한 만큼 지불하기 때문에 억울하게(?) 지불하는 경우는 없을 것이다. 그리고 용량 추정을 할 필요도 없다. Auto Scaling 기능이라고 하여 내가 컴퓨팅 자원이 더 필요한 상황에는 자동으로 서버 용량/수를 증가시켜주기도 한다. 또 서버를 운영하는 수고를 덜 수 있다. 이러한 부분들이 속도 혹은 비용을 절감하는 데에 도움이 된다. 게다가 컴퓨팅 자원이 전 세계에 고루 분포되어 있기 때문에 내가 원하는 지역에 원하는 만큼의 컴퓨팅 자원을 이용하여 서비스를 수십분 만에 전세계로 배포할 수 있다.

​

AWS 인프라

그럼 AWS의 인프라에 대해 넘어가보자. AWS의 인프라 환경은 세 가지로 분류할 수 있다.

1) 리전 (Region) : 2개 이상의 AZ 집합

2) 가용영역 (Availability Zone, AZ) : 하나 이상의 데이터 센터 집합

3) 로컬 영역(Local Zones) : 도시 규모가 큰 곳에 위치해 있음. 최종 사용자가 빠르게 서비스를 쓸 수 있도록 하기 위함. AR/VR, 라이브 비디오 스트리밍 등의 경우 지연 시간이 최대한 짧기를 원하기 때문에 최종 사용자에게 더 가까운 위치에 워크로드를 배포해야 하는 경우 사용. 예를 들어 최종사용자가 보스턴에 있다면 가장 가까운 리전은 노던 버지니아인 반면 Local Zone은 보스턴에 있어 지리적으로 더 가까운 곳에 워크로드 배포.

AWS는 전세계적으로 여러 다양한 지역(주로 인구가 밀집된 지역 혹은 지리적인 중요성이 있는 곳에 위치해있다)에 데이터 센터를 운영하고 있다. 데이터 센터에는 수십, 수백대의 서버들이 운영되고 있다. 이 데이터센터들을 모아 가용영역으로 부른다. 가용영역은 데이터 센터의 집합 단위로 생각하면 된다. 이 가용영역들을 또 모아 '리전'이라고 부르는데 리전은 우리가 흔히 아는 전세계의 주요 지역 단위이다. 국내향 서비스들은 AWS에서 리전을 ap-northeast-2로 Asia Pacific (Seoul)로 잡는다.

AWS 리전

AZ를 구분하는 이유는 리전 내에서도 고가용성(High Availability)을 높이기 위함이다. 예를 들어 리전 내에서도 어떤 데이터 센터는 서버가 다운이 되어 인프라 환경이 안정적이지 않다면 다른 AZ에 있는 데이터 센터내 서버에 서비스를 배포하여 서비스측으로 장애가 이어지지 않게 하기 위함이다. 이에 따라 AWS는 AZ를 100km 이내로 떨어뜨려 AZ간 통신은 빠르면서도 서로 독립적으로 운영할 수 있도록 셋팅했다. 참고로 서울 리전의 가용영역은 처음에 2개로 시작하였다가 최근 4개까지 확장되었다. AWS에서는 서비스의 고가용성을 위해서는 2개 이상의 가용영역에 서버 배포하기를 권장한다.

리전은 서로 백본 네트워크(backbone network) 즉 해저 광케이블로 서로 연결되어있다고 한다. 리전 선택할 때에도 규칙이 정해져있다. 첫 번째는 데이터 규정 준수라고 하여 데이터가 어디에 적재되어야하는지 고려한다. 내가 국내향 서비스를 운영하면서 서비스 운영에 필요한 데이터베이스를 한국에 두고 운영하고 싶다면 서울 리전을 선택하는 것이다. 두 번째는 대기시간이다. 최종 사용자(end-user)의 위치에 따라 결정된다. 사실 가장 중요한 기준이기도 하다. 결국 사용자가 서비스를 사용할 때 지연시간이 없어야할텐데 주요 유저들이 해외에 위치해있다면 서울 리전이 아닌 해외 리전을 선택해야할 것이다. 마지막은 요금이다. 리전마다 요금체계가 조금씩 다르다. 그래서 앞서 두 기준이 어느 곳에 위치해도 크게 문제가 없다면 요금제로 좀 더 혜택을 볼 수 있는 리전을 선택해야한다.

AWS 인프라로 엣지 로케이션(Edge Location)이란 개념도 있다. 흔히 CDN(Contents Delivery Network)로 지연 시간을 줄이고자 접근이 높은 데이터를 엣지 로케이션에 캐싱해두어 최종 사용자가 전세계 어느 곳에 있든 빠르게 콘텐츠를 접근할 수 있도록 해주는 인프라이다. 뿐만 아니라 보안을 강화하는 효과도 있다.

AWS Edge Location을 활용하는 서비스인 AWS CloudFront, 출처 :  https://aws.amazon.com/ko/cloudfront/features/?whats-new-cloudfront.sort-by=item.additionalFields.postDateTime&whats-new-cloudfront.sort-order=desc

참고로 AWS 엣지는 아래와 같이 나뉜다.

- AWS Wavelength : 5G 사업자

- AWS Outposts : 온프레미스 / VPN

- AWS Local Zones : VPC

- AWS Edge Location : CloudFront, WAF, Shield

 

엣지 로케이션을 사용하는 서비스는 CloudFront이다. AWS CloudFronts는 글로벌 콘텐츠 전송 네트워크로서

정적 혹은 동적 콘텐츠를 전송한다. 이 서비스는 내장된 보안 기능을 갖추고 있는 동시에 콘텐츠 엑세스 요청이 들어오게 되면 최적의 엣지 로케잉션으로 라우팅한다. 만약 캐시되지 않은 콘텐츠가 검색되면 콘텐츠 캐싱을 위해 CloudFront 엣지로케이션으로 오리진콘텐츠를 전송한다.

 

CloudFront는 구성 시에 오리진을 선택하도록 되어있는데 오리진은 S3버킷, ELB, 혹은 사용자 지정 오리진이 될 수 있다. 오리진을 지정한 이후 배포를 생성하여 캐시 동작에 대해 정의한다. 예를 들어 경로 패턴을 지정하거나, 서명된 URL만 허용하는 등의 캐싱에 대해 구체적으로 정의한다. 선택사항으로 WAF설정과 같은 보안 추가가 가능하다.​

 

AWS 서비스 접근방법

AWS 서비스를 이용할 수 있는 방법은 세가지가 있다:

1) AWS 관리 콘솔 - 웹 UI로 접근하는 방법이다. 콘솔에 접근하면 클릭 몇 번으로 서비스를 배포할 수 있다.

2) AWS CLI - 터미널에서 AWS API를 활용하여 AWS 서비스를 사용하게 된다. 터미널 내 명령어 몇 줄로 서비스를 배포할 수 있다.

3) SDK - 접근하고자 하는 서비스에 SDK를 삽입하여 AWS API에 접근하는 방법이다.

흔히 1)과 2)의 방법을 많이 사용한다.

​

AWS 보안

AWS에는 공동 책임 모델이라 하여 AWS와 (AWS의)고객이 모두 보안에 대해 책임을 지게 하는 정책을 운영하고 있다. 책임을 나누는 분야가 다른데, AWS는 클라우드 자체의 보안을 담당한다. 예를 들어 리전, 가용영역, 엣지 로케이션 등은 AWS가 보안을 담당하게 되지만 고객 데이터나 애플리케이션, 자격증명(IAM), 액세스 관리는 고객이 담당하게 된다. 고객은 클라우드 내부 보안을 담당하는 것이다. 즉 내가 권한 부여를 너무 후하게 주어 애플리케이션을 해킹당했을 때는 고객이 보안의 책임을 다하지 못한 것이 된다.

 

AWS에는 AWS의 시작과 모든 것이라고 할 수 있는 IAM서비스가 있다. IAM은 기본적으로 액세스 제어를 관리하며 AWS 서비스 및 리소스에 대한 전반적인 액세스를 관리, 사용자/그룹/역할을 생성하고 관리하는 서비스이다. 좀 더 자세히 설명하자면 IAM은 Identity and Access Management의 약자로 두 가지 기능을 한다.

- Authentication : who (인증) ← Identity

- Authorization : what to do (인가) ← Access

즉 누가 어떤 권한을 갖게될 것인가에 대해 정의하는 서비스이다. AWS의 모든 서비스는 IAM에 따라 사용자의 권한을 파악하고 서비스에 대한 접근을 허락/거절하게 된다. 가장 처음에 AWS 계정을 생성하게 된 이메일로, 즉 결제정보가 연결된 계정은 root 사용자가 된다. 하지만 AWS는 이 root사용자가 막강한 권한을 보유하고 있기 때문에 생성 후에는 일반적인 사용자에게 root권한을 부여하는 것을 권장하지 않는다.

 

IAM은 root외에도 여러 '사용자(user)'를 만들 수 있게 해준다. 사용자는 두 가지 유형으로 AWS에 엑세스가 가능하다 :

1) 엑세스 키 : 엑세스키ID, 비밀 엑세스키

2) 암호 : management console로 로그인. 즉 API, CLI, SDK 호출은 어려움

이 외에도 사용자 그룹단위로 생성도 가능한데, 사용자 그룹이란 말 그대로 하나 이상의 IAM 사용자를 그룹으로 묶는 것이다. 이 때 AWS는 사용자가 여러 그룹에 소속되어 권한이 충돌하게 될 경우 하나라도 Disallow 권한이면 접근 불가한 보수적인 권한 정책을 운영한다.

 

사용자가 생성되면 해당 사용자에게 여러 권한(permission)의 집합체인 정책(policy)을 부여하게 되는데 이 정책(policy)은 JSON형태의 문서로 어떤 서비스에 대한 권한을 허용/거부할 것인지를 나열하고 있다. 구성요소는 아래와 같다.

- IAM 서비스의 구성요소 : Effect, Principal, Action, Resource, Condition

 

정책(policy)은 두 가지 유형이 있다.

i. 리소스 기반 정책(policy) : 리소스에 누가 접근이 가능할지?

ii. 자격증명 기반의 정책(policy) : User/Group/Role이 어떤 작업을 가능하게 할것인지?

아래 이미지는 자격증명 기반의 policy 예시를 보여주고 있다.

AWS 정책(Policy) 예시, 출처 :  https://www.msp360.com/resources/blog/aws-iam-policy/

IAM은 기본적으로 암시적 거부(implicit disallow) 정책을 운영하고 있다. 즉 정책(policy)으로 허용하면 명시적(explicit)으로 허용하는 것이다. 이 외에 허용한 적이 없거나, 허용 여부를 판단하지 않았을 때는 모두 '거부'로 처리하고 있다. 아래 이미지가 정책 결정 방법에 대해 프로세스를 표현하고 있다.

• 계층적 방어 : SCP 필터 > 권한 경계 필터 > 자격 증명 기반 정책 순으로 허용/거부 판단

* SCP : AWS Organizations SCP (서비스 제어 정책)

출처 사진 링크 참조

IAM서비스는 사용자 단위로 정책을 매핑하여 권한을 부여할 수도 있지만, 더 안전한 방법으로 역할(Role)이라는 기능도 제공한다. 역할은 임시적으로 권한을 부여하는 것인데, Trust Relationship(누가 정책을 가져갈건지), permission(무엇을 할 수 있는지) 두 가지로 구성되어있다. 사용자/서비스가 역할을 부여받게 되면 임시적으로 역할에 매핑된 권한들을 부여받게 된다. 이 때 역할을 부여받는 것을 '역할을 수임(assume)'했다고 표현한다. 예를 들어 사용자가 스토리지 서비스인 AWS S3에 접근이 필요할 때 영구적으로 IAM 서비스에서 해당 사용자에게 S3접근 권한을 나열한 정책을 연결할 수 있지만, 해당 사용자가 S3 접근이 가능한 Role을 잠시 가져가는 것도 방법이다.

 

이외에 꼭 사용자를 지정하지 않더라도 계정 페더레이션 기능을 이용하여 AWS계정 없이도 AWS 사용가능하도록 설정할 수 있다. 자격증명공급자(IdP, ex) Google, Facebook등 보인증명 가능한 서비스)와 연계하여 AWS가 자격증명공급자의 신원증명 정보를 기반으로 AWS 접근이 가능하기도 하며, 혹은 AWS SSO를 서비스를 사용하여 페더레이션을 진행할 수도 있다.

 

AWS의 다중 계정 환경 지원

기업체에서 AWS를 사용하는 경우 사용자를 묶을 수 있는 그룹 단위 외에도 조직별 관리 등 구조적인 사용자 관리가 필요할 수 있다. 이 때 AWS Organizations 서비스를 사용할 수 있다.

관리 계정 산하에 여러 Organization Unit을 생성하고, 그 아래에 AWS 계정들을 묶어 관리할 수 있다.

 

AWS Organizations는 아래와 같은 특징을 지닌다.

- IAM 정책은 단일 계정 내의 개별 보안 주체에만 적용된다. 즉 조직내 AWS 계정이 두 개 이상이라면 계정을 초월하여 IAM 정책이 적용되진 않는다.

- 복수 청구서 생성이 필요한 경우 유용하다. 동시에 통합 과금도 가능하다. 계정별로 청구서는 복수로 생성되지만 납부는 통으로 가능하다.

 

추가로 AWS Control Tower 라는 솔루션도 간략하게 설명하자면, 이 서비스는 기존 Landing Zone 개념을 확대하였는데 예를 들어 AWS Organizations을 구축했을 때 클라우드 설정 및 거버넌스를 동일하게 일일이 지정하는 것이 어려울 수 있다. 이 때 AWS 셋업 자동화와 정책 관리 자동화 서비스를 통하여 회사 정책에 따른 거버넌스를 유지할 수 있다.

 

AWS의 Well-Architected Framework

AWS에서 안내하는 잘 설계된 아키텍쳐의 요소로는 아래와 같이 정리할 수 있다.

 

<보안>

• 가능한 모든 계층에 보안 솔루션을 적용
  IAM, 네트워크 엑세스 목록(NACL), 보안그룹(SG) 등의 여러 층으로 보안을 적용하는 것을 권장
• 최소 권한의 원칙
  권한을 최소한으로 주는 것이 원칙. 가장 대표적으로 root권한은 웬만해서 어떠한 경우에도 부여하지 않을 것을 권장한다.
• MFA (다중 인증) 사용

 

<비용 최적화>

• 지출 분석 및 귀속 : 오버프로비저닝 하지 않고, Auto Scaling 등의 기능으로 효율적으로 지출 및 사용
• 비용 효율적인 리소스 사용
• 추측 불필요

 

<안정성>

• 장애에서 복구가 가능하도록 설계
• 복구 절차 테스트 미리 시도
• 스케일링으로 가용성 증대 (Auto Scaling)

 

<성능 효율성>

• 지연 시간 감소하는 방향으로 설계
• 서버리스 아키텍트 사용
• 모니터링 통합

 

<운영 우수성>

• 코드로 운영 수행 (ex. AWS CloudFormation)
• 예기치 않은 이벤트에 대한 대응 테스트

 

<지속 가능성>

• 관리형 서비스 사용 : 관리형 서비스를 통해 자주 사용하지 않는 데이터 및 리소스를 줄여 지속가능성 추구
• 사용률 극대화 : 유휴 리소스를 최소화하도록 워크로드 크기를 조정
• 영향 이해 : 실제 비즈니스 연계된 성과 지표를 지속 가능성 측면에서 설정하고 개선사항을 평가하며 시간에 따라 영향도 변화를 추정