Amazon Machine Image (AMI) -> EC2를 만들기 위해서 사용하는 머신 이미지 Docker의 이미지와 비슷함. 

 

EC2도 도커처럼 머신 이미지를 제작해 자동화 한 뒤 EC2를 생성할 수 있음.

 

머신 이미지 만드는 과정

 

1. 준비 단계

  1. EC2 인스턴스 생성 및 설정
    • 원하는 OS(Amazon Linux, Ubuntu 등)로 EC2 인스턴스를 시작.
    • 필요한 패키지 설치, 보안 설정, 애플리케이션 배포 등을 완료.
  2. 불필요한 데이터/캐시 정리
    • 임시 파일, 로그 등을 삭제 → AMI 크기와 보안에 영향.

2. AMI 생성

  1. EC2 콘솔 접속 → Instances 메뉴.
  2. 대상 인스턴스 선택 → Actions → Image and templates → Create image 클릭.
  3. 이미지 이름과 설명 입력.
  4. 옵션 선택:
    • No reboot: 체크 시 인스턴스를 중지하지 않고 이미지를 생성하지만, 데이터 일관성이 완벽하지 않을 수 있음.
    • 루트 볼륨 및 추가 EBS 볼륨이 있는 경우 모두 포함 여부 선택.
  5. Create image 버튼 클릭.

3. AMI 생성 확인

  1. 왼쪽 메뉴 AMIs로 이동 → 상태가 Pending에서 Available로 변경될 때까지 대기.
  2. AMI와 함께 스냅샷(Snapshot) 도 자동으로 생성됨.
  3. 필요 시 태그(Tag)를 추가해 관리하기 쉽게 설정.

4. AMI 사용

  1. 새 EC2 인스턴스 생성 시
    • Launch instance → My AMIs 탭 → 생성한 AMI 선택.
  2. 다른 리전에 복사
    • AMI 선택 → Actions → Copy AMI → 대상 리전 선택.
  3. 필요 시 공유 또는 퍼블릭 설정
    • AMI 선택 → Modify Image Permissions → 특정 AWS 계정과 공유하거나 Public으로 전환.

추가 팁

  • 버전 관리: 업데이트할 때마다 새 AMI를 만들어 버전을 구분해 두면 롤백이 쉬움.
  • 자동화: CI/CD 파이프라인 또는 Packer 같은 도구로 AMI 빌드를 자동화 가능.
  • 보안: 민감한 데이터(비밀번호, SSH 키 등)를 인스턴스 안에 남겨두지 않도록 주의.

정리:

  1. EC2 준비 → 2) 콘솔에서 Create Image → 3) AMI 상태 확인 → 4) 새 인스턴스 시작/공유/복사.
    이 순서로 진행하면 안정적인 AWS 머신 이미지를 만들 수 있습니다.

참고 : ChatGPT

EC2 Key Pair

 

암호화 방식

RSA : 사용된지 오래된 Windows, Linux 가리지 않고 사용할 수 있음
ED25519 : Windows에서 주로 사용하는 암호화 방식

.pem : OpenSSH -> 보편적으로 쓸 수 있어서 사용하기에 편함 일반적으로 .pem으로 만들어서 사용
.ppk : PuTTY -> PuTTY, MobaXTerm 사용 가능 -> 개인적으로 MobaXTerm이 사용하기에 편했음.

MobaXTerm  : Putty를 대체하는 프로그램이 아니고 Putty와 Cygwin 및 Xwindows환경을 통합한 제품
Putty : filezilla와 같이 써서 게임 서버 열 때 사용해봄.

프라이빗 키 : 만든 모든 EC2 접근 가능 -> EC2를 만들때 마다 퍼블릭키가 복사되기 때문.

키를 잘못 넣고 만들면 로그인이 안될 수 있음.

 

IMDS v1 : 간단하게 인스턴스 정보를 가져올 수 있음 -> 해킹에 취약 

IMDS v2 : 토큰값을 넣어주면 지정한 시간 동안만 인스턴스 정보를 가져오거나 접근할 수 있음 -> 보안 강화

 

인스턴스 유형

범용

  • 컴퓨팅, 메모리, 네트워킹 리소스를 균형 있게 제공
  • 다양한 워크로드에 적합

