[0516 복습] 클라우드 서비스_AWS 보안정책, 서브넷, 컴퓨팅 서비스, EC2

클라우드 서비스 2일차 

보안 정책

IAM 정책

자격증명 기반 정책	- 사용자, 그룹 또는 역할 등에 적용해 특정 주체가 리소스에 접근하여 수행할 수 있는 권한을 지정 - 예를 들어, 특정 IAM 사용자에게 EC2 인스턴스에 접근해 모든 작업을 수행하도록 허용하는 정책을 정의 (접근을 하기 위한)
	AWS 관리형 정책	- AWS에서 사전에 생성해놓은 정책으로 서비스별 액세스, 직무별로 선택할 수 있음 - 예를 들어 AmazonS3FullAccess, AmazonEC2ReadOnlyAccess 등 미리 정해진 정책을 선택해 손쉽게 권한을 할당할 수 있음 (모든 사용자에게 적용)
	고객 관리형 정책	- 고객이 목적에 맞게 직접 생성 및 관리하는 정책 - AWS 관리형 정책을 바탕으로 생성하는 것이 가장 쉽고 좋은 방법임 (모든 사용자에게 적용)
	인라인 정책	- 특정 주체(사용자, 그룹, Role)에게만 적용하기 위한 정책 - 다른 주체에 공유가 불가능하여 인라인 정책보다는 관리형 정책 사용을 권장
리소스 기반 정책	- 리소스에 정책을 적용해 액세스할 수 있는 주체 및 리소스에 수행할 수 있는 작업을 지정 - 리소스 기반 정책을 활용할 수 있는 일반적인 사례는 S3 버킷 정책으로 정책에 지정된 주체에 권한을 부여 (접근을 받기 위한)

 

 

 

IAM 정책 구조

- 권한 허용 결정을 위해 IAM은 먼저 명시적 거부 정책을 확인하고 명시적 거부 정책이 없는 경우 다음으로 명시적 허용 정책을 확인

- 명시적 거부나 명시적 허용 정책이 둘다 없는 경우 기본 설정인 암시적 거부를 통해 최종적으로 거부

- 거부 규칙을 먼저하는 이유? 직원의 실수로 권한이 허용되었을 때 보안정책 위반을 규제하기 위해서!

 

 

IAM 권한 경계

 

- IAM 권한 경계(Permission boundary)는 권한을 부여하는 목적이 아닌 사용자 권한을 제한하는 목적으로 사용

- 조직 내 보안 정책 범위를 벗어난 잘못된 정책 적용 시 필터링 역할을 할 수 있음

 

 

 

 

네트워킹 서비스_Amazon VPC

리전 및 가용 영역

가용 영역(Availability Zone)	리전(Region)
- 데이터 센터는 수만개의 서버를 운영 중이고 모든 데이터 센터는 온라인으로 연결 - 각 가용 영역은 하나 이상의 데이터 센터로 구성되며 내결함성을 갖도록 설계됨 - 전용선을 통해 다른 가용 영역과 상호 연결 - 전용선: 전용망을 구축(인터넷망을 사용하지 않도록)	- 리전은 두 개 이상의 가용 역역으로 구성 (ex. 서울 리전의 경우 현재 4개의 가용영역(AZ)로 구성) - AWS는 전 세계에 다수의 리전과 가용 영역을 보유하고 있으며 계속 확장 중임 - 리전 간 데이터 복제를 활성화하고 제어가능

 

- AWS는 현재 전 세계 33개의 리전, 105개의 가용 영역을 구축

 

 

엣지 로케이션

- 최종 사용자에게 가까운 위치에서 더 짧은 지연 시간으로 콘텐츠를 전송하기 위해 600개 이상의 엣지 로케이션(=Point of Presene)을 구축

- 글로벌 엣지 로케이션을 기반으로 CDN, DNS 등의 서비스를 제공 중임

- 가장 가까운 edge에 콘텐츠 캐싱 저장

 

 

 

VPC 정의

- Virtual Private Cloud, 클라우드의 가상 프라이빗 네트워크 공간 (Private IP로 통신)

