AWS EC2 인스턴스의 구성 요소와 실무 운영 기준

작성자Hee 조회수 45

도입

웹 서비스를 직접 운영하려면 애플리케이션이 실행될 컴퓨터가 필요하다. 물리 서버를 구매하면 초기 비용과 설치 시간이 발생하고, 트래픽 변화에 맞춰 용량을 조정하기도 어렵다.

Amazon Elastic Compute Cloud인 Amazon EC2는 AWS 클라우드에서 필요한 만큼 가상 서버를 실행하는 서비스다. 이 글에서는 EC2 인스턴스의 구성 요소와 선택 기준, 생성 이후의 운영 주의사항을 설명한다.

내용은 Linux 기반 웹 서버를 처음 구성하는 입문·중급 개발자를 기준으로 한다. 특정 리전의 가격이나 개별 인스턴스 사양은 계속 달라질 수 있으므로 AWS 공식 페이지에서 별도로 확인해야 한다.

핵심 개념 설명

EC2 인스턴스는 AWS 클라우드에서 실행되는 가상 서버다. 필요한 운영체제, CPU와 메모리 용량, 스토리지, 네트워크와 접근 정책을 선택해 실행한다.

인스턴스를 구성하는 요소

Amazon Machine Image인 AMI는 운영체제와 기본 소프트웨어 구성을 담은 실행 템플릿이다. Amazon Linux, Ubuntu, Windows Server 같은 운영체제와 조직에서 만든 사용자 지정 AMI를 선택할 수 있다.

인스턴스 유형은 가상 서버에 할당되는 컴퓨팅 특성을 결정한다. 유형마다 vCPU, 메모리, 네트워크, 스토리지와 가속 하드웨어의 조합이 다르다.

Amazon EBS는 인스턴스에 연결하는 영구 블록 스토리지다. EBS 기반 루트 볼륨은 인스턴스를 중지해도 유지되지만, 볼륨 자체의 저장 비용은 계속 발생한다.

보안 그룹은 인스턴스의 인바운드와 아웃바운드 트래픽을 제어하는 상태 저장 방식의 가상 방화벽이다. 허용 규칙만 만들 수 있으며 SSH와 애플리케이션 포트를 필요한 출발지에만 개방해야 한다.

키 페어와 IAM 역할은 서로 다른 목적을 가진다. 키 페어는 운영체제 로그인에 사용하고, IAM 역할은 인스턴스의 애플리케이션이 AWS API를 호출할 임시 권한을 제공한다.

인스턴스 유형의 주요 범주

범주 특성 대표적인 워크로드
범용 컴퓨팅, 메모리와 네트워크의 균형 웹 서버, 개발 환경, 중소형 애플리케이션
컴퓨팅 최적화 높은 프로세서 성능 중심 배치 처리, 미디어 변환, 게임 서버
메모리 최적화 대용량 메모리 중심 인메모리 데이터베이스, 분석 처리
스토리지 최적화 높은 로컬 I/O 처리량 중심 대규모 데이터 처리, 분산 파일 시스템
가속 컴퓨팅 GPU와 전용 가속기 활용 머신러닝, 그래픽, 추론 작업

T 계열과 같은 버스터블 인스턴스는 기준 CPU 성능을 제공하면서 CPU 크레딧을 사용해 일시적으로 더 높은 성능을 낸다. CPU 사용률이 지속적으로 높다면 크레딧과 Unlimited 모드 비용을 확인하거나 고정 성능 계열을 검토해야 한다.

가상 서버의 크기를 워크로드에 맞게 확장하고 축소하는 모습을 표현한 이미지
AI로 생성한 이미지입니다.

장점과 제약

EC2는 운영체제부터 네트워크와 스토리지까지 세밀하게 제어할 수 있다. 기존 서버 애플리케이션을 이전하거나 특수한 런타임과 에이전트가 필요한 환경에 적합하다.