컴퓨팅 최적화

  • 고성능 프로세서
  • 컴퓨팅 집약적 애플리케이션 및 배치 처리 워크로드에 적합

메모리 최적화

  • 메모리 집약적 워크로드를 위한 빠른 성능 제공
  • 고성능 데이터베이스에 적합

하드웨어 가속화 컴퓨팅

  • 하드웨어 가속기를 사용하여 데이터 처리 가속화
  • 애플리케이션 스트리밍 및 그래픽 워크로드에 적합

스토리지 최적화 -> I type (DB에 많이 씀)

  • 낮은 지연 시간 및 높은 IOPS (초당 입출력 작업 수) 제공
  • 분산 파일 시스템 및 데이터 웨어하우징 애플리케이션과 같은 워크로드에 적합

온디맨드

  • 초기 선결제 비용이나 최소 약정 없음
  • 불규칙한 단기 워크로드에 적합

스팟 ( 온디맨드 대비 90% 가까이 가격이 쌈 임의로 회수 당할 수 있음 ) 

  • 시작 및 종료 시간이 자유로운 워크로드에 적합 -> 학습용으로 쓰거나 여러대를 병렬로 쓸 때 요금 절감해 사용할 수 있음
  • 온디맨드 대비 비용 절감

예약

  • 온디맨드 요금에 비해 결제 할인
  • 1년 또는 3년 약정 필요

Compute Savings Plans EC2 Instance Savings Plan

  • 컴퓨팅 사용량이 일정할 경우 온디맨드에 비해 최대 66% 비용 절감
  • 1년 또는 3년 약정 필요

Lambda : 서버 관리를 AWS에서 해줌

 

Fargate : Container만 쓰고 서버 관리를 하고 싶지 않을 때

 

Compute Savings Plans : Lambda, Container 쓰고 서버 관리를 하지 않는 녀석들의 비용 절감을 위한 플랜

 

전용 인스턴스 (EC2)

  • 단일 고객용 하드웨어의 VPC에서 실행되는 EC2 인스턴스
  • 표준 Amazon EC2 인스턴스에 비해 더 높은 비용

전용 호스트 (물리 서버)

  • 단일 고객용 EC2 인스턴스 용량을 갖춘 물리적 서버
  • 가장 비용이 많이 드는 Amazon EC2 옵션

tmi -> 물리서버 : 늘리는데 어려움이 큼 

 

Elastic Load Balancing : 네트워크 트래픽을 여러 서버(EC2 인스턴스)에 자동으로 분산시켜주는 AWS의 서비스

 

ELB의 주요 목적은 단일 서버에 트래픽이 몰려 과부하가 걸리는 것을 방지하고, 애플리케이션의 가용성과 확장성을 높이는 것

 

주요 기능 및 개념

  • 부하 분산: 여러 대의 서버에 트래픽을 효율적으로 나누어 서버 과부하를 막고, 서비스의 안정성을 유지합니다.
  • 고가용성: 특정 서버에 장애가 발생하더라도, ELB는 해당 서버를 자동으로 감지하고 트래픽을 정상적인 서버로만 보냅니다. 이를 통해 서비스가 중단 없이 지속될 수 있습니다.
  • 자동 확장: 트래픽 양이 급증하면, ELB는 자동으로 EC2 인스턴스 수를 늘려(Auto Scaling 그룹과 연동 시) 트래픽을 처리하고, 트래픽이 줄면 다시 인스턴스 수를 줄여 비용을 절감합니다.
  • 헬스 체크: ELB는 주기적으로 등록된 서버들의 상태(건강성)를 확인합니다. 응답이 없는 서버는 트래픽 분산 대상에서 제외하고, 다시 정상 상태가 되면 트래픽을 보내기 시작합니다.

ELB의 유형

