개요

Elastic Compute Cloud
AWS의 가장 기본적인 컴퓨팅 리소스.
말 그대로 서버 한 대를 빌려서 원하는 대로 사용할 수 있다.
다른 모든 리소스들의 원형격에 해당한다.

매우 매우 다양한 사양의 인스턴스를 빌릴 수 있고, 가격 정책도 다양하다.
그래서 되도록 자신의 필요에 맞게 종류를 고르는 것이 중요하다.

스펙

말 그대로 정말 다양하다.

사양 표기법은 다음과 같다.

• 인스턴스 패밀리
  • 메모리 최적화, cpu 최적화 등등
  • 범용으로 T,C,M 정도
• 인스턴스 세대
  • 버전
• 인스턴스 크기
  • 두배씩 증가

싸게싸게 이용하고 싶다면 t타입, 그외의 범용적으로는 m타입 정도를 쓰는 것 같다.

T 타입에 대해

실무에서는 T타입을 지양하는 것이 좋은데, 왜냐하면 이 녀석은 cpu 사용량에 대한 제약이 있기 때문이다.^[1]
t 타입에서는 cpu 사용량을 크레딧으로 관리한다.
무슨 말이냐, cpu를 많이 사용하면 크레딧이 소모되고, 크레딧을 다 사용하면 그만큼의 성능을 낼 수 없다는 것이다.
CPU를 5~15퍼 정도로 사용 시 크레딧이 소모되고, 그 이하로 사용하면 크레딧이 쌓인다.
그리고 이 크레딧은 한 시간 단위로 쌓이며 최대 24시간의 양 만큼 저장된다(스펙마다 다를 수도).
그래서 잠깐 잠깐 쓰는 정도에만 적합한 타입이라 할 수 있다.
대신 그만큼 가격은 착한 편이다.

cpu 유형

그라피톤, arm

요금

EC2 자체가 실행되는 요금과, EC2에 붙이는 EBS블록에 대한 요금이 따로 존재한다.

온디맨드

빌린 시간 만큼 과금하는 방식으로, 가장 기본적이라 할 수 있다.
기본적인 AWS 이미지라면 1분마다 비용이 발생한다.
그런데 이게 유의할 게 사용하는 이미지에 따라 과금이 다르며, 산정되는 기간도 다르다..
가령 아마존 리눅스를 위에 올리면 가격이 조금 착해지는데 rhel을 올리면 또 조금 비싸진다던가..

과거에는 윈도우 이미지면 한 시간마다 발생했다고 한다.
RHEL 역시 24.07월에 초당으로 바뀐다.
근데 이게 또 VPC가 연결된 개수에 따라 달라지고.. 복잡하다.

절감형 플랜

원하는 시간만큼 미리 구매
예약 인스턴스라고도 부른다.

스팟 인스턴스

경매 방식으로, 현재 사용되고 있지 않은 떨이 구역을 훨씬 싼 가격에 구매할 수 있다.
남은 공간을 사용하는 거라 누군가 온디맨드로 사용을 하려고 한다면 자연스레 인스턴스를 뺏긴다..
그래도 뺏기기 2분 전쯤에 알람을 주기 때문에, 이를 활용하면 비용을 절약할 수 있다.
2~30퍼 정도의 가격 세이브가 있다는 것 같다.

EKS에서는 Karpenter를 이용해 스팟 인스턴스를 야무지게 활용할 수 있다.

구조

가상화 기술을 활용했다.
즉, 신청한 Amazon Region, AZ에 위치한 IDC의 리소스를 하이퍼바이저를 통해 가상화한다.
그 위에는 사용자가 지정한 이미지로 부팅을 하고, 이 게스트를 사용자에게 나눠주는 구조이다.
이 게스트 하나하나가 인스턴스가 된다.
현재 하이퍼바이저는 XEN, 이후에는 KVM을 사용한다고 한다.
디스크는 네트워크를 통해 연결되며, 아래에서 보게 될 스토리지에 해당한다.

기본 구성 요소

EC2에는 연결된 다양한 리소스가 존재한다.
이것들이 다 복합적으로 얽히고 설켜서 사용하게 되는데, 이를 잘 다루는 게 클라우드 엔지니어라 할 수 있겠다.
이중 인스턴스가 가장 기본이고, 이는 인스턴스를 만들 때 필요한 요소들이다.

• ami
• ebs, snapshot
• key pair, bootstraping
• vpc, 보안그룹, elastic ip