대신 운영체제 패치, 접근 통제, 모니터링, 백업과 장애 복구는 사용자가 설계해야 한다. 애플리케이션 실행만 필요하다면 관리형 컨테이너, 서버리스 또는 Lightsail이 더 단순할 수 있다.

동작 원리 또는 구조

flowchart TD A[사용자 요청] --> B[인터넷 게이트웨이] B --> C[보안 그룹] C --> D[EC2 인스턴스] D --> E[EBS 볼륨] D --> F[IAM 역할] D --> G[CloudWatch]

외부 요청이 퍼블릭 서브넷의 인스턴스로 들어오려면 VPC 라우팅과 인터넷 게이트웨이 구성이 필요하다. 보안 그룹은 허용된 포트와 출발지의 트래픽만 인스턴스로 전달한다.

인스턴스의 운영체제와 애플리케이션은 연결된 EBS 볼륨에서 데이터를 읽고 쓴다. 애플리케이션이 다른 AWS 서비스에 접근할 때는 장기 액세스 키 대신 IAM 역할의 임시 자격 증명을 사용한다.

CloudWatch 지표와 로그, EC2 상태 검사를 함께 사용하면 인프라와 운영체제 문제를 구분하기 쉽다. 기본 지표만으로 애플리케이션 상태를 모두 알 수 없으므로 로그와 사용자 정의 지표도 설계해야 한다.

인스턴스 생명주기

flowchart LR A[Pending] --> B[Running] B --> C[Stopping] C --> D[Stopped] D --> A B --> E[Shutting down] E --> F[Terminated]

인스턴스는 생성 중인 pending 상태를 거쳐 running 상태가 되면 사용량 과금이 시작된다. 일반적인 EBS 기반 인스턴스는 stopped 상태에서 인스턴스 사용 요금이 없지만 EBS와 공인 IPv4 같은 별도 자원은 과금될 수 있다.

중지 후 다시 시작하면 기본 퍼블릭 IPv4 주소가 변경될 수 있다. 고정 주소가 필요한 서비스는 Elastic IP의 비용과 사용 정책을 확인하거나 로드 밸런서와 DNS를 사용한다.

terminated 상태의 인스턴스는 다시 시작하거나 복구할 수 없다. 종료 전에 루트 볼륨의 DeleteOnTermination 설정과 데이터 볼륨, 스냅샷 및 백업 상태를 반드시 확인해야 한다.

실무 기준 / 적용 방법

EC2가 적합한 상황

  • 운영체제와 런타임을 직접 제어해야 하는 경우
  • 기존 서버 애플리케이션을 큰 변경 없이 이전하는 경우
  • 특정 CPU, 메모리, GPU 또는 로컬 스토리지 구성이 필요한 경우
  • 지속 실행되는 워크로드에 세밀한 비용 최적화가 필요한 경우

EC2보다 다른 서비스가 적합한 상황

  • 단순한 웹사이트를 예측 가능한 월 비용으로 운영하면 Lightsail을 검토한다.
  • 짧은 이벤트 처리만 필요하면 AWS Lambda와 같은 서버리스 실행 환경을 검토한다.
  • 컨테이너 실행이 핵심이고 서버 관리가 불필요하면 AWS Fargate를 검토한다.
  • 데이터베이스 운영이 목적이면 Amazon RDS 같은 관리형 데이터베이스를 우선 검토한다.

인스턴스 선택 기준

  1. 평균과 최대 CPU 및 메모리 요구량을 확인한다.
  2. 네트워크 처리량과 EBS 대역폭 요구량을 확인한다.
  3. 소프트웨어의 x86과 Arm 아키텍처 호환성을 확인한다.
  4. 온디맨드로 시작해 실제 지표를 수집한 뒤 크기를 조정한다.
  5. 지속 사용량이 확인된 후 Savings Plans와 같은 약정 모델을 검토한다.

