최근 다시 AWS를 이용하게 되면서 AMI 선택하는데 눈에 띄는 변화를 목격했다.

아래 그림처럼 이미지 대부분이 HVM으로 바뀐 것인데 정확히는 PV가 사라진 것.

그림에는 다 나오지 않았지만 사용중인 region에서 Ubuntu의 경우 HVM 이미지만 제공하고 있다.

먼저 PV(Para Virtualization)와 HVM (Hardware Virtual Machine)의 차이부터 정리할 필요가 있겠는데,

PV는 반가상화로 guest os가 hypervisor를 통해 hardware를 제어하고 가볍기 때문에 퍼포먼스가 좋지만 guest os에 수정이 필요하다. 반면에 HVM은 전가상화로 보면 되는데 다른 guest와 완전히 독립되고 os 수정없이 그대로 사용가능하다는 이점이 있지만 hardware 자체가 전가상화 기능(CPU의 VT)을 지원해야 하기 때문에 이것이 부담이 되어 퍼포먼스가 PV에 비해 떨어진다고 알려져 왔었다.

AWS는 Xen 기반이지만 PV, HVM 모두 제공해왔고 위에서처럼 초기부터 PV 성능이 더 좋다고 알려져왔기 때문에 HVM을 선택할 일은 없었는데 왜 이렇게 바뀐 것인지 찾다가 재미있는 글을 보게 되었다.

AWS in 2015: Why You Need to Switch from PV to HVM

이 글을 보면,

PV가 HVM보다 성능이 좋기는 했지만 그 차이가 크지 않았고 AWS가 발전하면서 퍼포먼스 차이가 더 줄어들었거나 어떤 경우는 HVM이 더 좋은 성능을 내는 경우도 있다고 한다. 또 이렇게 된 이유로 Xen 자체의 기술 향상, 새로운 세대의 CPU 도입, EC2 driver의 향상 등을 들고 있다.

그리고 이번에 직접 목격한대로 AWS는 PV => HVM으로 점차 바꾸고 있는 중인 것 같고 최신 instance type들은 HVM으로만 제공하는 것으로 보인다. AMI matrix를 살펴보니 이제 PV 지원하는 instance type은 거의 없다.

위 링크에서 본 것중에 또 하나 재미있는 것은 T2 instance type에 대한 것이었는데,

CPU의 20~40%를 baseline으로 긋고 CPU 사용량이 그 이하가 되면 token을 적립하고 baseline을 초과하면 적립된 token을 소모하는 방식이라고 한다. PyCON APAC 2016에서도 잠깐 들었던 것 같은데 token이 정확히 어떤 단위인지 모르지만 과금과 관련된 얘기였던 것으로 기억된다. 어느 회사에선가 instance를 잘게 쪼개고 저녁엔 shutdown 해서 token 적립하고 아침엔 다시 올려서 적립된 token 쓰며 거의 공짜로 이용하고 있다던데. T2도 한 번 알아볼 생각.

ref : https://blurblah.net/1352

Step 4: 는 EC2의 스토리지를 설정 하는 것입니다.

여기에서 인스턴스 스토리지나 EBS를 설정 할 수 있습니다.

인스턴스 스토리지는, 인스턴스 타입 중에서 인스턴스 스토리지를 제공하는 경우에만 사용할 수 있습니다. 개념으로는 쉽게 생각하면, 우리가 사용하는 PC에 로컬로 내장되어 있는 마스터 HDD를 생각하면 됩니다. 윈도우를 사용하는 분들은 C드라이브를 연상하면 되겠네요.

인스턴스 스토리지는, 인스턴스 타입 중에서 인스턴스 스토리지를 제공하는 경우에만 사용할 수 있습니다. 개념으로는 쉽게 생각하면, 우리가 사용하는 PC에 로컬로 내장되어 있는 마스터 HDD를 생각하면 됩니다. 윈도우를 사용하는 분들은 C드라이브를 연상하면 되겠네요.

다만, 인스턴스 스토리지는 인스턴스를 끄게 되면 데이터도 함께 날라가는 임시적인 성격이 있다고 생각해야 합니다.

