<h2>인스턴스</h2>
<ul>
<li>클라우딩 컴퓨팅의 단위</li>
<li>하나의 인스턴스는 격리된 컴퓨팅 공간으로 동작한다</li>
<li>인스턴스는 유형별로 성능이 모두 다르며, 성능이나 목적에 맞는 유형을 선택해서 만들어야 한다</li>
<li>인스턴스의 네트워크 정책은 보안그룹을 통해 결정된다</li>
<li>사용자 데이터를 통해서 인스턴스가 실행될 때 자동으로 동작할 스크립트를 지정할 수 있다</li>
</ul>
<h3>온디멘드 인스턴스</h3>
<ul>
<li>사용한 만큼 초 단위로 요금을 내는 인스턴스, 가장 기본적인 방식이다.</li>
<li>가장 유연하게 운용이 가능하다</li>
</ul>
<h3>예약 인스턴스</h3>
<ul>
<li>1년, 3년 단위로 계약해서 사용하는 인스턴스</li>
<li>최대 75% 저렴하다 (온디멘드 대비)</li>
</ul>
<h3>스팟 인스턴스</h3>
<ul>
<li>싯가로 책정된 여분의 인스턴스를 사용하는 방식</li>
<li>요금은 인스턴스중 가장 저렴 (최대 90%)</li>
<li>하지만 지정한 요금 이상으로 인스턴스의 삿가가 올라가면 해당 인스턴스는 2분의 유예기간 이후 자동으로 중단됨</li>
<li>때문에 진행 상황을 잃으면 안되는 작업에는 적합하지 않음</li>
</ul>
<h4>스팟 요청</h4>
<ul>
<li>하나의 작업을 위해 스팟 인스턴스를 유지할 수 있도록 하는 서비스</li>
<li>스팟 요청에서는 설정한 예산에 맞춰서 최적의 스팟 인스턴스를 계속 요청해서 작업을 유지해줌</li>
<li>인스턴스가 계속해서 지속적으로 중단되고 재실행 될 수 있기 때문에 복구가 보장되는 작업에 적합</li>
<li>더 이상 작업이 불필요 하게 되면 반드시 스팟 요청을 철회하고 스팟 인스턴스를 직접 종료해줘야 함
<ul>
<li>만약 스팟 요청이 실행되고 있고 스팟 인스턴스만 종료하면 스팟 요청은 다시 스팟 인스턴스를 만들어서 실행시킴</li>
</ul>
</li>
</ul>
<h3>전용 호스트</h3>
<ul>
<li>AWS 데이터 센터의 물리적인 서버를 렌탈하는 방식</li>
<li>클라이언트 정책에 따라 물리적인 서버가 필요하거나 라이센스 관련 제한이 있을 때 사용</li>
<li>요금은 온디멘드와 예약 방식중에 선택해서 지불할 수 있다
<ul>
<li>마찬가지로 예약이 최대 75% 저렴하다</li>
</ul>
</li>
</ul>
<h3>전용 인스턴스</h3>
<ul>
<li>전용 호스트 같이 물리적으로 격리된 공간에 EC2 인스턴스를 제공받는 방식</li>
<li>동일한 AWS계정 내의 다른 인스턴스와 하드웨어 공유가 가능</li>
</ul>
<h3>Hibernate (절전 모드)</h3>
<ul>
<li>EC2 인스턴스를 절전 모드로 들어가게 해준다.</li>
<li>기존의 인스턴스 중단을 하게 되면 작업 내역과 루트 EBS불륨의 모든 데이터를 잃게 되고, 인스턴스를 재시동할 때 사용자 데이터의 스크립트를 다시 시작하여 비효율적일 수 있다.</li>
<li>절전 모드에서는 인스턴스의 메모리를 모두 저장한 채로 중단하고 저장한 메모리를 복구하여 인스턴스를 재시작하기 때문에 상태를 유지하면서 빠르게 인스턴스를 재시작 시킬 수 있다.
<ul>
<li>메모리 전체를 루트 EBS볼륨에 덤프하여 보관하고 해당 EBS볼륨을 암호화 처리 해야한다</li>
</ul>
</li>
<li>모든 인스턴스 유형에서 지원하지 않음</li>
<li>인스턴스의 램은 최대 150GB까지만 지원하며 EBS불륨의 사이즈는 램의 데이터를 모두 덤프할 수 있을만큼 충분히 여유있어야 한다</li>
<li>스팟 인스턴스에서는 사용이 불가능</li>
<li>절전 모드로는 60일까지만 유지 가능</li>
</ul>
<h3>EC2 Nitro</h3>
<ul>
<li>EC2의 개선된 가상화 기술을 도입한 차세대 플랫폼</li>
<li>고성능 컴퓨팅과 네트워킹을 제공하고 더 빠른 속도의 EBS볼륨을 제공
<ul>
<li>최대 64,000 IOPS의 속도를 제공</li>
<li>기존에는 최대 32,000 IOPS의 속도로 제공</li>
</ul>
</li>
<li>더 나은 보안 제공</li>
<li>A1, T3, C5, C6, D3, M5 등의 인스턴스 패밀리에서 제공</li>
</ul>
<h3>vCPU 최적화</h3>
<ul>
<li>인스턴스는 컴퓨팅을 담당하는 코어와 스레드를 제공한다</li>
<li>만약 4코어 2스레드라면 총 8개의 스레드가 제공되며 각 스레드 하나를 vCPU로 일컫는다.</li>
<li>상황에 따라 코어의 갯수, 코어당 스레드의 갯수를 축소하여 비용을 절감할 수 있다
<ul>
<li>컴퓨팅 성능이 필요 이상으로 부여되는 경우</li>
<li>코어당 라이센스를 지불해야 하는 경우</li>
<li>코어당 하나의 스레드가 성능에 더 좋은 경우</li>
</ul>
</li>
</ul>
<h3>용량 예약</h3>
<ul>
<li>AZ내에서 원하는 인스턴스의 공간을 미리 할당하여 확보할 수 있다.</li>
<li>해당 인스턴스가 당장 필요하지는 않지만 공간을 미리 확보하여 필요할 때 동작을 보장받을 수 있어야 할 때 사용한다</li>
</ul>
<h2>보안그룹</h2>
<ul>
<li>하나 이상의 인스턴스의 네트워크 인/아웃바운드 규칙을 지정해 줄 수 있음</li>
<li>인스턴스 역시 하나 이상의 보안규칙을 가질 수 있음</li>
<li>각 포트별로 들어오고 나갈 수 있는 포트와 IP주소를 지정해 줄 수 있음</li>
<li>IP주소 뿐만 아니라 다른 보안그룹을 예외 규칙에 추가하여 인스턴스 사이의 네트워크 규칙을 쉽게 지정해 줄 수 있다.</li>
</ul>
<h2>SSH</h2>
<ul>
<li>외부에서 인스턴스 내부로 터미널을 통해서 접속할수 있다. 인스턴스에 지정한 키 페어를 통해 자격증명을 해야 접속할 수 있다.</li>
<li>키 페어는 생성할 때 한 번 컴퓨터에 저장할 수 있고 그 이후에는 절대 재발급이 안되기 때문에 잘 보관해야 한다.</li>
</ul>
<h2>IP</h2>
<ul>
<li>하나의 인스턴스는 퍼블릭IP와 프라이빗IP를 갖는데 퍼블릭IP를 통해 외부와 통신할 수 있다.</li>
<li>프라이빗IP를 통해서는 AWS서비스 내에서 통신할 수 있다.</li>
<li>퍼블릭IP는 인스턴스를 실행할 때 마다 변경된다.</li>
<li>탄력적IP를 통해서 인스턴스가 재실행되어도 퍼블릭IP를 유지할 수 있고 계정별로 5개를 기본으로 사용할 수 있다
<ul>
<li>탄력적IP는 발급받고 인스턴스에 바인딩 하지 않고 보관하게 되면 요금이 발생</li>
<li>로드밸런서 등을 이용해서 외부와 연결하는 게 더 좋기 때문에 사용을 지양하는 게 좋다</li>
</ul>
</li>
</ul>
<h2>배치 그룹</h2>
<ul>
<li>다수의 인스턴스를 다양한 방법으로 AZ(Availability Zone)에 배치할 수 있다.</li>
<li>작업에 따라 적절한 배치 전략을 선택할 수 있다.</li>
</ul>
<h3>클러스터 배치 그룹</h3>
<ul>
<li>같은 AZ내에 같은 클러스터 내에 인스턴스들을 배치하는 방식으로 동작한다.</li>
<li>물리적으로 같은 랙 내부에 인스턴스들이 동작하므로 인스턴스간의 통신에서 초저지연을 기대할 수 있다.</li>
<li>단 클러스터가 포함된 랙이 이슈가 생기면 모든 인스턴스가 영향을 받기 때문에 위험도가 높다.</li>
</ul>
<h3>분산형 배치 그룹</h3>
<ul>
<li>모든 인스턴스를 AZ내에 모두 다른 랙에 배치한다</li>
<li>하나의 배치그룹 당 최대 7개의 인스턴스를 포함할 수 있으며 각 인스턴스는 모두 다른 랙에 배치되기 때문에, 모든 인스턴스가 예상치 못한 하드웨어 이슈에 영향을 받을 확률이 거의 없다.</li>
</ul>
<h3>파티션 배치 그룹</h3>
<ul>
<li>인스턴스를 파티션이라는 논리 구조로 묶어서 배치한다.</li>
<li>하나의 파티션은 같은 랙에서 동작하며 스프레드 방식과 동일하게 같은 AZ내에서 최대 7개까지 관리할 수 있다.</li>
<li>인스턴스 별로 파티션을 지정해주거나 자동으로 배치할 수 있다.</li>
<li>하나의 랙에 이슈가 생기면 해당하는 파티션에 포함된 인스턴스들만 영향을 받게 된다.</li>
</ul>
<h2>네트워크</h2>
<h3>ENI</h3>
<ul>
<li>가상 네트워크 인터페이스</li>
<li>하나의 ENI는 하나의 사설 아이피를 할당받는다.</li>
<li>하나의 EC2 인스턴스는 다수의 ENI가 바인딩 될 수 있다.</li>
<li>인스턴스간의 ENI는 이동 및 교체가 가능하다</li>
</ul>
<h2>스토리지</h2>
<h3>EBS</h3>
<ul>
<li>Elastic Block Store</li>
<li>인스턴스가 실행되는 동안 연결 가능한 네트워크 드라이브</li>
<li>네트워크를 통해 연결되기 때문에 지연이 발생할 수 있음</li>
<li>인스턴스 종료 이후에도 데이터를 유지할 수 있다.</li>
<li>CCP 레벨에서는 하나의 EBS는 하나의 EC2 인스턴스에 마운트 가능하며, 어소시어에트 레벨에서는 일부 EBS는 다중연결을 지원한다</li>
<li>동일 AZ내에 있는 인스턴스간의 마운트/언마운트가 가능하다</li>
<li>인스턴스를 생성할 때 Root에 마운트된 EBS볼륨은 기본적으로 인스턴스가 종료되면 삭제되도록 설정되어 있다
<ul>
<li>해당 속성을 비활성화 하여 인스턴스가 종료되어도 Root EBS볼륨을 유지할 수 있다</li>
</ul>
</li>
</ul>
<h4>EBS 볼륨 유형</h4>
<p><strong>일반 목적 SSD</strong></p>
<ul>
<li>일반적인 애플리케이션에 적합, 가성비가 좋음</li>
<li>시스템의 부트 볼륨 등으로 사용된다.</li>
<li>1GiB - 16TiB까지 제공</li>
<li><strong>gp3</strong>
<ul>
<li>기본으로 3,000 IOPS의 성능과 초당 125MiB/s 처리속도</li>
<li>최대 16,000 IOPS, 1,000MiB/s 처리 속도까지 증가 가능</li>
</ul>
</li>
<li><strong>gp2</strong>
<ul>
<li>이전 버전의 볼륨으로 최대 3,000 IOPS의 성능</li>
<li>GiB당 3IOPS를 제공하도록 설정되어 있음 5,334 GiB에서 3,000 IOPS이 성능 제공</li>
</ul>
</li>
</ul>
<p><strong>프로비저닝 된 IOPS의 SSD</strong></p>
<ul>
<li>IOPS 성능을 유지해야 하는 중요한 비즈니스 애플리케이션에 적합</li>
<li>DB 워크로드에 적합</li>
<li><strong>io1/io2</strong>
<ul>
<li>4GiB - 16TiB까지 제공</li>
<li>io2는 io1보다 높은 성능을 같은 비용으로 사용할 수 있기 때문에 io2를 선택할 수 있으면 io2를 선택하는 게 좋음</li>
<li>최대 32,000 IOPS의 성능</li>
<li>Nitor EC2 인스턴스에서는 최대 64,000 IOPS까지 가능</li>
</ul>
</li>
<li><strong>io2 Block Express</strong>
<ul>
<li>4GiB - 64TiB까지 제공</li>
<li>밀리초 미만의 지연속도</li>
<li>최대 256,000 IOPS의 성능 (IOPS:GiB의 비율이 1,000:1)</li>
</ul>
</li>
</ul>
<p><strong>HDD</strong></p>
<ul>
<li>부트 볼륨으로 사용할 수 없음</li>
<li>125MiB - 16TiB까지 제공</li>
<li><strong>st1</strong>
<ul>
<li>처리량에 최적화되어 있음</li>
<li>빅데이터, 데이터 웨어하우징, 로그 처리에 적합</li>
<li>최대 처리량 500MiB/s, 최대 성능 500 IOPS</li>
</ul>
</li>
<li><strong>sc1</strong>
<ul>
<li>아카이브에 최적화되어 있음</li>
<li>접근 빈도가 낮은 고용량 데이터에 적합</li>
<li>최저 비용으로 데이터를 저장할 수 있음</li>
<li>최대 처리량 250MiB/s, 최대 성능 250 IOPS</li>
</ul>
</li>
</ul>
<h4>EBS 다중연결</h4>
<ul>
<li>io1/io2 에서만 사용 가능</li>
<li>같은 AZ내에 여러 인스턴스에 연결해서 사용할 수 있음</li>
<li>클러스트 인식 파일 시스템 에서만 사용가능
<ul>
<li>XFS, EX4 등은 사용 불가</li>
</ul>
</li>
</ul>
<h4>EBS 암호화</h4>
<ul>
<li>EBS볼륨을 생성할 때 암호화를 활성화 할 수 있음</li>
<li>암호화된 볼륨과 인스턴스간의 모든 데이터 전송이 암호화됨</li>
<li>스냅샷을 생성할 때 암호화되어 생성됨
<ul>
<li>스냅샷에서 생성된 모든 볼륨은 암호화됨</li>
</ul>
</li>
<li>암호화 방식은 투명하게 공개되어 AWS에서 처리됨</li>
<li>성능상의 영향이 거의 없음</li>
<li>KMS(AES-256)를 활용</li>
<li>암호화 되지 않은 스냅샷을 암호화하여 사용할 수 있음</li>
<li>이에 따라 암호화 되지 않은 볼륨도 스냅샷 복사를 통해 암호화 할 수 있음
<ul>
<li>먼저 암호화되지 않은 볼륨의 스냅샷을 생성</li>
<li>생성된 스냅샷을 암호화
<ul>
<li>해당 과정을 생략하고 암호화 되지 않은 스냅샷을 통해 바로 암호화된 볼륨을 생성할 수도 있음</li>
</ul>
</li>
<li>암호화된 스냅샷을 사용해서 새로운 볼륨 생성
→ <strong>암호화된 볼륨으로 생성됨</strong></li>
</ul>
</li>
</ul>
<h4>스냅샷</h4>
<ul>
<li>EBS 볼륨을 백업하는 것</li>
<li>스냅샷을 이용해 EBS볼륨을 복원할 수 있다.</li>
<li>스냅샷은 서로 다른 리전이나 AZ에 복사하여 이동할 수 있다.</li>
</ul>
<h3>EFS</h3>
<ul>
<li>Elastic File System</li>
<li>EC2 인스턴스에 마운트 되는 NFS(Network File System)를 관리하는 서비스</li>
<li>EBS와 다르게 다중 AZ에서 사용할 수 있음</li>
<li>가용성과 확장성이 EBS에 비해 높으며, 비용도 많이 듬</li>
<li>gp3 기준으로 3배 정도 비싸지만, 데이터를 사용한 만큼만 지불하기 때문에 많은 양을 저장하는 게 아니라면 EFS가 더 저렴할 수도 있음</li>
<li>NFSv4.1 프로토콜로 동작</li>
<li>리눅스에서만 마운트 가능</li>
<li>보안 그룹을 이용해서 컨트롤한다</li>
<li>1000개의 클라이언트, 초당 최대 10GB의 처리량을 지원</li>
<li>용량은 최대 페타바이트 급으로 사용량에 따라 자동으로 확장되기 때문에 따로 용량을 지정하지 않아도 됨 (사용한 만큼만 지불)</li>
<li><strong>성능 모드</strong>
<ul>
<li>웹서버와 같이 지연시간에 민감할 경우 범용 성능 모드를 사용
<ul>
<li>작은 파일에 신속하게 접근해야 할 때</li>
</ul>
</li>
<li>대규모 워크플로우를 처리해야 할 때는 Max I/O 성능 모드를 사용
<ul>
<li>지연 시간은 조금 더 걸리지만 높은 처리량</li>
</ul>
</li>
</ul>
</li>
<li><strong>처리량 모드</strong>
<ul>
<li>버스팅 처리량 모드
<ul>
<li>1TB당 50MiB/s → 최대 100MiB/s까지 확장 가능</li>
</ul>
</li>
<li>프로비저닝 된 처리량 모드
<ul>
<li>크기에 상관없이 1GiB/s 까지 지정 가능</li>
</ul>
</li>
</ul>
</li>
<li>스토리지 계층
<ul>
<li>파일에 대한 수명주기 관리 기능</li>
<li>일정 주기에 한 번씩 접근 빈도에 따라 다른 계층으로 파일을 이동시킴</li>
<li>접근 빈도가 낮은 파일은 EFS-IA라고 부르는 저비용의 계층으로 이동시킴
<ul>
<li>단 해당 계층에 있는 파일을 이동시킬 때 추가 비용이 발생하기 때문에 빈도가 낮은 파일만 위치시켜야 효율적인 비용 전략이 가능</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>AMI</h3>
<ul>
<li>Amazon Machine Image</li>
<li>인스턴스의 운영체제의 설정과 기본 환경 설정을 사전에 정의해 패키징한 이미지</li>
<li>사용자가 만든 AMI는 리전에 종속된다</li>
<li>다양한 AMI를 선택하여 인스턴스를 생성할 수 있다
<ul>
<li>공개 AMI : AWS에서 제공하는 AMI</li>
<li>사용자 AMI : 사용자가 직접 정의한 AMI</li>
<li>마켓플레이스 AMI : 사용자, 기관에서 유/무료로 제공하는 AMI</li>
</ul>
</li>
</ul>
<h3>인스턴스 스토어</h3>
<ul>
<li>인스턴스의 물리 서버에 연결된 하드웨어 드라이브를 제공한다.</li>
<li>물리적으로 연결되어 있기 때문에 네트워크로 연결된 EBS보다 빠른 응답속도와 I/O성능을 보장한다.</li>
<li>단 인스턴스를 종료하면 데이터가 손실된다
<ul>
<li>때문에 장기적인 데이터 보다는 버퍼, 캐시, 스크래치 데이터 등을 저장하는데 적합하다.</li>
</ul>
</li>
<li>EC2 서버에 장애가 발생하면 영향을 받는다.</li>
</ul>