개발 초기에는 요구량을 추정해 큰 인스턴스를 고정하기보다 작은 범용 인스턴스로 측정을 시작하는 편이 안전하다. CloudWatch와 부하 테스트 결과를 기준으로 CPU, 메모리, 네트워크 및 EBS 병목을 각각 확인한다.

생성 전 체크리스트

  • 리전과 가용 영역을 선택하고 장애 복구 범위를 정한다.
  • 신뢰할 수 있는 AMI와 CPU 아키텍처를 선택한다.
  • 워크로드에 맞는 인스턴스 유형과 EBS 유형을 선택한다.
  • SSH 22번 포트를 전체 인터넷에 개방하지 않는다.
  • 애플리케이션 권한은 최소 권한의 IAM 역할로 제공한다.
  • IMDSv2만 허용하도록 인스턴스 메타데이터 옵션을 검토한다.
  • 백업, 로그 수집, 모니터링과 종료 방지 정책을 결정한다.

AWS CLI로 상태 확인

다음 명령은 지정한 리전의 인스턴스 ID, 상태, 유형과 IP 주소를 조회한다. AWS CLI 자격 증명과 `ec2:DescribeInstances` 권한이 먼저 설정되어 있어야 한다.

aws ec2 describe-instances \
  --region ap-northeast-2 \
  --query 'Reservations[].Instances[].{
    Id:InstanceId,
    State:State.Name,
    Type:InstanceType,
    PrivateIp:PrivateIpAddress,
    PublicIp:PublicIpAddress
  }' \
  --output table

인스턴스가 `running`이어도 애플리케이션이 정상이라는 뜻은 아니다. EC2 상태 검사, 포트 리스닝 상태, 애플리케이션 로그와 실제 HTTP 상태 확인을 함께 수행한다.

IMDSv2 동작 확인

인스턴스 내부에서 메타데이터가 필요하면 세션 토큰을 사용하는 IMDSv2 방식으로 요청한다. 메타데이터에는 IAM 역할의 임시 자격 증명이 포함될 수 있으므로 애플리케이션의 SSRF 방어도 필요하다.

TOKEN=$(curl -sS -X PUT \
  -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600' \
  http://169.254.169.254/latest/api/token)

curl -sS \
  -H "X-aws-ec2-metadata-token: ${TOKEN}" \
  http://169.254.169.254/latest/meta-data/instance-id

명령이 인스턴스 ID를 반환하면 IMDSv2 요청이 처리된 것이다. 애플리케이션에서는 직접 HTTP 요청을 구현하기보다 최신 AWS SDK의 자격 증명 공급자를 사용하는 편이 권장된다.

비용 모델 선택

방식 적합한 상황 주의사항
온디맨드 사용량을 예측하기 어렵거나 초기 검증 단계 장기 지속 사용 시 비용을 다시 검토한다.
Savings Plans 1년 또는 3년의 일정 사용 금액을 약정할 수 있는 경우 실제 기준 사용량을 확인한 뒤 약정한다.
스팟 중단을 허용하는 배치, 테스트와 분산 처리 용량 회수에 대비한 재시도와 체크포인트가 필요하다.
용량 예약 특정 가용 영역의 실행 용량을 확보해야 하는 경우 비용 할인 상품과 목적이 다르다.

인스턴스 요금만으로 전체 비용을 판단하면 안 된다. EBS 볼륨과 스냅샷, 데이터 전송, 공인 IPv4 주소, 로드 밸런서와 모니터링 비용을 함께 계산해야 한다.

자주 발생하는 문제

문제 1. SSH 연결 시간이 초과된다

증상

인스턴스가 running 상태이지만 SSH 연결이 응답 없이 종료된다. 키 오류가 아니라 네트워크 경로 단계에서 연결되지 않는 상황이다.

원인

보안 그룹에 22번 포트가 없거나 출발지 IP가 다를 수 있다. 퍼블릭 IPv4, 서브넷 라우팅, 인터넷 게이트웨이 또는 운영체제 방화벽 구성도 확인해야 한다.

확인 방법

ssh -vvv -i ~/.ssh/example.pem ec2-user@203.0.113.10

예제 IP는 문서용 주소이며 실제 인스턴스 주소로 교체해야 한다. 연결 단계가 시간 초과되면 자격 증명보다 네트워크와 보안 그룹을 먼저 확인한다.

해결

관리자 공인 IP 또는 VPN 대역에서만 22번 포트를 허용한다. 퍼블릭 SSH를 열지 않으려면 AWS Systems Manager Session Manager나 EC2 Instance Connect Endpoint를 검토한다.

예방

SSH 규칙에 `0.0.0.0/0`을 사용하지 않고 인프라 코드로 허용 대역을 관리한다. 접근 경로를 정기적으로 검토하고 사용하지 않는 인바운드 규칙을 제거한다.

문제 2. 인스턴스를 중지했는데 비용이 발생한다

증상

EC2 인스턴스를 stopped 상태로 바꿨지만 청구 내역이 계속 증가한다. 인스턴스 컴퓨팅 외의 연결 자원이 남아 있는 경우가 많다.

원인

중지된 인스턴스의 EBS 볼륨과 스냅샷은 계속 저장된다. 공인 IPv4 주소와 Elastic IP, 로드 밸런서 같은 별도 자원에도 비용이 발생할 수 있다.

확인 방법

aws ec2 describe-volumes \
  --region ap-northeast-2 \
  --query 'Volumes[].{
    Id:VolumeId,
    State:State,
    SizeGiB:Size,
    Instance:Attachments[0].InstanceId
  }' \
  --output table

