Cloud Basic Service

 

국민대학교에서 "클라우드 컴퓨팅" 교과목을 진행하시는
이경용 교수님의 강의 교안을 이용하여 수업 내용을 정리하였습니다

 

 

 

 Cloud Infrastructure

 

하나의 데이터센터에는 일반적으로 수천대의 서버가 장착되어 있음

 

rack을 이루는 하나하나가 server임

 

데이터 센터 내에 서버는 랙으로 구성됨

 

=> 같은 랙에서는 싱글 네트워크 스위치를 통해서 연결

 

=> 여러 랙은 고성능 네트워크 스위치로 연결

 

AWS Infrastructure - Region & Availability Zone (AZ)

 

Region

 

물리적 지리적 위치를 기준으로 구성된 자원 세트

(미국 서부, 미국 동부, 아시아 서울, 아시아 일본 지역 등..)

 

하나의 Region은 최소 2개 이상의 Availability Zone으로 구성됨

 

Availability Zone

 

하나 또는 그 이상의 데이터 센터로 구성되어 있음

 

• AZ 간에는 실패가 전파되지 않음
  
  => 어느 한 AZ에서 문제가 발생해도 다른 AZ는 상관 없게 함 즉, 여러 AZ를 거쳐 개발하면 안정성이 올라감
  
  
• AZ 내부는 초고속 네트워크로 연결되어 있으며, AZ 내부 통신은 AZ 간 통신, Region 간 통신보다 빠름을 가정함

 

AWS Region 이름 부여 규칙은 '지역코드-방위-번호-AZ 알파벳' 임

(2023년 5월 기준 31개의 리전, 102개의 AZ)

 

ex. 'us-west-2' , 'ap-northeast-2'

 

 

Azure도 AWS와 유사하게 Region과 Availability Zone으로 구분하여 고가용성 서비스 제공

GCP의 경우 Region 개념을 사용하는데 Availability Zone은 Zones로 명칭

 

 

Amazon EC2

 

필요에 따라서 사용자는 활용하고자 하는 컴퓨터 특성에 따라서 인스턴스를 선택 함

 

특징을 살펴보면

 

1. 사용하는 만큼 과금 됨

 

• 아무런 작업을 하지 않고 인스턴스를 켜두기만 해도 과금 됨
  
  
• CPU 활용 % 에 따라서 과금이 되지는 않음
  
  

2. 다양한 하드웨어 특성 및 운영체제의 선택 가능

 

• Amazon Machine Image (AMI)
  
  
  • 운영체제 및 소프트웨어가 설치된 이미지 
    
    
  • AMI로 부터 EC2 인스턴스가 시작 됨 (가상화 기술을 이용)
    
    

컴퓨터 사용량이 필요하면 인스턴스를 추가하고, 필요없으면 언제든지 인스턴스 삭제 가능

 

 

EC2 활용시 구성 요소들

 

AMI (Amazon Machine Image)

 

• AWS에서 인스턴스 (서버) 구동을 위한 템플릿
  
  
• 윈도우, 리눅스 운영체제 포함 (mac 가능)
  
  
• 사용자가 임의의 AMI 생성 가능
  
  
• Quick start (AWS에서 제공해주는 기초 운영체제 포함)
  
  
• My AMIs (사용자 생성 AMI)
  
  
• AWS Marketplace (AWS 이외 다른 업체들이 본인 서비스를 잘 사용하게끔 만들어서 제공하는 AMI)
  
  
• Community AMIs (사용자 간에 공유하는 AMI)
  
  

인스턴스 타입

 

사용자가 원하는 하드웨어 특성을 활용 가능하도록 설정해둔 세트

 

=> 메모리, CPU, 파일 저장소, 네트워크 성능등의 설정이 가능함

 

인스턴스 타입의 큰 카테고리 (타입이 수백 종류가 있기 때문)

 

• General
  
  
• Compute-optimized
  
  
• Memory-optimized
  
  
• Storage-optimaized
  
  
• Accelerated compting
  
  

인스턴스 타입, 지역별로 가격이 다를 수 있음

 

 

보통 이름은 어떤 타입인지 나타내는 Family, 높을수록 최신 버전을 타나태는 generation, 커질수록 메모리, cpu 도 비례해서 증가하는 size로 구성됨

ex. t2.micro 와 같이 표현

 

 

AWS EC2 가격 옵션

 

 

• On-demand
  
  • 사용하는 양 만큼 과금 됨 (운영체제에 따라 초당 과금 or 시간당 과금)
  • 인스턴스 타입 마다 가격이 다름 (지역마다도 다름)
    
    