[AWS] EC2

<h2>간단정리</h2>
<ul>
<li>AWS서비스 내의 모든 정책과 권한에 대한 설정을 담당</li>
<li>최소 권한 부여를 원칙으로 설계해야 한다.</li>
</ul>
<h4>정책</h4>
<ul>
<li>AWS 서비스 내의 각 <strong>기능에 대한 권한</strong>의 벌크를 지정한 JSON</li>
<li>어떤 서비스 내의 읽기, 쓰기, 지우기 등의 권한을 지정해 줄 수 있다.</li>
<li>AWS에서 기본적으로 정의된 것이 있고 사용자가 임의로 추가할 수 있다.</li>
</ul>
<h4>사용자</h4>
<ul>
<li>root 계정이 아닌 계정들, 임의로 추가 및 삭제가 가능</li>
<li>사용자별로 액세스 키를 통해 AWS콘솔에 접근할 수 있다.</li>
<li>사용자는 사용자 그룹, 직접 설정을 통해 정책의 영향을 받을 수 있다.</li>
<li>사용자는 하나 이상의 사용자 그룹에 포함될 수 있다.</li>
</ul>
<h4>사용자 그룹</h4>
<ul>
<li>사용자 그룹을 통해 다수의 사용자가 정책을 공유할 수 있도록 할 수 있음</li>
<li>하나 이상의 사용자를 그룹에 포함시킬 수 있으며, 이미 다른 그룹에 있는 사용자도 포함시킬 수 있다.</li>
</ul>
<h4>역할</h4>
<ul>
<li>AWS 서비스 내에 접근할 수 있는 권한을 부여할 수 있는 자격 증명</li>
<li>AWS 서비스(대표적으로 EC2 인스턴스), 다른 AWS 계정, 그 외 에서 해당 AWS의 서비스 내에 접근할 수 있도록 하고 권한을 부여한다.</li>
<li>역할의 권한은 정책을 통해서 지정할 수 있다.</li>
<li>역할은 생성할 때 유형을 지정하고 해당 유형에만 역할을 부여할 수 있다.</li>
</ul>


[AWS] EC2

[AWS] IAM