해결

Billing and Cost Management에서 서비스와 사용 유형별 비용을 확인한다. 삭제 가능한 볼륨은 스냅샷과 복구 절차를 검증한 뒤 정리하고 사용하지 않는 네트워크 자원도 함께 확인한다.

예방

프로젝트, 환경과 소유자 태그를 필수로 적용하고 AWS Budgets 알림을 설정한다. 정기적인 미사용 자원 점검과 종료 시 체크리스트를 운영한다.

문제 3. 재시작 후 데이터나 주소가 달라졌다

증상

인스턴스를 중지하고 시작한 뒤 퍼블릭 IPv4가 변경되거나 임시 데이터가 사라진다. DNS 또는 애플리케이션 설정이 이전 주소를 계속 참조할 수 있다.

원인

중지 후 시작하면 인스턴스가 다른 호스트로 이동할 수 있고 기본 퍼블릭 IPv4가 새로 할당될 수 있다. 인스턴스 스토어의 데이터는 중지, 최대 절전 또는 종료 시 유지되지 않는다.

확인 방법

aws ec2 describe-instances \
  --region ap-northeast-2 \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[0].Instances[0].{
    State:State.Name,
    PrivateIp:PrivateIpAddress,
    PublicIp:PublicIpAddress,
    RootDevice:RootDeviceType
  }'

해결

영구 데이터는 EBS, Amazon S3 또는 관리형 데이터베이스에 저장한다. 외부 접속 주소는 인스턴스의 일시적인 퍼블릭 IP보다 DNS, 로드 밸런서 또는 정책에 맞는 Elastic IP로 관리한다.

예방

인스턴스 로컬 상태에 의존하지 않도록 애플리케이션을 설계한다. 종료와 교체를 전제로 구성 자동화, 백업 복원 테스트와 상태 점검 절차를 준비한다.

참고 자료

한 줄 요약

Amazon EC2는 운영체제와 컴퓨팅 자원을 세밀하게 제어하는 가상 서버 서비스이며, 워크로드에 맞는 유형 선택과 보안·백업·모니터링·비용 관리가 함께 필요하다.

댓글 0

  • 첫 번째 댓글을 남겨보세요.