• Reserved instance
  • 장기적으로 사용함을 기준으로 할인 받음 (탄력적으로 서버 사용 X => 서버 개수가 유지되는 경우 선납금
    
    
  • 선납금을 먼저 내는 기간에 따라서 할인 액수가 다름
    
    
• Spot instance
  
  • 남아도는 자원을 싼 가격에 활용 (특정 지역, 특정 시간에 서버가 남아돌면 싸게 제공해줌)
    
    
  • 사용중인 자원은 언제든지 종료될 수 있음
    (사람이 몰리면 on-demand에 자원 배정을 위해 종료시킴 => 경매 방식이라 수요 높아져서 사용자가 설정한 최대가격 넘어서면 종료)
    
    
• Reserved Host(Instance) 
  
  • 호스트 기기를 다른 사용자와 공유하지 않음 
  • 라이센스 관련 규정 및 규제 만족 (oracle 같이 라이센스 이슈로 사용 제약이 있는 경우 사용)
  • HW를 독점적으로 사용하기 때문에 가격이 비쌈

Reserved Host가 비싼 이유

 

네트워크 세팅

• VPC 설정
• Public IP 할당 여부 선택
  
  

IAM Role

• 실행될 인스턴스가 다른 AWS 자원을 접근시에 가지는 권한을 정의
  
  (EC2 쓴다고 서버의 메모리 같은 것만 쓰는게 아니라 다른 cloud 서비스를 사용하기 때문)
  
  
• Role에 attach된 policy가 접근 권한을 설정
  
  
• 인스턴스가 시작한 후에도 설정 가능

 

User data

 

 

인스턴스가 시작할 때 실행하는 명령어를 지정하게 해줌

 

인스턴스가 시작할 때라는 의미는 재부팅이나 중지 후 다시 시작할 때가 아니라 완전 새롭게 시작할 때를 의미함

 

사용 예 : 인스턴스마다 실행할 명령어가 다를 경우 (ex. 파리미터 전달 등), 별도의 AMI 로 만들기보다 하나의 AMI를 만들고 user data를 통해서 인자 전달이 가능함

 

Storage 옵션

• Root 볼륨 (부팅이 진행되는) 의 사이즈 지정이 가능 - 부팅 디스크
  
  
• 추가적인 디스크 장착 가능 (attach 가능)
  
  
• 암호화 설정 가능
  
  
• 볼륨 크기, SSD, HDD 등을 지정 가능
  
  
• EBS 또는 인스턴스 로컬 스토리지 설정 가능 

인스턴스 안에 스토리지가 있는 것이 인스턴스 로컬 스토리지이고 따로 스토리지가 없을 수 도 있는데 그것이 EBS임

 

 

인스턴스 로컬 스토리지의 경우 일부 인스턴스 타입에서만 지원함 (storage-optimized)

인스턴스 로컬 스토리지 vs EBS

 

인스턴스 로컬 스토리지 볼륨은 데이터 영속성이 없음 (reboot 에서만 지속)

 

 

클라우드 벤더들은 HW1에 원래 있던 인스턴스가 빠지고 자리가 나면 또 다른 인스턴스를 올릴 수 도 있음

 

=> 이 말은 인스턴스를 껐다가 다시 키면 다른 HW에서 작동한다는 말 (데이터가 날라감)

 

Key Pair

• 인스턴스에 SSH로 접근하기 위한 비대칭 키 지정
  
  
• Public, Private 키로 구성 됨
  
  (암호화할 때는 Public key로 누구든 가능하지만 복호화할 때는 Private key를 이용하는 비대칭 키 암호화)
  
  
• RSA 키를 활용한 접근

 

EC2 페이지에서 KeyPair 생성 가능함

 

=> 사용자의 RSA 키를 EC2 페이지에서 KeyPair로 import 가능

 

하지만, 사용자 KeyPair로 EBS encryption이 불가능하고 KMS를 통해서 EC2 KeyPair 생성이 불가능함

 

KMS (Key Management Service)는 AWS에서 암호화 키를 생성하고 관리하는 서비로 EBS 암호화, S3 객체 암호화, 데이터 암호화 등에 사용됨

=> 로그인용 EC2 KeyPair (SSH 키 쌍)를 생성하는 데는 사용되지 X

 

EC2 인스턴스 수명주기

 

AMI를 이용하여 EC2가 시작되면 대기중에 머물다가 실행중으로 바뀌게 됨 (이 때 부터 동작중으로 판단하고 과금)

 

이 때 재부팅, 중지, 종료로 나아갈 수 있음

 

재부팅을 하게 되면 재부팅중이었다가 다시 실행중 상태로 바뀜

 

종료(terminate)를 하게 되면 CPU, RAM, DISK가 다 날라가고 종료중 상태를 거쳐 종료됨으로 바뀜

(더 이상 과금 X)

=> Delete on termination이 설정되어 있지 않으면 EBS 볼륨은 삭제되지 않고 유지됨

 

중지(최대 절전 모드)를 하게 되면 중지중을 거쳐 중지됨으로 바뀜

(인스턴스 과금은 일어나지 않고, EBS사용하므로 DISK는 남아있음)

=> Storage 과금은 발생함!

 

EC2 인스턴스 최대 절전 모드

 

EC2 인스턴스의 구동을 멈추는 방법에는 Stop(중지) 와 Shutdown (종료)이 있음

=> 둘다 메모리에 있는 내용은 유실 됨 (휘발성)

 

최대절전모드

 

 

• 인스턴스내의 메모리 (RAM)에 저장된 내용을 저장 가능
  
  
• 메모리 내용 및 프로세스 재시작 가능
  
  
• Amazon Linux2 및 특정 인스턴스만 지원
  
  
• 암호화된 EBS 루트 볼륨 사용 및 150GB RAM까지 가능 (dump가 가능)
  
  => RAM 내용을 EBS 루트 볼륨에 dump
  
  
• 인스턴스 시작시 최대절전모드 활성화 필요

 

EC2 인스턴스의 메타데이터 확인

 

EC2 메타데이터

 

• 현재 구동 중인 인스턴스의 다양한 정보를 제공
  
  
• 동작 중인 EC2 인스턴스에 접속하여 (SSH) 쉘을 통해서 정보 획득 가능
  
  
• 정보 획득 시 보안 기능 제공
  (메타데이터는 EC2 인스턴스 내부에서만 접근 가능)

쉘에서 curl http://169.254.169.254/latest/meta-data/~ 를 하면 되는데

curl http://169.254.169.254/latest/meta-data/ami-id 처럼 curl 요청을 보내면 해당 인스턴스의 AMI ID가 출력됨

curl 명령어는 HTTP 요청을 보내는 도구인데 ping 과 비슷한 점이 있지만, ping은 ICMP 프로토콜을 사용해 네트워크 연결 상태를 확인하는 데 사용되고, curl은 HTTP 요청을 보내고 응답을 받는 데 사용됨

제공되는 정보들로는 퍼블릭 IP 주소, 프라이빗 IP 주소, 퍼블릭 호스트 이름, 인스턴스 ID, 보안 그룹, 리전, 가용 영역 등이 있음

 

EC2 인스턴스로의 접근 제어

 

Security Group

 

• 포트 기준으로 해당 인스턴스에 접근 가능 여부 지정
  
  
• 인스턴스당 inbound/outbound 트래픽의 방화벽 역할 담당
  
  
• 기본적으로 모든 inbound 트래픽을 허용하지 않음
  
  
• 기본적으로 모든 outbound 트래픽은 허용 됨
  
  
• 주요 서비스 (SSH, HTTP 등) 별로 필요한 서비스를 별도로 허용
  
  
• Incoming 요청의 경우 CIDR로 표현된 특정 소스 기기로 부터의 접근 허용 가능

 

 

 

=> 인스턴스에서 나가는건 (outbound) 기본적으로 모두 허용, 들어오는건 (inbound)는 직접 설정해줘야함!

 

Azure Virtual Machines

 

AWS EC2에 대응되는 컴퓨팅 서비스

 

=> Azure VM이라고 부름

 

Azure VM 인스턴스 타입

 

Azure VM의 인스턴스 타입은 EC2의 인스턴스 타입과 유사하고

 

이름의 경우 Family, size(vCPU 수), 추가기능, 세대로 구성됨

 

=> ex. D2as v5
(as가 추가기능 notation)

 

Azure VM 가격 옵션

 

EC2의 가격 옵션과 비슷하지만 Reserved Host가 없고 Savings Plan이라는 옵션이 있음

 

이 Savings Plan은 1년 또는 3년동안 고정된 시간당 금액을 약정, 할인된 가격을 제공해줌

=> Pay as you go ( = aws on-demand)에 비해 최대 65% 할인

Reserved instance는 예를 들어, 특정 VM 유형, 리전, 운영 체제 등을 예약하고, 그에 맞는 요금을 미리 지불한다고 하면

Savings Plan은 리소스를 고정하지 않고 유연하게 사용할 수 있는 요금제로 1년 또는 3년 동안 시간당 금액을 고정하여 할인된 요금을 제공함

=> 예약한 금액 내에서 다양한 리소스를 유연하게 사용할 수 있음

 

네트워크 세팅은 AWS 와 동일하고

Resource Group IAM <-> AWS IAM ROLE

 

Cloud-init <-> AWS user data

(cloud-init 명령어는 암호화 되지 않음)

 

Key-Pair <-> AWS Key-Pair

각각 이렇게 대응됨

 

Azure VM 수명 주기

 

EC2와 유사함

 

 

Stopping과 Deallocating의 차이

 

Stopping : OS 등 모든 프로세스는 종료되었지만 리소스를 사용하고 있는 상태 (스토리지 관점에서 과금 O)

 

Deallocated : 모든 리소스를 Azure에 반환하여 과금 X

 

 

GCP Compute Engine

 

GCP VM 인스턴스 타입

 

다른 클라우드 벤더와 다르게 사용자가 CPU 코어나 메모리 사이즈를 커스텀하게 만들 수 있음!

 

이름은 Family, 세대, 유형, size(vCPU수) 로 구성됨

 

 

 

유형은 standard, highmem, highcpu 등이 올 수 있고

 

커스텀 머신 유형이 있음

 

• 기존 VM이 요구사항을 충족하지 못할 경우 사용
  
  
• 사용자가 vCPU, 메모리를 선택하여 인스턴스 생성
  
  
• 설정된 vCPU, 메모리에 따라 과금

GCP는 Storage 계열이 X => Storage-optimized 존재 X

 

GCP VM 가격 옵션

 

AWS와 유사하지만

 

지속 사용할인 이라는 옵션이 있음 

 

이는 별도의 정책을 사용하지 않고 VM을 오랫동안 사용하면 자동적으로 최대 30%를 할인해줌

(1달에 25% 이상 지속 사용하면 할인)

=> 다른 벤더와 다르게 약정이 없고 그냥 오래 안끄고 켜두면 할인

 

또한, 약정 사용 할인이라고해서 VM 타입 (ex. n1-standard-1) 이 아닌 vCPU 코어와 메모리 수와 같은 리소스를 Region 단위로 약정 구매
(1년 혹은 3년 약정 구매하여 할인)

 

=> 다른 벤더와 다르게 커스텀 마이징이 가능하기 때문

 

GCP VM 구성요소

 

 

Startup Script <-> AWS user data 에 대응

 

IAM을 통해 VM 접근 제어 (웹페이지에서 사용자의 엑세스를 제어 가능)

=> SSH키는 수동으로 생성 가능하고 수동 생성 안할 시 자동으로 생성

 

GCP VM 수명주기

 

 

SUSPENDING과 TERMINATED를 잘 구분하면 됨

 

Amazon Elastic Block Storage (EBS)

 

파일 저장소 서비스이며, 각 EBS는 EC2 인스턴스에 장착 (attach) 이 가능함!

 

• Block 단위 저장 서비스
  
  => Object 저장소는 전체 파일 단위로 작업이 되지만 Block 저장소는 전체 파일중 일부만을 업데이트 및 저장 가능!
  
  
• 하나의 AZ 내에서 복제되어 있음
  (어느 정도의 안정성 확보)
  
  
• 네트워크를 통해서 EC2와 연결
  
  
• EC2 내 로컬 저장소 아님

 

EC2 인스턴스의 부트 볼륨(SSD, HDD)이나 데이터 저장 서비스로 사용됨

 

일반적인 디스크가 로컬에 읽고 쓸 때 100~200 MB/sec 인데 EBS의 Network 통신이 이 정도는 넘기 때문에 네트워크로 연결해서 쓰던 로컬 스토리지에 있던 크게 성능 차이 X

 

인스턴스 로컬은 자원의 활용도가 적고 요새는 네트워크로 통신하더라도 거의 비슷한 성능이라면 무조건 EBS?

 

 

고성능 스토리지 기능을 쓰고 싶으면 로컬을 지원

 

=> 네트워크가 스토리지 대역폭을 못따라가는 경우

 

EBS 볼륨 타입

 

EBS 지원 기능 

결국 DISK임..

 

스냅샷

• 특정 시점의 파일을 기준으로 생성 가능 (부팅 가능)
  
  => 스냅샷을 기반으로 새로운 EBS 볼륨을 생성한 후, 그 볼륨을 EC2 인스턴스의 부트 볼륨으로 사용할 수 있다는 의미
  
  
• 스냅샷으로 부터 새로운 볼륨 생성 및 EC2 인스턴스에 장착 가능
  
  
• 스냅샷을 생성한 볼륨 용량에 따른 과금 발생

 

암호화

• 추가 요금 없이 암호화 지원
  
  
• 암호화/복호화에 대한 부담은 무시할 정도라고 광고 (오버헤드가 없다는 말)

탄력성

• 용량 증가 가능
  
  
• 다른 유형으로 변경 가능 (스냅샷 생성 -> 볼륨 생성 시 원하는 타입 SSD/HDD 선택)

 

예를 들어, 원래는 General Purpose SSD (gp3)를 사용했지만, 스냅샷을 기반으로 새로 생성하는 볼륨은 Provisioned IOPS SSD (io2)와 같은 더 높은 성능의 볼륨으로 변경할 수 있음

 

Azure Managed Disk & GCP Persistent Disk

 

파일 저장소 서비스로 인스턴스에 장착 (attach) 이 가능함

=> Block 단위 저장 서비스임

 

Amazon Simple Storage Service (S3)

 

Fully-managed object 저장 서비스로 확장성이 보장되며 파일의 안정성을 99.999999999% 보장

 

• 블락 단위가 아닌 오브젝트 단위로 저장 (EBS와 차이) 
  
  => 파일 그 자체를 저장
  
  
• 버킷을 생성하며, 버킷은 전세계 모든 AWS 지역에서 unique 해야 함
  
  
• EC2의 부팅 볼륨으로는 활용될 수 없음 
  
  => 이 때는 EBS를 활용해야함 (데이터로만 사용 가능)
  
  
• 데이터 복제는 AWS가 관리함
  
  
• AWS console, CLI, SDK (소프트웨어 개발 키트) 를 통해서 접근 가능
  
  
• 오브젝트의 상태변화 (create, delete, update) 는 이벤트를 발생 시킬 수 있음

 

S3 스토리지 클래스

 

객체의 저장 기간 및 복제 정도에 따라서 다양한 레벨로 설정 가능
(각 레벨간 가격차이가 있음)

 

• Amazon S3 Standard
  
  
• Amazon S3 Intelligent - Tiering
  
  (접근 안하는 애들은 접근 속도가 낮은 대신 비용이 적음 - 클라우드 벤더가 결정함)
  
  
• Amazon S3 Standard-Infrequent Access
  
  (Intelligent와 동일한데 사용자가 결정할 수 있음)
  
  
• Amazon S3 One Zone-Infrequent Access
  
  (유실, 접근 속도는 상관없으니 비용을 낮게)
  
  
• Amazon S3 Glacier
  
  (보안 용도 - 아카이빙)
  
  => 대학 신입생 입시 서류처럼 저장만 하는 용도로 접근 속도 낮고 비용도 낮게 설정
  
  

Amazon S3 활용법

 

오브젝트를 업로드 하기 위해서는 버킷을 생성해야함 
(메인 AWS Region은 선택 해야함)

=> 생성된 버킷에 오브젝트 업로드

 

버킷 : https://s3-ap-northeast-1.amazonaws.com/[bucket name]/

 

Region 코드 또는 글로벌 주소를 적어주면되고 bucket name도 적어줘야함

 

오브젝트 :  https://s3-ap-northeast-1.amazonaws.com/[bucket name]/ Preview2.mp4

=> Key 값으로 오브젝트 파일명을 적어주면 접근 가능

 

bucket name은 위에서 말했듯이 전세계 모든 AWS 지역에서 unique하지만 누군가 삭제하면 재사용이 가능함!

 

Amazon S3 특징들

 

저장된 오브젝트는 HTTP로 접근 가능함 (퍼블릭하게 설정 가능)

 

주요 사용 예제로는

 

• 어플리케이션에서 사용하는 정적 파일들
  
  
• 정적 웹페이지 호스팅 (html)
  
  
• 데이터 백업 (가장 저렴한 파일 저장법)
  
  
• Data lake (빅데이터 분석을 위한 스테이징)

 

가 있고

 

가격 모델을 살펴보면

 

• 오브젝트의 저장된 크기
  
  
• 다른 지역으로 파일이 나가는 경우 transfer 비용 발생
  
  
• PUT, COPY, POST, LIST, GET 요청 횟수
  
  
• S3로 업로드, 같은 Region 내에서 파일 전송, CloudFront 로의 전송은 무료
  
  

에 따라 가격이 책정됨

 

Amazon S3 Glacier

 

데이터 아카이빙 (보존) 서비스

=> 뛰어난 내구성 (안정성) 보장

 

매우 저렴한 비용으로 장기간 파일 보존에 적합함

=> 검색 시간은 수분에서 수시간 소요됨

 

수명 주기 정책 설정 가능

 

 

=> S3 객체의 생성 시간에 따른 자동 아카이빙 가능

 

 

Azure Blob Storage

 

AWS S3에 대응되는 객체 스토리지 서비스

(비정형 데이터를 저장)

 

 

Google Cloud Storage

 

AWS S3에 대응되는 객체 스토리지 서비스

(양에 상관없이 데이터를 저장하고 원할 때마다 검색할 수 있음)

=> AWS와 유사하나 가격적인 측면에서 유리

 

Relational Database (RDS)

 

클라우드에서 관계형 데이터베이스를 구성하고 운영해주는 관리형 데이터베이스 서비스

 

기존 관계형 데이터베이스 구성의 문제점으로는

 

• 서버 유지 관리 필요
  
  
• 소프트웨어 업데이트 및 보안 패치 적용
  
  
• 데이터베이스 백업 및 고가용성 보장
  
  
• 확장성 제안
  
  
• OS 설치 및 업데이트

가 있다!

 

관계형 데이터베이스 활용의 장점

 

 

 

 

=> 온프레미스 환경에 비해 개발자가 신경써야할 부분이 줄어듬

 

Amazon RDS 인스턴스

 

 

RDS는 DB 엔진 (MySQL, PostgreSQL, MariaDB ...)을 서버 위에 얹어서 쓸 수 있게 관리해줌
(데이터베이스 관리)

 

실제로 데이터베이스가 동작하는 서버 인스턴스는 EC2 위에서 동작
=> CPU, 메모리, 네트워크 성능등은 EC2 인스턴스 클래스를 따라감

 

RDS의 DB 인스턴스는 데이터를 저장하기 위해 EBS 볼륨을 사용함

=> 이 스토리지의 크기와 성능(예: SSD, 마그네틱 디스크, 프로비저닝된 IOPS 등)을 선택할 수 있음

 

Amazon Aurora DB

 

Cloud-native 데이터베이스
(cloud 내에서만 구동 가능한 DB)

 

 

• MySQL, PostgreSQL 과 호환성 제공
  
  
• RDS의 모든 장점 상속
  
  
• 클라우드 서비스를 활용한 고가용성 확보
  
  => 다중 AZ에 복사본을 두고 이를 S3에서 백업해둠
  (cloud-native라 이렇게 더 높은 안정성, 확장성이 가능함)

 

클라우드에서의 보안 - IAM

 

AWS Identity and Access Management (IAM)

 

• AWS에서 사용자 및 자원에 대한 Authentication(인증) 과 Authorization(권한 체크) 실행

클라우드 자원에 대해서 아주 세부적인 접근 권한 설정을 가능하게 해줌

 

• 누가 자원에 접근할 수 있는가
  
  
• 어떤 자원이 다른 서비스에 접근할 수 있는가
  
  
• 자원들은 어떤 방식으로 접근 할 수 있는가

=> ex. EC2 자원을 종료하는 것은 A라는 사용자만 가능하게 

 

과금은 따로 없음

 

IAM 핵심 요소

 

 

User : AWS로 authentication을 수행할 사용자 또는 응용 프로그램

 

Group : IAM user의 집합체로 Group 내에서는 같은 권한을 부여 받음

 

Policy : 특정 자원이 다른 어떤 자원을 접근할 수 있는지 정의

 

=> 접근하는 정도를 정의

Role :  AWS 자원간 또는 사용자간 permission을 부여할 때 활용

 

Policy는 무엇을 할 수 있는지(권한) 정의하고, Role은 누구에게 이 권한을 줄지(권한을 부여받는 대상)를 나타냄!

 

AWS IAM User 활용

 

 

 

AWS Management 콘솔 접근

 

• 12 자리 account ID 또는 Alias
• IAM user name
• IAM password로 접근

Multi-Factor Authentication (MFA)

 

• 강화된 로그인 보안 실현 가능
• IAM Username, password 이외에 authentication code 가 필요

 

IAM User를 통한 인증

 

IAM User를 활용하여 사용자를 생성할 경우 접근 방식을 정할 수 있음

 

Programmatic access

 

=> 프로그램 또는 코드를 활용하여 접근을 가능하게함

 

=> Access key ID와 Secret access key로 구성

 

 

 

=> AWS CLI (Command Line interface) : 리눅스 쉘을 통해서 접근

 

SDK로 코드 상에서 사용

=> AWS SDK (Software Development Kit) : 프로그래밍 언어를 활용해서 접근

 

Authorization & Authentication

 

 

Authentication은 인증을 Authorization은 어떤 작업을 할 수 있는지를 정의함

 

IAM Policy를 이용한 Authorization

 

IAM Policy는 세부 자원 및 사용자의 접근 권한 제어를 표현할 수 있음

 

=> 어떤 자원이 어떤 연산을 할 수 있는지 정의함

 

• 모든 연산들은 묵시적으로 모두 거절됨
  
  
• 허용하고 싶은 연산은 명시적으로 허용해줘야함
  
  
• 특정 연산이 명시적으로 거절 되어있다면 절대로 허용될 수 X

=> 최소한의 접근을 가능하게 하는 것이 중요함

 

IAM Policy 세부 사항

 

 

IAM Policy는 접근 제어 권한을 정의하는 문서임!

 

=> 세부적인 접근 제어 표현을 가능하게해줌

 

두 가지 종류가 있음

 

• Identity-based policy
  
  
  • Policy를 IAM entity (User, group, role)에게 할당
    
    
  • Entity가 수행 가능한 actions를 정의
    
    
  • Entity가 수행 할 수 없는 action을 정의
    
    
  • 하나의 policy가 여러 entity에 정의 가능 (재활용이 가능함)
    
    
  • 하나의 entity가 여러개의 policy를 가질 수 있음
• Resource-based policy
  
  
  • 자원 자체에 정의되는 policy (예 : AWS S3 bucket)
    
    => S3에 접근할 수 있는지 없는지를 정의해놓음

 

IAM Policy 구성 요소들

 

JSON 형태로 표현되며 Principal이 Resource에 Action을 행하는 것이 허용되는지 거절 되는지 Effect 값이 결정

 

Version : Policy 언어의 버전 표시 (최신 : 2012-10-17)

 

Statement : Policy element 들의 집합체

(여러개의 statement가 포함됨)

 

Sid : StatementID (optional - 도움말)

Effect : Allow 또는 Deny

Principal : 사용자 ID, user, role 등이 포함 되며, Allow 또는 Deny가 적용될 개체

 

Action : Policy가 적용될 명령어 정의 (list로 표현됨)

Resource : policy가 적용될 AWS 자원들에 대한 정의 (EC2 서버, RDS, S3 bucket, ...)

 

Condition : policy가 적용될 조건을 정의 (optional)

 

Resource-based Policy

 

 

Identity-based policy와 달리 resource-based policy는 자원 (resource)에 할당됨

 

=> Identity : user, group, role 등

 

Resource-based policy의 특성

 

• 특정 리소스를 접근 할 수 있는 사용자가 누구이고 어떤 action을 할 수 있는지 정의
• 특정 AWS 서비스에서만 사용가능 (S3)

 

IAM 에서 접근 제어

 

 

IAM 에서 접근 제어가 되는 순서

 

 

IAM Groups

 

IAM Group은 IAM users들의 집합체

 

IAM Group을 통해서 여러 user들에게 같은 permission을 부여 가능

 

=> Permission 부여는 policy를 부여하는 방식으로 진행됨
(해당 그룹의 모든 user가 policy 적용)

 

하나의 User는 여러 group에 소속 가능하고 Default Group은 없음
(Nested group도 지원하지 않음 => group 안에 group은 X)

 

IAM Roles

 

IAM Role은 permission(policy)을 가지는 IAM identity임

 

IAM user와 유사한점

• Permission policy를 attach 할 수 있음

IAM user와 다른점

• 특정 사용자 또는 한명의 사용자와 연계 되지 않음
  
  
• 사용자 응용서비스 등에 부착 가능 (Assume 이라는 명칭 사용)
  
  
• Role을 통해서 임시적인 권한 부여 가능

 

 

=> 같은 AWS Account 내에 다른 IAM user 간에 role을 사용

 

 

=> AWS Service가 role에 정의된 permission 사용

(User는 바로 policy를 가져갈 수 있는데 서비스는 그럴 수 X => role에 할당!)

 

 

=> 서로 다른 AWS Account의 IAM user 간에도 사용 가능

 

 

IAM Role 을 사용한 응용 예제

 

 

 

EC2 인스턴스에서 동작중인 응용 프로그램이 S3 버킷을 접근할 필요가 있음

 

1. S3 버킷에 접근 권한을 부여하는 policy를 생성

2. 해당 policy를 role에 attach 

 

3. EC2 인스턴스가 해당 role을 assume

 

순서를 따라감

 

AWS 에서 Root 계정으로 로그인

 

AWS의 루트 계정으로 로그인 가능함

 

• 루트 계정 : 최초 가입한 이메일 주소와 비밀번호
  
  => 사용하지 않는 것이 좋음
  
  

AWS 루트 계정으로만 실행 가능 한 action

 

• 루트 계정의 비밀번호 변경
  
  
• AWS Support plan 변경
  
  
• Account 설정 변경 (contact info, 허용 region 등)
  
  

AWS 에서 올바른 계정 관리

 

계정을 처음 만든 후 필요한 첫 단계

 

• IAM 계정을 만들어서 Administrator Access Policy를 해당 계정에 부여해줌
  
  => 전체 접근 가능 (*)
  
  
• Root 계정으로 logout 후 IAM 계정으로 로그인
  
  

Multi-Factor Authentication (MFA 사용)

• 루트 계정과 IAM User 모두 MFA 사용이 추천됨
  
  
• 소프트웨어 기반 MFA 토큰 발생 (Google Authenticator - virtual) , 하드웨어 기반 MFA 기기 사용 가능

 

Azure에서의 보안 - ADD, IAM

 

Azure Active Directory (Entra ID)

 

=> 클라우드 기반의 ID 및 엑세스 관리 서비스

 

(Azure AD는 사용자, 클라우드 리소스에 대한 ID를 인증하고 권한을 부여하는데 사용)

 

Azure Resource Groups IAM

 

=> Azure Resource Manager (ARM)은 리소스 그룹에 대한 엑세스 권한을 관리하는데 사용

 

(IAM을 사용하면 사용자, 그룹 또는 서비스 주체에 대한 리소스 그룹에 대한 엑세스 권한을 부여)

 

Azure Active Directory (AD)

 

Azure Active Directory (AD) 는 AWS IAM User, Group에 대응

 

=> 사용자 생성, 사용자 권한 생성

 

(기본 모델은 무료이나 과금 모델도 있음)

 

Azure Active Directory Group

 

동일한 엑세스 및 권한이 필요한 사용자를 관리하는데 사용

 

=> AD IAM Group을 통해서 같은 역할을 하는 user에게 같은 permission을 부여가능

(Permission 부여는 Policy를 부여하는 방식으로 진행됨)

 

Azure Resource Groups IAM

 

 

 

Azure Resource Groups IAM 은 AWS IAM Role에 대응

 

=> Resource Group 기반 접근 제어 서비스

(같은 리소스 그룹 내 어떤 자원이 다른 서비스에 접근할 수 있는가 / 자원들은 어떤 방식으로 접근할 수 있는가)

 

과금은 따로 없음

 

Google Cloud IAM 작동 방식

 

Google Cloud Identity and Access Management (IAM)은 AWS IAM에 대응

 

IAM의 Permission은 사용자에게 직접 부여하지 않고 권한이 역할로 그룹화, 역할은 인증된 Principals(구성원)에게 부여된다!

 

과금은 따로 없음

 

AWS Organization

 

nested group은 존재하지 않았는데 OU는 가능

 

 

AWS 계정을 여러 그룹으로 나누어서 관리하게해줌

 

하나의 Root 계정, 다수의 AWS Account들, 그룹을 표현하는 Organization Unit (OU)로 구성
(일종이 Group 개념)

 

Root 계정에서 통합 billing을 지원해줌

 

=> 큰 기업에서는 각 부서마다 다른 AWS 계정을 사용할 수 있는데 이런 계정들을 한 조직(Organization)으로 묶고, 마스터 계정을 통해 전체 계정을 통제할 수 있음

 

IAM 계정 간에는 자원공유가 되는 경우가 많지만, Organization 내 다른 계정간에는 명시적 공유가 필요함!

 

=> OU 단에서 Policy를 attach하여 각 계정에서 접근 할 수 있는 권한 명시 가능

 

사용자간에 얼마나 독립적이여야하는가를 생각해야함

=> IAM user의 경우 접근은 못하더라도 내용을 볼 수는 있지만 Organization은 완전 독립!

 

Azure Management Groups

 

Azure Management Groups는 AWS의 Organization에 대응됨

 

Tenant 라는 AWS에서의 Root가 있고 하위 계층인 Subscription을 그룹화하여 같은 역할에 대한 엑세스 정책 등을 관리함!

 

각각

 

Management Groups <-> AWS OU

 

Subscriptions <-> AWS User

 

Resource Groups : 리소스를 하나의 그룹으로 관리하기위한 논리적 묶음
(리소스는 하나의 리소스 그룹에 속해있음)

 

Resources : 가상머신, 스토리지 등 Azure 서비스

 

로 구성됨

 

Google Cloud Organization

 

Google Cloud의 AWS Organization에 대응되는 개념임

 

각각

 

Organization <-> AWS Root

 

Folders <-> AWS OU

 

Projects : 리소스 분리를 위한 계층

 

Resources : 가상머신, 스토리지, App Engine 등 GCP 서비스