- AWS 리소스를 사용자가 정의한 가상 네트워크 안에서 생성하여 활용할 수 있음

 

 

Amazon VPC 특징

- 사용자가 자신의 요구에 맞게 클라우드 상에서 가상의 네트워크를 정의

- VPC는 클라우드 내 다른 가상 네트워크와 논리적으로 분리(격리)되어 있음

- 리소스에 사용할 IP 주소 범위를 지정할 수 있고 IPv4와 IPv6을 모두 지원

- 인바운드 및 아웃바운드 트래픽에 대한 액세스 정책 설정 지원(트래픽 제어, 방화벽 기능)

 

VPC 생성

- VPC를 생성할 리전(Region)을 지정하고 사용할 IP 주소 범위를 지정

- 지정한 리전에 속한 가용 영역(AZ)을 선택해 원하는 개수의 서브넷을 구성

- 리전/계정당 VPC는 최대 5개 생성 (AWS Support center를 통해 Service limit Increase 요청 가능)

 

 

VPC IP 주소 범위 지정

- CIDR(Classless Inter-Domain Routing
: 클래스 없는 도메인 간 라우팅 기법으로 가장 일반적으로 활용되고 있는 IP 주소 할당 및 표기 방법

: 기존의 IP 주소 할당 방식이었던 네트워크 클래스를 대체한 방식

: IP Address의 영역을 나눌 때 기존 방식보다 유연하게 사용자가 원하는 Network Addressdhk Host Address를 나눌 수 있음

 

- 10.0.0.0/24 방식 (32bit 체계, 2의 8승만 IP주소로 사용 가능)

- 위 IP의 경우 .0/24가 호스트 주소를 의미, 그 앞이 네트워크 주소 의미

- VPC 생성 시 Private IP 주소 범위 내에서 활용할 IP 주소 범위를 지정

 

 

- CIDR의 netmask가 커질수록 할당 가능한 IP 주소의 개수는 줄어듦

- AWS VPC는 기본적으로 /28 (16개 IP 주소) 와 /16 (65,563개 IP 주소) 사이에서 네트워크 블록 크기 지정할 수 있음

- VPC 생성 후 CIDR 변경 불가 → 호스트에 할당할 IP 주소 부족하지 않도록 범위 넉넉히 지정

 

 

서브넷 생성

- 서브넷은 리소스 그룹을격리할 수 있는 VPC IP 주소 범위의 하위 집합

- 서브넷 생성시 VPC CIDR 블록의 하위 집합에 속하는 CIDR 블록을 지정

- 서브넷 단위로 네트워크 트래픽을 제어할 수 있음 (인터넷 접근성 제어)

- 가용영역은 최소 2개 이상으로 VPC 환경을 만듦

 

**주의할 점

- VPC 주소 범위 내에서 가용영역을 선택해 생성

- 서브넷 간 CIDR 블록(IP 주소)는 중첩되는 안됨

- 서브넷 별로 5개의 예약된 IP 주소가 있음

- 기 설정된 서브넷 IP 범위는 변경 불가

 

 

라우팅 테이블

- 네트워크 트래픽이 향하는 방향을 결정하는 데 사용되는 경로(규칙 세트)

- VPC 리소스 간에 트래픽을 전송하는 데 필요

- VPC 생성 시 모든 서브넷의 라우팅을 제어하는 기본 라우팅 테이블이 생성됨 (수정/추가 가능, 삭제 불가)

- 서브넷은 기본 라우팅 테이블과 연결되어 있으며 상용자 지정 라우팅 테이블을 적용하고자 할 경우 직접 연결 필요

- 대개 사용자 정의 라우팅 테이블을 생성하여 활용

 

 

인터넷 게이트웨이

- VPC와 인터넷 간에 통신을 위한 리소스로 VPC 내부 리소스가 인터넷에 연결하거나 혹은 외부에서 서브넷의 리소스에 접근하고자 할 경우 활용 (리소스가 웹서버라면 인터넷 통신 상에서 소통할 필요가 있음!)

- 인터넷 게이트웨이는 IPv4와 IPv6 트래픽을 지원

- 사용자가 콘솔상에서 인터넷 게이트웨이 생성 후 대상 VPC와 직접 연결해야 함(인터넷 구간 통신)

- HA 구성, 수평적 확장을 통해 네트워크 트래픽에 가용성 위험이나 대역폭 제약이 발생하지 않음

 

 

프라이빗 서브넷

- 프라이빗 서브넷(Private Subnet)은 인터넷 게이트웨이로 향하는 경로가 없는 라우팅 테이블과 연결된 서브넷

→ 인터넷 구간으로의 통신을 하지 않아야 되는 리소스를 생성하는 서브넷!

- 퍼블릭 인터넷에서 직접 액세스할 수 없음 (프라이빗 서브넷에 배치된 인스턴스 VM(가상머신) 은 Private IP만을 가짐)

- 보안 측면에서 일반적으로 웹서버 용도를 제외, 대부분의 인스턴스 프라이빗 서브넷에 배치하는 것이 바람직

 

퍼블릭 서브넷

- 퍼블릭 서브넷(Public Subnet)은 인터넷 게이트웨이로 향하는 경로가 있는 라우팅 테이블과 연결된 서브넷

- 퍼블릭 인터넷에 대한 인바운드 및 아웃바운드 액세스를 기원

- 퍼블릭 서브넷에 배치된 인스턴스는 Private IP와 함께 Public IP를 가져야 함

 

 

탄력적 IP 주소

- 탄력적 IP(Elastic IP, EIP)는 동적 클라우드 컴퓨팅을 위해 설계된 고정 퍼블릭 IPv4 주소

- 클라우드에서 리소스를 배정할 때,

  Private IP; 고정 IP / Public IP; 유동 IP (가상머신 중단 → 재실행해도 IP 를 고정하고 싶을 때!)

- 인터넷 연결 필요한데 퍼블릭 IP 변경되면 안되는 경우 EIP 발급, 리소스 할당

- 인스턴스, 네트워크 인터페이스, NAT gateway 등에 연결해 활용 가능

- 탄력적 IP 주소는 AWS 계정에 할당되며 리전당 5개로 제한

 

특징

- 실행 중인 인스턴스에 연결된 EIP 한 개는 무료로 사용 가능

- 탄력적 IP 주소의 효율적인 사용을 위해 EIP가 실행 중인 인스턴스와 연결되어 있지 않거나, 중지된 인스턴스에 연결되어 있는 경우 소액의 시간당 요금 부과

→ 사용하지 않는 EIP 바로 연결 해제 후 릴리즈 통해 제거해야 추가 비용 발생 X

 

 

탄력적 네트워크 인터페이스

- 탄력적 네트워크 인터페이스(ENI): VPC에서 인스턴스에 연결할 수 있는 가상 네트워크 인터페이스

- VPC 내 인스턴스에는 VPC의 IP 주소 범위에서 Private IP주소가 할당된 기본 네트워크 인터페이스가 있음 

→ 필요에 따라 가상 네트워크 인터페이스를 생성

- ENI를 생성해 특정 인스턴스에 추가로 연결, 추후 연결된 인스턴스에서 분리한 후 다른 인스턴스에 연결 가능

 

 

 

 

- ENI를 활용하는 용도 중 하나는 관리 네트워크 생성

- 인스턴스의 기본 네트워크 인터페이스(eth0)에서 퍼블릭 트래픽 처리

- 보조 네트워크 인터페이스(eth1) 생성해 백엔드 관리 트래픽을 처리하는 용도로 사용

 

 

 

 

 

 

 

 

프라이빗 서브넷

- 프라이빗 서브넷에 배치된 EC2 인스턴스도 필요에 따라 VPC 외부로 아웃바운드 트래픽을 내보내야 할 때는 어떻게 ?

 

NAT 게이트웨이

- NAT 게이트웨이는 네트워크 주소 변환 서비스

- Private IP만을 보유한 인스턴스들의 아웃바운드 트래픽을 인터넷 등 VPC 외부로 전송할 수 있도록 하기 위해 활용 (ex.업데이트 및 패치)

- 인스턴스의 프라이빗 IP 주소를 NAT 게이트웨이에서 퍼블릭 IP 주소로 변환해 인터넷에 연결, 응답 트래픽을 전송할 때 NAT 게이트웨이는 주소를 원래 프라이빗 IP 주소로 다시 변환

- 프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 인스턴스로의 연결은 불가능

 

 

 

 

 

- NAT 게이트웨이를 생성할 퍼블릭 서브넷을 지정

- NAT 게이트웨이에 연결할 EIP(고정 퍼블릭 IPv4 주소)를 할당

- 프라이빗 서브넷의 라우팅 테이블에 NAT 게이트웨이로 향하는 경로를 추가

- 내부에서 요청한 것을 응답은 받을 수 있으면 외부에서는 EC2에 대한 내용 알 수 없음 (NAT 게이트웨이의 역할, 보안상 적절)

 

 

 

서브넷 구성 시 고려사항

- 가용 영역 내에 서브넷을 몇 개 만들어야 할까?       제한두지 말자!
- NAT 게이트웨이는 리전 내 특정 가용영역에 한 개만 생성하면 되는가?    아니다! 여러 개 있을 수록 시스템 장애 대응에 좋음!

- 웹 티어 인스턴스는 어떤 서브넷에 배치해야 하는가?     기본(퍼블릭) -> Private subnet에 배치할 수 있는 예외가 있긴 함!

 

 

 

방화벽(Firewall)

- 방화벽: 미리 정의된 보안 규칙에 기반해 네트워크 트래픽을 모니터링하고 제어하는 네트워크 보안 시스템, 내부 네트워크와 외부와의 통신을 제어하고 내부 네트워크의 안전을 유지하기 위한 필수 기술

- 방화벽은 정의된 규칙에 기반하여 수신 트래픽을 허용하거나 차단하는데 이런 규칙은 대개 IP 주소, 포트, 프로토콜 등을 기반으로 설정

 

 

 

- AWS는 네트워크 통신 및 트래픽을 IP 주소, 프로토콜, 포트 기준으로 허용/차단하기 위해 네트워크 ACL, 보안 그룹과 같은 가상 방화벽 서비스 제공

- 네트워크 ACL(Network ACL)은 서브넷 경계에서 송신 및 수신되는 트래픽을 제어하기 위한 방화벽 역할 수행

- 보안 그룹(Security Group)은 AWS 리소스로 전송되는 인바운드 및 아웃바운드 트래픽을 제어하는 방화벽 역할 수행

 

 

 

보안 그룹

- 보안 그룹: 인스턴스와 같은 리소스 레벨에서 트래픽을 제어하기 위한 가상의 방화벽

- 트래픽은 모든 IP 프로토콜, 서비스 포트, 원본/대상 IP 주소(개별 IP 또는 CIDR 블록)에 의해 제한될 수 있음

- VPC를 생성할 경우 기본(Default) 보안 그룹이 함께 제공되지만 이는 기본 보안 그룹이 적용된 인스턴스간의 통신을 위한 용도

- 일반적으로 사용자 지정 보안 그룹을 생성하고 필요한 규칙을 추가, 특정 인스턴스에 적용하여 활용

- 사용자 정의 보안그룹을 생성하면 기본 설정은 모든 인바운드 트래픽을 차단 (인바운드 허용 규칙 없음!!)

-> 모든 아웃바운드 트래픽 허용!!

- 인바운드 트래픽 허용 규칙을 추가하거나 아웃바운드 규칙을 추가해 제한할 수 있음

- 보안 그룹은 등록된 모든 규칙을 평가하며 허용 규칙만 적용 가능

- 보안 그룹은 상태 저장(stateful) 특성을 가진 리소스임 (인바운드가 허용되면 인바운드 대응되는 아웃바운드 규칙 만들 필요 X)

- 즉, 보안 그룹은 인바운드 요청의 상태를 저장하고 반환 요청에 대한 아웃바운드 트래픽을 자동으로 허용

ex. 웹 서버에서 TCP 포트 80으로 인바운드 트래픽 허용 -> 임의의 TCP 포트를 통한 아웃바운드 트래픽이 자동으로 허용

 

 

네트워크 ACL

- 1개 이상의 서브넷 내부와 외부의 트래픽을 제어하기 위한 방화벽 역할을 하는 보안 계층

- VPC 생성 시 수정 가능한 기본 네트워크 ACL을 자동으로 제공 (기본적으로 모든 인바운드 및 아웃바운드 IPv4 트래픽을 허용)

- 네트워크 ACL은 규칙번호 있음, 보안그룹은 규칙번호 없음!! (규칙번호가 낮을수록 우선순위가 높음)

- 네트워크 ACL은 상태 비저장(Stateless) 특성을 가짐, 허용되는 인바운드 트래픽에 대한 응답은 아웃바운드 트래픽에 대한 규칙을 따로 그 반대의 경우에도 마찬가지 !!

- 사용자 지정 네트워크 ACL을 생성해 서브넷과 연결할 수 있음 (기본적으로 모든 인바운드 및 아웃바운드 트래픽을 거부)

 

 

 

VPC 피어링

- VPC 피어링 연결: 비공개적으로 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 VPC 사이의 네트워킹 연결을 의미

- 격리된 2개의 VPC 내 리소스 간 Private IP를 이용한 통신이 필요할 때 활용

- 동일 리전 내 VPC 간, 다른 리전에 있는 VPC, 다른 계정의 VPC와도 피어링 연결을 생성할 수 있음

- 피어링 연결 대상 VPC간에는 CIDR 중복이 없어야 함

 

 

Site-to-Site VPN

- Site-to-Site VPN: 인터넷망을 활용해 VPC와 온프레미스 네트워크를 안전하게 연결하기 위한 방식

- VPC와 온프레미스 네트워크 간 인터넷망에 VPN 터널을 생성하고 전송 데이터를 암호화해 통신

- Site-to-Site VPN은 인터넷 프로토콜 보안(IPsec) VPN 연결을 지원

- VPN 터널 당 최대 대역폭은 1.25Gbps, 인터넷망을 통해 연결하니 전송속도가 낮고, 대량의 데이터 빠르게 전송하기 어려움

- 빠른 연결 설정이 가능하고 많은 비용이 들지 않는 장점

- 가상 프라이빗 게이트웨이는 VPN이나 Direct Connect 구성을 위해 활용하는 리소스로 2개의 엔드포인트로 구성되어 고가용성을 지원(VPN 연결에 2개의 터널을 구성)

- VPN에 가상 프라이빗 게이트웨이 생성 및 연결, 사용자 지정 라우팅 테이블 생성, 보안 그룹 규칙 업데이트 과정을 통해 VPN을 생성

 

 

Direct Connect

- Direct Connect는 인터넷망을 거치지 않고 AWS 전용 네트워크를 통해 VPC와 온프레미스 네트워크를 연결하는 방식

- 1 또는 10Gbps(최대 100Gbps)의 전용 프라이빗 네트워크 연결을 제공

- 대용량의 데이터를 빠르게 전송할 수 있는 하이브리드 네트워크 환경을 제공

- 회사 보안 정책 또는 특정 규제로 인해 AWS 클라우드에 호스팅된 애플리케이션이 프라이빗 네트워크를 통해서만 액세스되도록 해야할 경우에도 필요

 

 

 

컴퓨팅 서비스_Amazon EC2

가상 머신

- 한 개의 물리적 서버 위에 다수의 가상머신을 생성해 애플리케이션을 독립적으로 실행

- 서로 다른 운영체제 기반의 다양한 기술 스택을 적용한 애플리케이션을 실행

- 컴퓨팅 자원의 사용률을 최대화하고 물리적인 서버의 개수를 줄임으로써 비용을 절감

 

 

Amazon EC2 정의

- Elastic Compute Cloud

: 클라우드에서 컴퓨팅 작업을 담당하는 가상머신, 온프레미스에서 서버가 수행할 수 있는 모든 워크로드를 지원

 

Amazon EC2 특징

- 글로벌 인프라를 활용해 고객이 원하는 다양한 위치에 배포 가능

- 고객의 워크로드 요구사항에 부합하도록 최신의 다양한 인스턴스 유형 제공 (인스턴스를 사용하는 용도가 다양)
: AI/ML 용도로 사용하면 CPU와 메모리 중 CPU의 성능이 좋아야 함!
: 데이터 분석할 때는 메모리 성능이 더 좋아야 함!

- 빠른 실행 및 변경 관리, 용량 조정 및 확장 지원 

- SLA를 통해 각 리전에 대해 99.99%의 가용성을 보장

- 비용 최적화 실현(사용한 만큼만 과금: 초당 결제, 시간당 결제)

 

 

EC2 생성 절차

EC2 인스턴스 생성 시 설정사항

- 기타 고급 옵션: 사용자 데이터/메타데이터, 전용 옵션, 배치 그룹, 요금 옵션, IAM 등

 

태그 활용

- 리소스 생성 시 태그를 지정하면 다수의 리소스를 보다 쉽게 관리할 수 있음

- 태그는 Key-Value 형태로 지정하고 대/소문자를 구분

- 태그는 리소스 용도, 소유자 또는 사용 환경 등을 기준으로 지정

- 동일 유형의 리소스가 많을 때 특히 유용하며 지정한 태그에 따라 리소스를 빠르게 식별, 필터링 및 관리할 수 있음

- 조직 내 리소스 및 비용을 효율적으로 관리할 수 있어 적극적으로 활용하는 것을 추처

- ex. 동일한 tag를 가진 다수의 인스턴스를 한번에 중지 및 재시작 가능

 

 

 

AMI 개념 및 용도

- Amazon Machine Image(AMI)는 인스턴스를 시작하는 데 필요한 정보를 제공하며 인스턴스를 생성 시 소스 AMI를 지정해야 함

- 동일한 구성의 인스턴스가 필요할 때 하나의 AMI에서 다수의 동일한 인스턴스들을 생성할 수 있음

- 용도별 AMI를 이용해 다양한 용도의 인스턴스를 생성할 수 있음 (ex. 웹 서버용 AMI, 애플리케이션 서버용 AMI 등)

- AWS에서 제공하는 사전 구축된 AMI, AMS Marketplace에서 다운로드, 사용자가 자체 생성한 사용자 AMI 모두 활용 가능

 

AMI 구성내용

- EC2 인스턴스 루트 볼륨용 템플릿: 루트 볼륨은 일반적으로 전체 운영 체제(OS) 및 설치된 구성 요소 (애플리케이션, 라이브러리, 유틸리티 등)를 포함

- 해당 AMI를 사용해 인스턴스를 시작할 수 있는 권한

- 인스턴스에 연할 볼륨을 지정하는 블록 디바이스 매핑 정보

 

AMI 활용 시 이점

 

AMI Marketplaces

- 서드 파티 소프트웨어를 구성, 배포 및 관리하는 각종 서비스를 탐색하고 구매 (AWS 제공)

 

사용자 AMI 생성

 

EC2 인스턴스 유형

 

 

EC2 Key Pair

- 서비스 운영 중 로그 확인, 상태 확인, 또는 설치 등을 위해 특정 인스턴스에 직접 접속하려면 Key Pair가 필요
(사용자가 인스턴스에 SSH 22번 포트를 통해 접속하기 위한 Private Key)

- Public Key는 EC2 인스턴스에 내장되어 있고 사용자가 다운로드 받은 Private Key를 사용해 인스턴스에 접속 시도, 인스턴스는 Public Key를 이용해 사용자의 접속 허용 여부를 결정

- 한번 다운로드된 Private Key 파일(.pem)은 보안상의 이유로 콘솔에서 재다운로드가 불가능하고 AWS에 저장되지 않음!! (파일 관리 중요)

 

EC2 데이터 저장

- 블록 스토리지: Amazon EBS, EC2 with Instance Store

- 파일 스토리지: EFS/FSx

-> 용도에 따라 EC2 인스턴스에 위 3가지 스토리지 옵션을 선택해 사용할 수 있음

 

사용자 데이터와 메타 데이터

사용자 데이터

- EC2 인스턴스 생성 시 사용자 데이터(User Data)에 쉘 스크립트를 작성해 일반적인 구성 작업을 자동화하는데 사용할 수 있음
- 인스턴스 AMI를 패치 및 업데이트하거나 소프트웨어 라이선스 키를 가져와 설치하거나 또는 추가 소프트웨어를 설치하고자 할 경우 활용

 

메타 데이터

- 인스턴스 메타데이터는 실행 중인 인스턴스를 구성 또는 관리하는 데 사용될 수 있는 인스턴스 관련 데이터를 의미함 (Key-Value 형식)

- 사용자 데이터 내 쉘 스크립트 작성 시 인스턴스 속성 정보를 조회하기 위해 활용

- 메타데이터에는 시작을 완료한 새 인스턴스의 퍼블릭 IP 주소, 호스트 이름 또는 MAC 주소 정보 등이 있음

 

 

인스턴스 생명주기

- 인스턴스 사용요금은 Running(실행) 중인 경우에만 청구되며 정지(Stopped)나 종료 상태(Termiated)에서는 과금 되지 않음

- 인스턴스 상태가 Pending 혹은 Shutting-down하는 시기에 특정 목적의 쉘 스크립트를 활용해 필요한 작업을 수행할 수 있음

 

 

요금 옵션

Amazon EC2 요금 옵션

1) 온디맨드 인스턴스