AWS에서는 크게 세 가지 종류의 로드 밸런서를 제공하며, 각각 다른 용도에 사용됩니다.

  1. Application Load Balancer (ALB): HTTP/HTTPS 트래픽을 처리하며, 경로 기반 라우팅(예: /images는 이미지 서버로, /api는 API 서버로)이 가능하여 마이크로서비스 아키텍처에 적합합니다.
  2. Network Load Balancer (NLB): 매우 높은 성능과 낮은 지연 시간을 요구하는 TCP/UDP 트래픽에 최적화되어 있습니다.
  3. Classic Load Balancer (CLB): 구 버전의 로드 밸런서로, 기본적인 HTTP/HTTPS 및 TCP 트래픽을 처리합니다. 현재는 새로운 애플리케이션에 사용이 권장되지 않습니다.

 

EC2 

Elastic IP : 변경되지 않는 IP -> 사용하지 않으면 비용 발생 -> 안쓰면 반납하기를 권장하기 때문 

public IP : 계속 바뀌는 IP

privateIP : 변경되지 않는 IP

 

Amazon EC2 Auto Scaling

  • 컴퓨팅 요구 사항의 변화에 따라 용량을 조정
  • 동적 조정 및 예측 조정 사용 

Scaling out : 늘어남

Scaling in : 줄어듬

 

최소 용량

희망 용량

최대 용량

 

미리 용량에 대한 설정을 Auto Scaling 그룹에서 설정.

 

 

모놀리식 아키텍처 (Monolithic Architecture)

전통의 아키텍처를 지칭한다. 소프트웨어의 모든 구성요소가 한 프로젝트에 통합 되어 있는 형태.

모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다.

 

 

장점

- 소규모 프로젝트에서는 합리적이다.

- 개발, 빌드, 배포, 테스트가 용이하다.

 

단점

- 어플리케이션 구동시간이 늘어나고 빌드,배포 시간이 길어진다.

- 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다.

- 많은 양의 코드가 몰려있어 유지보수가 힘들다.

- 일부분의 오류가 전체에 영향을 미친다.

- 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다롭다.

- scale out이 불가능 하다.

 

SOA 아키텍처는 공통된 서비스를 ESB에 모아 사업 측면에서 공통 기능의 집합을 통해 서비스를 제공한다.

 

ESB란? Enterprise Service Bus로 서비스들을 컴포넌트화된 논리적 집합으로 묶는 미들웨어로 이벤트 및 서비스에 대한 요청과 처리를 중개하여 인프라 전체 스트럭처에 분포되게한다.

 

여기서는 서비스가 아주 중요한 개념인데 서비스는 뭘까?

 

Service

서비스는 기업의 업무에 따라 나뉘어진 하나의 소프트웨어를 뜻한다.


현대의 SOA에서 서비스가 의미하는 바는 기업의 업무 중 하나를 뜻한다.

 

장점

ESB를 이용한 SOA는 서비스 단위로 모듈을 분리하다 보니 자연스럽게 결합도가 낮아지는 Loosly Coupled 된 아키텍처가 된다.


이런 특징은 서비스를 지향하여 각각의 모듈의 재사용성을 높임과 동시에 버스 형태에 연결만 가능하다면 확장성과 유연성이 증가한다는 특징이 있다.

 

문제점

하지만 ESB도 어쩔 수 없이 하나의 DB를 사용한다는 점에서 끊어질 수 없는 의존성이 존재하기 마련이다.

 

또한 구체적이지 않은 특성 덕분에 비즈니스에서의 실 성공 사례가 드물다는 특징이 있다.

 

마이크로서비스 아키텍처 (MicroService Architecture)

마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말한다. 각 마이크로서비스는 상호 통신이 가능하며 이를 통해 전체 서비스를 구성한다. 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신한다. 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행한다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.

 

 

장점

- 독립적인 서비스로 배포가 빠르고 모놀리식보다 가볍다.

- 서비스별 개별 배포 가능하여 배포 시 전체 서비스의 중단이 없다.

- 각 서비스에 따라 개별적으로 서버를 나눌 수 있어 메모리 및 cpu 관리에 효율적이다.

- 각 서비스가 모듈화 되어있고 모듈끼리 RPC, Message-driven 이용하여 통신하기 때문에 각 서비스의 개발 속도가 증가한다.

- 분리된 서비스로 개발할 수 있기 때문에 서비스마다 가장 적합한 기술을 선택 할 수 있다.