AMI

Amazon Machine Image

인스턴스 시작에 필요한 OS, 앱이 구성된 이미지
이미지는 기본적으로 Amazon S3에 저장된다.
이걸 하드디스크에 박아야 비로소 부팅이 되고 OS로 동작을 할수 있다.
어떤 OS 설치할지 선택할 때 보게 되는 것이 이것.

사용자 커스터마이징도 가능하다!

커스텀 AMI를 커뮤니티로 공유하는 것도 가능하다
AMI 부분을 가보면 로드밸런서, 방화벽 등 다양한 기능을 기본적으로 탑재한 AMI가 있다.
AWS 내의 리소스들은 어느 정도 한계가 있기 때문에 이런 서비스들의 도움을 받을 수 있다.

인스턴스 스토리지 장치

말 그대로 인스턴스의 디스크를 뜻한다.

인스턴스 스토어

ec2가 가동되는 디스크는 사실 Amazon EBS위에 세팅된다.
즉, 컴퓨팅 리소스가 돌아가는 위치와 디스크 공간의 위치가 물리적으로 분리돼있다는 것이다.
그렇지만 만약 인스턴스와 같은 컴퓨터에 위치한 저장 공간을 활용할 수 있다면 어떨까?
disk io가 굉장히 빠를 것이다.
그런 공간이 바로 instance store이다.
일전의 실험을 해봤을 때는 대충 7배 가량 빨랐는데 아마 인스턴스 유형마다 다를 것이다.
구제적으로 인스턴스 스토어는 실제 해당 인스턴스의 물리적 위치에 존재하는 스토리지 공간을 말한다.

ami 단에서 미리 세팅을 하거나, 보통 nvme를 사용하는 타입은 포맷이 되지 않은 채로 블록이 붙어있다.^[2]
이 저장 공간은 인스턴스와 수명을 같이 하는데, 중지되거나 절전이 되도 데이터를 보장하지 않는다.
그래서 실질적으로 활용할 때는 메모리처럼 빠르면서 휘발성있는 공간으로 생각하는 편이 좋다.
물론 메모리만큼 빠를 순 없다.
https://aws.amazon.com/ko/blogs/containers/eks-persistent-volumes-for-instance-store/

aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=c*" "Name=instance-storage-supported,Values=true" \
--query "InstanceTypes[].[InstanceType, InstanceStorageInfo.TotalSizeInGB]" \
--output table

이 공간은 nvme 스토리지가 포함되는 특정 인스턴스 유형들에만 제공되며, 처음부터 파일시스템이 포맷팅되어 있지도 않다.
이 명령어를 통해 사용하고자 하는 인스턴스가 얼만큼의 크기를 지원하는지 체크해보자.
T 시리즈에는 인스턴스 스토어가 없다.^[3]

또한 이 스토리지는 영속성을 보장해주지 않는다.
인스턴스가 종료되면 같이 휘발되는, 메모리 같은 녀석이다.
그래서 메모리보다는 느리지만 그에 상응하는 넓은 공간이 필요할 때 사용하면 용이할 것이다.
가령 스왑 메모리를 써야 하는 상황이라면, 최소한 이 놈으로 세팅하자.

EBS

aws에서 기본이 되는 블록 스토리지로, ec2를 만들면 기본적으로 이 스토리지가 세팅되어 여기에 os가 올라간다.
위에서 잠시 언급했듯이 이것은 사실 ec2에 네트워크를 통해 연결된다.
자세한 내용은 Amazon EBS에 담는다.

볼륨마다 성능과 용량 정의 가능
ec2를 만들었다 지워도 많은 것들이 남게 된다.
저것들이 다 만들어지니까.
만들어진 게 아니라도, 기본적으로 만들어져 있는 것들도 있다.
보안그룹, 키페어, vpc 등등
이것들은 직접 만드는 것과 다르게 동작하는 경우가 많기 때문에 가급적 사용하지 않도록 한다.
aws 기능들을 활용하기에 불필요하게 많은 기능들이 있을 수도 있고, 어떤 기능이 있는지 알기도 어렵다.

키와 이름만 지정하면 쉽게 인스턴스를 만들 수 있다.

사용법

인스턴스 제작

https://velog.io/@server30sopt/AWS-EC2-개념-정리

접속 방법

4가지
정리
https://youtu.be/fytZgsmGwk8?si=ZZ3k_kFwoo4Wb36N

관련 문서

참고