- 장기 약정 없이 컴퓨팅 파워에 대해 시간당 또는 초당 비용을 지불 (Linux, Ubuntu)

- 각 인스턴스에 사용된 인스턴스 시간, 즉 인스턴스가 시작된 시점부터 종료 또는 중단될 때까지의 시간을 기준으로 요금 책정

- 애플리케이션의 수요에 따라 컴퓨팅 파워를 확장 또는 축소 가능, 변경이 용이함

- 사전 H/W 용량 계획이 어려운 예측할 수 없는 신규 서비스 제공에 적합, 가상머신 많이 쓰지 않는 서비스에 적합

 

2) 절감형 플랜

- 1년 또는 3년 약정으로 구매하는 방식, 온디맨드 인스턴스 요금에 비해 상당한 할인 혜택 (최대 72%)을 제공

- Compute Savings Plans(최대 66%할인), EC2 Instance Savings Plans(최대 72%할인) 2가지 방법 선택 가능

- Compute Savings Plans는 리전, 가용영역, 인스턴스 유형 및 크기, OS 등의 변경이 가능하고 EC2 Instance Savings Plans는 크기, OS 변경 만 가능

- 인스턴스 사용량 수준을 알고 있다면 미리 정해진 용량을 예약해서 비용을 절감

 

3) 스팟 인스턴스

- Amazon에서 기구축한 컴퓨팅 용량에서 미사용 용량을 온디맨드 대비 최대 90% 할인된 가격으로 활용하는 방식

- 경우에 따라 AWS에서 온디맨드 고객에게 제공하기 위한 스팟 용량을 회수(사용자가 필요한 작업을 수행할 수 있도록 종료 시 2분 전에 중단 공지 제공)

- 주요 활용 사례로 비디오 트랜스코딩, 빅데이터 처리, 대량의 병렬 계산 등이 있음

- 상태 비저장 서비스 혹은 실패해도 재시도하면 되는 일회성 작업에 주로 사용

 

Compute Optimizer

- AWS Compute Optimizer는 AWS 리소스의 구성 및 사용률 지표를 분석하는 서비스

- 사용자는 리소스(EC2, EBS 등)가 최적의 상태인지 여부 (Under-Provisioned, Optimized, Over-Provisioned)를 검토하고 최적화를 권장사항을 확인해 비용 절감 및 워크로드 성능을 개선할 수 있음