- 서버 및 프로스 장애 시, 격리 및 복구가 쉬워 장애가 전체 서비스로 확장될 가능성이 적다.

 

단점

- 각자 배포한 서비스에 대해 다른 서비스와 연계가 잘 되는지 확인해야 한다.

- 서비스 간 호출 시 REST API 사용으로 인한 통신비용, Latency(지연시간)가 증가한다.

- 서비스가 분산되어 있어 트랜잭션 관리, 장애 추적 및 테스트 등이 쉽지 않다.

- 서비스마다 DB가 분리되어 데이터의 조회가 어렵고 데이터의 중복이 발생한다.

- 전체 서비스가 커짐에 따라 복잡도가 기하급수적으로 늘어날 수 있다.

 

 

가상 머신(VM)과 컨테이너 차이

가상 머신에는 게스트 OS가 들어가는데 게스트 OS가 EC2

 

ECS / EKS

ECS

  • 컨테이너식 애플리케이션 실행 및 크기 조정
  • API 호출을 사용하여 Docker 지원 애플리케이션 제어

EKS

  • Kubernetes 애플리케이션 실행 및 ㅡ기 조정
  • 패치, 노드, 프로비저닝 업데이트 자동화

서버리스 컴퓨팅  -> 실제로 서버가 없다는게 아니고 사용자(클라이언트가) 관리할 서버가 없다는 뜻 AWS가 대신 관리

-> 대표적인 서버리스 Lambda

 

Lambda

  • 서버를 프로비저닝하거나 관리하지 않는 코드 실행
  • 코드가 실행되는 컴퓨팅 시간에 대해서만 비용 지불
  • 다른 AWS 서비스를 사용하여 코드를 자동으로 트리거

혼자서는 동작 못함

Event Source 필요 

-> 대표적인 것 

  • S3
  • DinamoDB
  • Kinesis
  • SNS
  • SQS
  • EventBridge
  • CloudWatch
주요 특징
  • 서버리스: 
    서버를 직접 관리할 필요 없어 코드에만 집중 가능
     
  • 이벤트 기반: 
    특정 이벤트에 반응하여 코드가 실행
     
  • 자동 확장: 
    트래픽에 따라 컴퓨팅 리소스가 자동으로 늘어나거나 줄어듬
     
  • 비용 효율성: 
    코드가 실행될 때만 비용이 발생하며, 서버 관리 비용을 절감
     
  • 다양한 이벤트 소스: 
    HTTP 요청, S3 파일 업로드, 데이터베이스 변경 등 다양한 AWS 서비스와 통합되어 이벤트를 처리

 

작동 방식

  1. 이벤트 트리거: 
  2. 웹사이트 업데이트, 파일 업로드, API 요청 등 특정 이벤트가 발생
     
  3. 함수 실행: 
    Lambda는 이 이벤트를 감지하고 사용자가 작성한 코드를 실행
     
  4. 데이터 전달: 
    Lambda 런타임은 이벤트 데이터를 JSON 형식의 객체로 변환하여 코드에 전달
     
  5. 코드 처리: 
    Lambda 함수는 이 객체를 기반으로 원하는 작업을 수행
     
  6. 리소스 관리: 
    코드가 실행되는 동안 AWS가 서버, 운영 체제, 컴퓨팅 인프라를 자동으로 관리하고 확장

m6g.2xlarge

m : 인스턴스 패밀리

6 : 세대를 뜻함 높을 수록 최신 세대

g : CPU 종류

2xlarge : 사양

 

 

 

참고 사이트 :
1. https://wonit.tistory.com/487#google_vignette 
2. https://daaa0555.tistory.com/457

'AWS 광주 개발일지(25.08.19~25.01.20) > 교육 25년 9월 일지' 카테고리의 다른 글

25.09.18 목요일 24일차 (AWS 네트워킹)  (0) 2025.09.18
25.09.17 수요일 23일차 ( 개인 프로젝트 설명 )  (0) 2025.09.17
25.09.16 화요일 21일차 (aws 개념)  (0) 2025.09.16
25.09.15 월요일 20일차 (aws 기본 개념)  (0) 2025.09.15
25.09.12 금요일 19일차 (전체 복습)  (0) 2025.09.12

티스토리툴바