EBS는 쉽게 생각하면 네트웍으로 연결된 외장 HDD 를 떠올리면 되겠습니다. (그래서 일반적으로 인스턴스 스토리지보다 속도가 느릴 수 있겠죠.) EBS의 경우는 설정에 따라 인스턴스를 종료해도 데이터가 영구하게 남도록 할 수 있습니다.

단, EBS는 한번에 한 인스턴스와만 연결 될 수 있으며, 사용 요금이 있습니다. (프리티어의 경우 어느 정도까지 무료 제공되는지 확인해 보세요.)

여기서 선택한 t2.micro 인스턴스의 경우에는 EBS가 반드시 필요 하므로 위 화면과 같이 기본적으로 하나의 EBS가 추가되어 있습니다.

위 화면에서 디스크 공간의 크기와 볼륨 타입, 인스턴스가 터미네이션 될때 같이 삭제할 것인지의 여부를 선택합니다. (자세한 설명은 AWS의 EBS를 읽어보세요. http://aws.amazon.com/ko/ebs/details/)

ref : http://wingsnote.com/52

가용구역이란? 한 Region 내에 있는 서버들의 구역이라고 볼 수 있는데 한 Region 에 있는 서버들끼리는 전용 회선으로 연결되어 있어 일반 연결 보다

데이터 전송이 빠른 구역을 말한다, 그렇지만 다른 가용 구역끼리의 연결은 전용회선으로는 연결되어 있지 않아 일반 인터넷으로 데이터를 주고 받아야한다

RDS 는 Database를 생성 및 빽업 하는 AWS 서비스를 말하는데 기능 중 자동 빽업/복원을 설정 할 수 있다

빽업 기간이 길어질 수록 비용이 올라간다

DB 생성옵션 중 MultiAZ(다중 가용 구역) 를 yes 로 해놓을 경우 다른 가용구역(건물이 다른곳에 있는DB)과 연결 관계가 형성이 되면서

저장할 정보를 가용구역의 DB에도 자동으로 저장시킨다

이것의 장점은 한곳의 가용 구역이 먹통(고장)이 됐을때 다른 가용구역의 DB를 사용하면 된다는 장점이 있음

예약이나 특정 시점에서 수동으로 빽업 또한 가능

RDS 에서 도 스케일 Up 또 한 가능하다(특정 시간이나 즉시 옵션중에 선택하여 복사하는 형태로 진행)

=> 스케일 아웃도 가능한데 이럴때는 먼저

1. 한대의 컴퓨터를 만들어 놓는다 이것을 Master 라 함
   
   
2. 나머지 서버를 Slave n 로 만든다(Replica 들) (DB 인스턴스 생성)
   
   
3. 그 후 Master 와 Slave 들간의 동기화를 한다

=> 이렇게 설정 된 이후

• 쓰기 작업을 할때는 Master 에 쓰기 작업이 들어가면 나머지 Slave 들에서 최근 쓰여진 정보를 읽어 동기화를 한다
  
  
• 읽기 작업을 할때는 각 Slave 를 대상으로만 읽도록 처리하여 부하를 줄인다

[이때 master 에 과부하가 일어 날 수 있다]

• 이때 이런 기술은 RDS 가 알아서 해주지 않는데 이를 해결 하기 위한 방법 중 sharding 이라는 기술로 슬레이브 모두가 
  가져가는 것이 아니고 예를 들어 인덱스로 나누어서
  데이터가 쓰여질 슬레이브에 대한 인덱스를 계산해 관련 슬레이스에서만 쓰기가 일어나도록 할 수 있다
  

Amazon Relational Database Service(RDS)를 사용하면 클라우드에서 관계형 데이터베이스를 더욱 간편하게 설정, 운영 및 확장할 수 있습니다. 하드웨어 프로비저닝, 데이터베이스 설정, 패치 및 백업과 같은 시간 소모적인 관리 작업을 자동화하면서 비용 효율적이고 크기 조정 가능한 용량을 제공합니다. 애플리케이션에 집중하여 애플리케이션에 필요한 빠른 성능, 고가용성, 보안 및 호환성을 제공할 수 있도록 지원합니다.

Amazon RDS는 여러 데이터베이스 인스턴스 유형(메모리, 성능 또는 I/O 최적화)으로 제공되며 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server를 비롯하여 6개의 익숙한 데이터베이스 엔진 중에서 선택할 수 있습니다. AWS Database Migration Service를 사용하여 기존 데이터베이스를 Amazon RDS로 손쉽게 마이그레이션 또는 복제할 수 있습니다.

ref : https://aws.amazon.com/ko/rds/details/

한 서버로 트래픽이 몰리게 되면 한 서버에 부하가 커짐으로 여러 인스턴스를 만들어 놓고 각 서버로 트래픽을 분산하는 처리를 할 수 있는데

이때 분산해주는 서버를 ELB(Elastic Load Balancer)라 한다

ELB 를 사용하게 되면 사용자들이  처음 만나는 서버가 기존 서버가 아닌 ELB를 처음 만나 미리 분산해 놓은 서버중 한곳으로 가게된다

ELB는 오토스케일링과 같이 접목 될 수 있는 기술이라 볼 수 있겠다

ELB : Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소와 같은

여러 대상에 자동으로 분산시킵니다. 

Elastic Load Balancing은 단일 가용 영역 또는 여러 가용 영역에서 다양한 애플리케이션 부하를 처리할 수 있습니다. 

Elastic Load Balancing이 제공하는 세 가지 로드 밸런서는 모두 애플리케이션의 내결함성에 필요한 고가용성, 자동 확장/축소, 강력한 보안을 갖추고 있습니다.

AWS 에서 제공하는 제품들은 다음과 같은것들이 있음

Application Load Balancer

Application Load Balancer는 HTTP 및 HTTPS 트래픽의 로드 밸런싱에 가장 적합하며, 마이크로서비스와 컨테이너 등 최신 애플리케이션 아키텍처 전달을 위한 고급 요청 라우팅 기능을 제공합니다. 개별 요청 수준(레이어 7)에서 작동하는 Application Load Balancer는 요청의 콘텐츠를 기반으로 Amazon Virtual Private Cloud(Amazon VPC) 내의 대상으로 트래픽을 라우팅합니다.

Network Load Balancer

Network Load Balancer는 극한의 성능이 요구되는 TCP 트래픽의 로드 밸런싱에 가장 적합합니다. 연결 수준(레이어 4)에서 작동하는 Network Load Balancer는 Amazon Virtual Private Cloud(Amazon VPC) 내의 대상으로 트래픽을 라우팅하며, 초당 수백만 개의 요청을 처리하면서 극히 낮은 지연 시간을 유지할 수 있습니다. Network Load Balancer는 갑작스러운 일시적 트래픽 패턴 처리에도 최적화되어 있습니다.

Classic Load Balancer

Classic Load Balancer는 여러 Amazon EC2 인스턴스에서 기본적인 로드 밸런싱을 제공하며, 요청 수준 및 연결 수준에서 작동합니다. Classic Load Balancer는 EC2-Classic 네트워크 내에 구축된 애플리케이션용입니다.

장점

이외에 보안성 , 유연성,, 모니터링 감사로 성능 병목 파악등의 장점 등이ㅣ 있다

ref : https://aws.amazon.com/ko/elasticloadbalancing/

Amazon EC2 Auto Scaling이란 무엇입니까?

Amazon EC2 Auto Scaling을 통해 애플리케이션의 로드를 처리할 수 있는 정확한 수의 Amazon EC2 인스턴스를 보유하도록 보장할 수 있습니다. 

Auto Scaling 그룹이라는 EC2 인스턴스 모음을 생성합니다. 

각 Auto Scaling 그룹의 최소 인스턴스 수를 지정할 수 있으며, Auto Scaling에서는 그룹의 크기가 이 값 아래로 내려가지 않습니다. 

각 Auto Scaling 그룹의 최대 인스턴스 수를 지정할 수 있으며, Auto Scaling에서는 그룹의 크기가 이 값을 넘지 않습니다. 

원하는 용량을 지정한 경우 그룹을 생성한 다음에는 언제든지 Auto Scaling에서 해당 그룹에서 이만큼의 인스턴스를 보유할 수 있습니다.

 조정 정책을 지정했다면 Auto Scaling에서는 애플리케이션의 늘어나거나 줄어드는 수요에 따라 인스턴스를 시작하거나 종료할 수 있습니다.

예를 들어, 다음 Auto Scaling 그룹의 경우 최소 인스턴스 수 1개, 원하는 인스턴스 용량 2개, 최대 인스턴스 수 4개가 됩니다. 사용자가 정의한 조정 정책에 따라 인스턴스 수가 최소 및 최대 인스턴스 수 내에서 지정하는 조건에 따라 조절됩니다.

Auto Scaling의 이점에 대한 자세한 내용은 Auto Scaling의 이점을 참조하십시오.

Auto Scaling 수명 주기

Auto Scaling 그룹의 EC2 인스턴스에는 다른 EC2 인스턴스와는 다른 경로, 즉 수명 주기가 있습니다. 수명 주기는 Auto Scaling 그룹이 인스턴스를 시작하고 서비스에 들어갈 때 시작됩니다. 수명 주기는 인스턴스를 종료하거나 Auto Scaling 그룹이 인스턴스를 서비스에서 제외시키고 이를 종료할 때 끝납니다.

다음 그림에서는 Auto Scaling 수명 주기에서 인스턴스 상태 간 전환을 보여 줍니다.

보류(Pending)

Auto Scaling에서 확장 이벤트에 응답하면 하나 이상의 인스턴스를 시작합니다. 이러한 인스턴스는 Pending 상태에서 시작됩니다.

확장(Scale Out)

다음 확장 이벤트는 Auto Scaling 그룹에 EC2 인스턴스를 시작하고 이를 그룹에 연결하라고 지시합니다.

• 그룹의 크기를 수동으로 늘립니다. 자세한 내용은 수동 조정 단원을 참조하십시오.

• 지정된 수요 증가에 따라 그룹의 크기를 자동으로 늘리는 조정 정책을 만듭니다. 자세한 내용은 동적 조정 단원을 참조하십시오.

• 특정 시간에 그룹의 크기를 늘리도록 조정을 일정 기반으로 설정합니다. 자세한 내용은 예약된 조정 단원을 참조하십시오.

확장 이벤트가 발생하면 Auto Scaling 그룹이 할당된 시작 구성을 사용하여 필요한 수의 EC2 인스턴스를 시작합니다. 이러한 인스턴스는 Pending 상태에서 시작됩니다. Auto Scaling 그룹에 수명 주기 후크를 추가하면 여기에서 사용자 지정 작업을 수행할 수 있습니다. 자세한 내용은 수명 주기 후크 단원을 참조하십시오.

각 인스턴스가 완전히 구성되고 Amazon EC2 상태 확인을 통과하면, Auto Scaling 그룹에 연결되고 InService 상태에 들어갑니다. 이 인스턴스는 원하는 Auto Scaling 그룹 용량에서 감산됩니다.

서비스 상태의 인스턴스(Instances In Service)

인스턴스는 다음 중 하나가 발생할 때까지 InService(서비스중) 상태로 유지됩니다.

• 축소 이벤트가 발생하면 Auto Scaling은 Auto Scaling 그룹의 크기를 줄이기 위해 이 인스턴스를 종료합니다. 자세한 내용은 축소 시 Auto Scaling 인스턴스 종료 제어단원을 참조하십시오.

• 인스턴스를 Standby 상태로 설정하는 경우 자세한 내용은 대기 모드 시작 및 종료 단원을 참조하십시오.

• Auto Scaling 그룹에서 인스턴스를 분리합니다. 자세한 내용은 인스턴스 분리 단원을 참조하십시오.

• 인스턴스가 필요한 수의 상태 확인에 실패한 경우, Auto Scaling 그룹에서 제거, 종료 및 교체됩니다. 자세한 내용은 Auto Scaling 인스턴스 상태 확인 단원을 참조하십시오.

축소(Scale In)

생성한 확장 이벤트 각각에 대해 축소 이벤트를 생성하는 것이 중요합니다. 이렇게 하면 애플리케이션에 할당된 리소스와 그러한 리소스의 수요를 가능한 한 가깝게 일치시킬 수 있습니다.

다음 축소 이벤트는 Auto Scaling 그룹이 그룹에서 EC2 인스턴스를 분리하고 이를 종료하라고 지시합니다.

• 그룹의 크기를 수동으로 줄입니다.

• 지정된 수요 감소에 따라 그룹의 크기를 자동으로 줄이는 조정 정책을 만듭니다.

• 특정 시간에 그룹의 크기를 줄이도록 조정을 일정 기반으로 설정합니다.

축소 이벤트가 발생하면 Auto Scaling 그룹에서 하나 이상의 인스턴스를 분리합니다. Auto Scaling 그룹이 종료 정책을 사용하여 종료할 인스턴스를 결정합니다. Auto Scaling 그룹에서 분리되어 종료 중인 인스턴스는 Terminating 상태로 들어가며, 다시 서비스 상태로 돌아갈 수 없습니다. Auto Scaling 그룹에 수명 주기 후크를 추가하면 여기에서 사용자 지정 작업을 수행할 수 있습니다. 마지막으로 인스턴스가 완전히 종료되고 Terminated 상태로 들어갑니다.

인스턴스 연결(Attach an Instance)

Auto Scaling 그룹에 특정 기준을 충족하는 실행 중인 EC2 인스턴스를 연결할 수 있습니다. 인스턴스가 연결되면 Auto Scaling 그룹의 일부로 관리됩니다.

자세한 내용은 Auto Scaling 그룹에 EC2 인스턴스 연결 단원을 참조하십시오.

인스턴스 분리(Detach an Instance)

Auto Scaling 그룹에서 인스턴스를 분리할 수 있습니다. 인스턴스를 분리한 후에는 이를 Auto Scaling 그룹과 별도로 관리하거나 다른 Auto Scaling 그룹에 연결할 수 있습니다.

자세한 내용은 Auto Scaling 그룹에서 EC2 인스턴스 분리 단원을 참조하십시오.

수명 주기 후크(Lifecycle Hooks)

인스턴스를 시작하거나 종료할 때 사용자 지정 작업을 수행할 수 있도록 Auto Scaling 그룹에 수명 주기 후크를 추가할 수 있습니다.

Auto Scaling에서 확장 이벤트에 응답하면 하나 이상의 인스턴스를 시작합니다. 이러한 인스턴스는 Pending 상태에서 시작됩니다. Auto Scaling 그룹에 autoscaling:EC2_INSTANCE_LAUNCHING 수명 주기 후크를 추가한 경우, 인스턴스가 Pending 상태에서 Pending:Wait 상태로 이동합니다. 수명 주기 작업을 완료하면 인스턴스가 Pending:Proceed 상태로 들어갑니다. 인스턴스가 완전히 구성되면 Auto Scaling 그룹에 연결되고 InService 상태로 들어갑니다.

Auto Scaling에서 축소 이벤트에 응답하면 하나 이상의 인스턴스를 종료합니다. Auto Scaling 그룹에서 이러한 인스턴스가 분리되고 Terminating 상태로 들어갑니다. Auto Scaling 그룹에 autoscaling:EC2_INSTANCE_TERMINATING 수명 주기 후크를 추가한 경우, 인스턴스가 Terminating 상태에서 Terminating:Wait 상태로 이동합니다. 수명 주기 작업을 완료하면 인스턴스가 Terminating:Proceed 상태로 들어갑니다. 인스턴스가 완전히 종료되면 Terminated 상태로 들어갑니다.

자세한 내용은 Amazon EC2 Auto Scaling 수명 주기 후크 단원을 참조하십시오.

Auto Scaling 구성 요소

다음 표는 Auto Scaling의 핵심 구성 요소가 나와 있습니다.

시작하기

ref : https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html

AWS 내에서 인스턴스가 ip 를 할당 받은 다음 껏다 다시 키게 되면 ip 를 새로 받게 된다(즉 고정이 아니다)

이를 고정으로 하기 위햇 AWS 내부에서 제공하는 서비스인 Elastic IP 를 사용하면 고정으로 사용 가능하다

고정 IP 이면서 사용하고 있다면 무료로 하나까지 제공이 되는데 이 아이피를 어떤 하나의 인스턴스에서도 사용하지 않거나

2개 이상을 사용한다면 추가 과금이 된다

Elastic IP 를 사용하게 되면 Public IP 와 Elastic IP 라는 두개의 아이피가 인스턴스에 주어지는 것을 확인 할 수 있는데

이때 Elastic IP 가 고정 IP 가 된다

AWS EC2를 오랫동안 껐다가 다시 켜거나 혹은 재부팅만 해도 IP가 변경되는 경우가 있습니다. 유동IP이기 때문인데요.
고정으로 바꾸려면 ‘Elastic IP’를 이용하면 됩니다. ‘Elastic IP’의 뜻이 ‘유동 IP’지만 헷갈리지 마세요.

* 주의!! ‘Elastic IP’는 생성하고 사용하면 무료지만, 쓰지 않으면 비용이 발생합니다. 얼마인지는 모르겠네요. 안 쓰는 경우 삭제하세요.

1. EC2 대시보드에서 ‘Elastic IP’를 클릭합니다.

2. 아래 버튼을 클릭합니다. (EC2 대시보드에서요. =_=)

Yes를 누르면 생성됩니다.

3. IP위를 마우스 우측 클릭하면 아래와 같은 메뉴가 뜹니다.

– Allocate New Address: 새 IP를 생성합니다.
– Release Addresses: IP를 제거합니다.
– Associate Address: EC2 인스턴스에 연결합니다.
– Disassociate Address: EC2 인스턴스의 연결을 끊습니다.

4. ‘Associate Address’를 선택해서 연결할 인스턴스를 선택합니다.

– Reassociation: 체크하면, 해당 IP가 다른 곳에 연결되어 있을 경우 끊고 연결합니다.

5. 인스턴스의 Description에 ‘Elastic IP’가 들어가 있으면 성공. (-:

ref : https://blog.wonhada.com/?p=1581

스케일 업(Scale up) : 인스턴스의 부품을 즉 해당 임대한 컴퓨터의 CPU 나 각종 성능 관련 부품을 업그레이드 하는것 ( 비용 발생)

스케일 다운(Scale down) : 인스턴스의 부품을 즉 해당 임대한 컴퓨터의 CPU 나 각종 성능 관련 부품을 다운 그레이드 하는것 (비용 감소)

1. 스케일 업 다운을 할때는 우선 현재 서버의 내용을 이미지화시켜 만든다
2. 이미지를 만들었다면 스케일업 하기 원하는 인슽턴스를 내린다
3. 더 좋은 부품 세팅으로 인스턴스를 구성하여 만든다
4. 이미지를 새로 생성한 인스턴스에 올린다

아래 처럼 인스턴스의 사양을 변경 할 수 있다(스케일 업 or down)

ref : https://www.slideshare.net/awskorea/10-aws-microsoft-sql-server

AMI : 이미지화 시킨다는 말은 현재 컴퓨터(윈도우일경우)의 OS/소프트웨어들 포함 복사본을 만들어 이것을 파일 형태로 만들어 놓는데
        이 파일을 이미라 부름(.iso 파일 같은 느낌)으로 AWS 에서는 이 이미지들을 유니티의 에셋스토어에서 처럼 사람들이 만들어 놓고
        이미지들에 대한 공유/판매가 이뤄진다

인스턴스

동일한 AMI에서 다른 유형의 인스턴스를 실행할 수 있습니다. 인스턴스 유형에 따라 인스턴스에 사용되는 호스트 컴퓨터의 하드웨어가 결정됩니다. 각 인스턴스 유형은 서로 다른 컴퓨팅 및 메모리 기능을 제공합니다. 인스턴스에서 실행하려는 애플리케이션 또는 소프트웨어에 필요한 메모리 양과 컴퓨팅 파워를 기준으로 인스턴스 유형을 선택하십시오. Amazon EC2 인스턴스 유형별 하드웨어 사양에 대한 자세한 내용은 Amazon EC2 인스턴스 유형 단원을 참조하십시오.

일단 인스턴스가 시작되면, 인스턴스는 다른 컴퓨터와 다를 것이 없고, 어느 컴퓨터와 동일한 방식으로 다루시면 됩니다. 인스턴스의 완벽한 통제가 가능하며, 루트 권한이 필요한 명령어는 sudo를 사용해 실행할 수 있습니다.

AWS 계정당 동시 수행할 수 있는 인스턴스 수는 제한됩니다. 해당 제한 및 추가 요청 방법에 대한 자세한 내용은 Amazon EC2의 실행 인스턴스 한도(종합 FAQ의 Amazon EC2) 단원을 참조하십시오.

인스턴스 스토리지

인스턴스의 루트 디바이스에는 인스턴스 부팅에 사용되는 이미지가 포함되어 있습니다. 자세한 내용은 Amazon EC2 루트 디바이스 볼륨 단원을 참조하십시오.

인스턴스에는 로컬 스토리지 볼륨이 포함될 수 있는데 이것을 인스턴스 스토어 볼륨이라고 하며, 인스턴스 실행 시 블록 디바이스 매핑으로 구성할 수 있습니다. 자세한 내용은 블록 디바이스 매핑 단원을 참조하십시오. 고객님의 인스턴스용 볼륨 추가와 매핑이 완료되면, 마운트하여 사용할 수 있습니다. 인스턴스 오류가 발생하거나 중지 혹은 종료된 경우, 해당 볼륨에 저장된 데이터는 손실되기 때문에 이런 볼륨은 임시 데이터 작성에 사용하는 것이 가장 좋습니다. 중요한 데이터는 여러 인스턴스를 연결하는 복제 방법을 사용하여 데이터를 보호하거나 지속적인 보관이 필요한 데이터를 Amazon S3 또는 Amazon EBS 볼륨에 저장하는 방법이 있습니다. 자세한 내용은 스토리지 단원을 참조하십시오.

보안 구현 모범 사례

인스턴스 중지, 시작 및 종료

인스턴스 중지

인스턴스를 중단하면 정상적인 실행종료 과정이 이루어지고 stopped 상태가 됩니다. 인스턴스의 모든 Amazon EBS 볼륨이 연결된 상태로 유지되므로 나중에 언제든지 다시 시작할 수 있습니다.

인스턴스가 중지됨 상태에 있는 동안에는 추가 인스턴스 사용량에 대한 요금이 부과되지 않습니다. 중지됨 상태에서 실행 중 상태로 전환할 때마다 최소 1분의 요금이 부과되며. 인스턴스가 중지된 상태에서 인스턴스 유형을 변경하면, 다음에 인스턴스가 시작된 후 신규 인스턴스 유형에 대한 요금이 부과됩니다. 모든 연결 Amazon EBS 루트 디바이스 사용을 비롯한 인스턴스 사용에 관련된 비용은 일반 Amazon EBS 요금이 적용됩니다.

인스턴스가 중지 상태인 경우 인스턴스에 Amazon EBS 볼륨을 연결하거나 분리할 수 있습니다. 또한 인스턴스로부터 AMI를 만들수도 있으며, 커널, 램 디스크, 인스턴스 유형을 변경할 수 있습니다.

인스턴스 종료

인스턴스가 종료될 때 인스턴스는 일반 종료를 수행합니다. 루트 디바이스 볼륨은 기본적으로 삭제되지만 모든 연결된 Amazon EBS 볼륨은 기본적으로 유지됩니다. 이는 각 볼륨의 deleteOnTermination속성 설정에 따라 결정됩니다. 인스턴트 자체도 삭제되므로 나중에 다시 시작할 수 없게 됩니다.

인스턴스 종료를 비활성화하면 실수로 인스턴스를 종료하는 일을 방지할 수 있습니다. 이 경우에는 해당 인스턴스에 관련된 disableApiTermination 속성을 true로 설정했는지 확인하십시오. Linux의 shutdown -h 및 Windows의 shutdown 같은 인스턴스 실행종료 동작을 제어하려면 instanceInitiatedShutdownBehavior 인스턴스 속성을 stop이나 terminate로 적절히 설정하십시오. 기본 설정은 인스턴스 실행종료 시 Amazon EBS 볼륨을 루트 디바이스로 사용하는 인스턴스는 stop 상태, 인스턴스 스토어를 루트 디바이스로 사용하는 인스턴스는 항상 종료 상태로 변경됩니다.

자세한 내용은 인스턴스 수명 주기 단원을 참조하십시오.

ref : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ec2-instances-and-amis.html

ref : https://aws.amazon.com/ko/ec2/details/