EC2 인스턴스

EC2는 가상 머신을 생성하고 실행하는 서비스입니다. EC2 인스턴스는 EC2 서버스에서 사용하는 가상 머신(VM)입니다. 기존의 온프라미스와 비슷하지만 클라우드 환경에서 제공된다는 차이가 있습니다. EC2는 웹 호스팅, 애플리케이션, DB, 인증 서비스 등 워크로드와 서비스가 제공할 수 있는 기타 모든 워크로드를 지원할 수 있습니다.

워크로드?
워크로드는 비즈니스 요구 사항을 지원하는 데 필요한 리소스 및 코드의 집합입니다. 워크로드는 고객 대면 애플리케이션, 백엔드 프로세스, 데이터베이스 및 기타 구성 요소와 같은 다양한 요소로 구성될 수 있습니다. 워크로드는 비즈니스 요구 사항을 지원하고 비즈니스 목표를 달성하는 데 사용됩니다.

AWS에서는 서버, DB, 스토리지 및 상위 수준의 애플리케이션 구성 요소를 몇 초 내에 인스턴스화할 수 있습니다. 즉, 고정된 IT 인프라의 제약 없이 이러한 구성 요소를 일회용 임시 리소스로 사용할 수 있습니다. 탄력적인 클라우드 컴퓨팅에서는 이과는 전혀 다른 방식으로 변경 관리, 테스트, 용량 계획을 수행하고 신뢰성을 보장할 수 있습니다.

인스턴스 시작 시 고려 사항

• 이름 및 태그 - 인스턴스 식별 방법
• 애플리케이션 및 OS(운영 체제) 이미지 - 부팅 시 시작할 항목
• 인스턴스 유형 및 크기 - CPU와 RAM, 스토리지의 용량(기술적 요구 사항)
• 인증 및 키 페어 - 인스턴스에 연결하는 방법
• 네트워크 설정 및 보안 - 사용할 VPC, 서브넷 및 보안 그룹
• 스토리지 구성 - 사용 사례에 가장 적합한 블록 스토리지 유형
• 배치 및 테넌시 - EC2 인스턴스를 실행할 위치
• 스크립트 및 메타데이터 - 시작을 자동화하기 위해 수행할 수 있는 작업

OS(운영 체제)?
운영 체제(OS)는 컴퓨터 하드웨어와 소프트웨어 간의 상호 작용을 관리하고 사용자가 컴퓨터를 사용할 수 있도록 하는 소프트웨어입니다. 운영 체제는 컴퓨터 하드웨어의 리소스를 관리하고, 사용자와 컴퓨터 하드웨어 간의 상호 작용을 관리하고, 소프트웨어를 실행하고 관리하는 역할을 합니다.

EC2 태그

AWS에서는 메타데이터를 태그 형태로 리소스에 할당할 수 있습니다. 각 태그는 고객 정의 키와 선택적 값으로 구성된 간단한 레이블입니다. 태그를 사용해 리소스를 필터링할 수 있습니다. 태그를 통해 리소스 액세스 제어를 관리하고 비용을 추적할 수 있으며, 태스크를 자동화하고 조직을 관리할 수 있습니다.

태그를 필수적으로 작성해야 하는 것은 아니지만 이를 활용해 용도, 소유자, 환경 또는 기타 기준을 정해 리소스를 분류할 수 있습니다. 태그의 키-값 페어는 대소문자를 구분하므로 정확히 일치하는 문자열을 사용해야 합니다.

예시
CLI(명령줄 인터페이스)로 "XXX 태그를 가지고 있는 인스턴스를 중지해줘" 작업이 가능합니다.

자세한 내용

AMI(Amazon Machine Image)

AMI는 클라우드의 가성 서버인 인스턴스를 시작할 때 필요한 정보를 제공합니다. 동일한 구성의 인스턴스가 여러 개 필요할 때는 한 AMI에서 여러 인스턴스를 시작할 수 있습니다. 서로 다른 구성의 인스턴스가 필요할 때는 다양한 AMI를 사용하여 인스턴스를 시작할 수 있습니다. 인스턴스를 시작할 때 소스 AMI를 지정합니다.

즉, 한 종류의 템플릿이라고 봐도 됩니다. 이러한 AMI는 직접 만들어서 사용할 수도 있습니다. AMI에 포함되는 속성은 다음과 같습니다.

• 인스턴스 루트 볼륨 템플릿(OS, APP, APP 서버)
• 어떤 AWS 계정이 해당 AMI를 사용하여 인스턴스를 시작할 수 있는지 제어하는 시작 허용 권한
• 시작될 때 인스턴스에 첨부할 볼륨을 지정하는 블록 디바이스 매핑

AMI를 받을 수 있는 수단

1. AWS에서 제공하는 사전 구축된 AMI 사용
2. AWS Marketplace에서 여러 솔루션이 포함된 카탈로그를 검색
3. AMI를 수동으로 직접 생성하거나 EC2 Image Builder 사용

AMI는 구매하거나 판매도 할 수 있습니다. AWS 사용자 커뮤니티나 Marketplace에 구매 혹은 자신의 AMI를 등록해 판매도 할 수 있고, 공유를 할 수도 있습니다. 이 때 게시자는 프로덕션에서 사용하는 시스템 이미지의 초기 보안 상태를 책임져야 합니다.

자세한 내용

인스턴스 패밀리

먼저 인스턴스 유형 이름이 가지고 있는 의미에 대해서 이 포스팅에 정리해 놓았으니 참고하세요.

1. 범용
   • 컴퓨팅, 메모리, 네트워킹 리소스가 적절한 비율로 제공
   • 다양한 워크로드에 사용 가능
   • 웹 애플리케이션
2. 메모리 최적화
   • 메모리에서 대형 데이터 집합을 빠르게 전송
   • 데이터베이스 서버
   • 웹 캐시
   • 데이터 분석
3. 스토리지 최적화
   • 대량의 순차 읽기/쓰기
   • 대형 데이터 집합
   • NoSQL DB
   • AWS OpenSearch Service
4. 컴퓨팅 최적화
   • 컴퓨팅 기반 앱
   • 고성능 프로세서
   • 미디어 트랜스 코딩
   • 과학 모델링
   • 기계 학습
5. 가속 컴퓨팅
   • 대량의 그래픽 처리
   • GPU에 따라 제한 결정
   • 기계 학습
   • 고성능 컴퓨팅(HPC)
   • 자율 주행 차량

이 외에도 다양한 유형이 있으므로 자세한 내용은 여기에서 확인해주세요.

최신 인스턴스 이점

최신 인스턴스는 전반적으로 컴퓨팅 용량이 증가하고 인스턴스 실행과 관련된 처리 비용이 감사홉니다. 최신 세대 인스턴스를 사용하여 더 발전된 성능을 얻으면서 컴퓨팅 비용을 절감할 수 있습니다.

AWS 컴퓨팅 발전 과정과 이점

1. 가상 머신(VM, EC2)
   • 하드웨어 독립성
   • 더 빠른 프로비저닝 속도(분 or 시간 단위)
   • 하드웨어 구매 대신 종량제 요금 모델
   • 더 큰 스케일링 규모
   • 탄력적 리소스
   • 향상된 민첩성
   • 유지 관리 효율 증가
     
     
2. 컨테이너화(2014년 ECS, 2017년 EKS(쿠버네티스 기능 추가))
   • 플랫폼 독립성
   • 일관된 런타임 환경
   • 리소스 사용 증가
   • 더욱 간편하고 빠른 배포
   • 격리 및 샌드박싱
   • 더 빠르게 시작하여 몇 초 만에 배포
3. 서비리스(완전 관리형)
   • 지속적인 크기 조정 가능
   • 내장형 내결함성
   • 종량제 요금
   • 유지 관리 불필요
     
     
4. 맞춤형 프로세서
   • 인공지능(AI) 및 기계 학습(ML) 구현을 위해 제작
   • Inferentia 프로세서는 기계학습 추론을 위해 제작
   • Trainium 프로세서는 고성능 딥 러닝 교육에 최적화
   • Graviton 프로세서는 여러 작은 인스턴스 간에 로드를 공유할 수 있는 스케일 아웃을 위해 제작
   • Graviton2 프로세서는 Arm Neoverse 코어를 사용해 클라우드 워크로드에서 가성비 증가
   • Graviton3 프로세서는 EC2 워크로드에서 가성비 증가

프로비저닝?
프로비저닝은 IT 인프라를 설정하고 관리하는 과정입니다. 프로비저닝에는 컴퓨터, 네트워크, 저장소, 보안 및 기타 IT 자산이 포함됩니다. 프로비저닝은 IT 자산을 생성하고, 구성하고, 배포하는 것을 포함합니다.

종량제 요금?
사용한 만큼만 지불하는 것을 뜻합니다.

런타임?
런타임(runtime)은 컴퓨터 프로그램이 실행되고 있는 동안의 동작을 말합니다. 런타임에는 프로그램의 실행을 관리하는 런타임 시스템이 포함됩니다. 런타임 시스템은 프로그램의 메모리 할당, 함수 호출, 오류 처리를 담당합니다. 런타임 시스템은 또한 프로그램의 성능을 향상시키기 위해 최적화를 수행할 수 있습니다.

런타임 환경?
런타임 환경(runtime environment)은 컴퓨터 프로그램이 실행되는 동안 필요한 코드, 라이브러리, 데이터 및 기타 리소스를 포함하는 환경입니다. 런타임 환경은 프로그램의 실행을 관리하고 프로그램이 정상적으로 실행되도록 보장합니다.

런타임 환경은 프로그램의 종류에 따라 다릅니다. 예를 들어, Java 프로그램의 런타임 환경은 Java Virtual Machine(JVM)입니다. JVM은 Java 프로그램이 실행되는 데 필요한 코드, 라이브러리 및 데이터를 포함합니다. JVM은 또한 Java 프로그램의 실행을 관리하고 프로그램이 정상적으로 실행되도록 보장합니다.

런타임 환경은 프로그램의 중요한 부분이며 프로그램의 안정성과 성능에 영향을 미칩니다. 런타임 환경을 잘 설계하고 구현하면 프로그램의 안정성과 성능을 향상시킬 수 있습니다.

NACL(Network Access Control List, 네트워크 액세스 제어 목록)

네트워크 ACL은 1개 이상의 서브넷에서 전송 및 송신되는 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC용 선택적 보안 계층입니다. 모든 VPC에는 기본 네트워크 ACL이 자동으로 제공됩니다. 이 ACL은 모든 인바운드 및 아웃바운드 IPv4 트래픽을 허용합니다. 사용자 정의 네트워크 ACL을 생성하여 서브넷과 연결할 수 있습니다. 기본적으로 사용자 정의 네트워크 ACL은 규칙을 추가하기 전에는 모든 인바운드 및 아웃바운드 트래픽을 거부합니다.

네트워크 ACL은 번호가 지정된 규칙 목록을 포함합니다. 번호가 가장 낮은 규칙부터 시작하여 이 목록의 규칙을 차례로 평가합니다. 규칙이 트래픽과 일치하면 번호가 높은 규칙과 상충하더라도 해당 규칙이 적용됩니다. 각 네트워크 ACL에는 번호가 별표인 규칙이 있습니다. 이 규칙은 규칙 번호가 지정되지 않은 모든 패킷을 뜻합니다. 이런 패킷은 기본적으로 거부로 설정하는 것이 바람직합니다.

예시

인바운드
규칙 번호	유형	프로토콜	포트 범위	소스	허용 또는 거부
100	HTTP	TCP	80	0.0.0.0/0	허용
101	HTTPS	TCP	443	0.0.0.0/0	허용
*	모든 트래픽	ALL	ALL	0.0.0.0/0	거부

아웃바운드
규칙 번호	유형	프로토콜	포트 범위	소스	허용 또는 거부
100	사용자 정의 TCP 규칙	TCP	1024-65535	0.0.0.0/0	허용
*	모든 트래픽	ALL	ALL	0.0.0.0/0	거부

네트워크 ACL 규칙의 구성 요소에는 다음 항목이 포함됩니다.

• 규칙 번호 - 규칙은 번호가 가장 낮은 항목부터 시작하여 차례로 평가됩니다.
• 유형 - Secure Shell(SSH) 등의 트래픽 유형입니다. 모든 트래픽이나 사용자 정의 범위를 지정할 수 있습니다.
• 프로토콜 - 표준 프로토콜 번호가 지정된 어떤 프로토콜이든 지정할 수 있습니다.
• 포트 범위 - 트래픽용 수신 대기 포트 또는 포트 범위 입니다. 예를 들어 HTTP 트래픽에는 80이 사용됩니다.
• 소스 - 트래픽의 소스(CIDR 범위)입니다. 인바운드 규칙에만 적용됩니다.
• 대상 위치 - 트래픽 대상 위치(CIDR 범위)입니다. 아웃바운드 규칙에만 적용됩니다.
• 허용 또는 거부 - 지정된 트래픽을 허용할지 아니면 거부할지를 결정합니다.

네트워크 ACL은 상태 비저장입니다. 즉, 허용되는 인바운드 트래픽에 대한 응답은 아웃바운드 트래픽에 대한 규칙의 적용을 받습니다. 반대의 경우도 마찬가지입니다. 예를 들어, 인바운드 트래픽이 허용되는 경우, 아웃바운드 트래픽도 허용됩니다. 반대의 경우도 마찬가지입니다.

네트워크 ACL은 상태 비저장이기 때문에, 트래픽의 흐름을 보다 세밀하게 제어할 수 없습니다. 또한 트래픽에 규칙을 낮은 번호에서 높은 번호로 하나하나 대조하기 때문에 여러 규칙을 설정하면 속도가 느려질 수 있습니다. 그러나 네트워크 ACL은 간단하고 사용하기 쉽기 때문에, VPC의 리소스에 대한 액세스를 제어하는 데 유용한 도구입니다.

인바운드? 아웃바운드?
인바운드는 들어오는 것을 의미하고, 아웃바운드는 나가는 것을 의미합니다. 인바운드 보안 그룹 규칙은 인스턴스로 들어오는 트래픽을 제어하는 데 사용되는 규칙입니다. 아웃바운드 보안 그룹 규칙은 인스턴스에서 나가는 트래픽을 제어하는 데 사용되는 규칙입니다.

자세한 내용

보안 그룹

NACL이 서브넷에 적용됐다면 보안 그룹은 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다. 또 다른 점은 NACL과 달리 거부 규칙이 지원되지 않습니다. 기본 그룹은 동인한 그룹 내의 다른 구성원으로부터의 인바운드 통신과 모든 대상에 대한 아웃바운드 통신을 허용합니다. 트래픽은 IP 프로토콜, 서비스 포트 및 소스 또는 대상 IP 주소를 기준으로 제한할 수 있습니다.

가정용 컴퓨터에서 인스턴스에 대해 ICMP(Internet Control Message Protocol) ping 명령을 실행한다고 가정해 봅시다. 인바운드 보안 그룹 규칙에서 ICMP 트래픽을 허용하는 경우 포트 정보를 포함한 연결 정보가 추적됩니다. ping 명령에 대한 인스턴스의 응답 트래픽은 새 요청으로 추적되지 않으며 설정된 연결로 추적됩니다. 즉, 컴퓨터가 핑에 응답하면 응답에 대한 새 레코드를 만들지 않고 기존 레코드에 응답 정보를 추가합니다. 그러므로 아웃바운드 보안 그룹 규칙에서 아웃바운드 ICMP 트래픽을 제한하더라도 해당 트래픽을 인스턴스 외부로 전송할 수 있습니다.

ICMP는 인터넷에서 에러 메시지를 전송하는 데 사용되는 프로토콜입니다. 그리고 ping 명령은 ICMP를 사용하여 다른 컴퓨터의 연결 상태를 확인하는 데 사용되는 명령입니다.

하지만 모든 트래픽 흐름이 추적되는 것은 아닙니다. 보안 그룹 규칙이 모든 트래픽(0.0.0.0/0)을 대상으로 TCP/UDP을 허용할 수 있습니다. 다른 방향에도 응답 트래픽을 허용하는 해당 규칙이 있으면 해당 트래픽 흐름은 추적되지 않습니다. 따라서 응답 트래픽은 응답 트래픽을 허용하는 인바운드 또는 아웃바운드 규칙을 기준으로 흐름이 허용되며, 추적 정보에 포함되지 않습니다.

예를 들어, 인바운드 보안 그룹 규칙에서 모든 트래픽(0.0.0.0/0)을 대상으로 TCP/UDP을 허용하는 경우, 인스턴스로 들어오는 모든 TCP/UDP 트래픽이 허용됩니다. 아웃바운드 보안 그룹 규칙에서 모든 트래픽(0.0.0.0/0)을 대상으로 TCP/UDP을 허용하는 경우, 인스턴스에서 나가는 모든 TCP/UDP 트래픽이 허용됩니다.

이러한 규칙이 모두 허용되는 경우, 인스턴스로 들어오는 모든 TCP/UDP 트래픽은 허용되고, 인스턴스에서 나가는 모든 TCP/UDP 트래픽은 허용됩니다. 그러나 인바운드 보안 그룹 규칙에서 모든 트래픽(0.0.0.0/0)을 대상으로 TCP/UDP을 허용하고, 아웃바운드 보안 그룹 규칙에서 특정 IP 주소에서 들어오는 TCP/UDP 트래픽만 허용하는 경우, 인스턴스로 들어오는 모든 TCP/UDP 트래픽은 허용되지만, 인스턴스에서 나가는 TCP/UDP 트래픽은 특정 IP 주소로만 허용됩니다.

이러한 규칙을 사용하여 인스턴스로 들어오는 트래픽과 인스턴스에서 나가는 트래픽을 보다 세밀하게 제어할 수 있습니다.

기본 VPC 보안 그룹 설정

기본  VPC를 사용하여 생성한 보안 그룹은 모든 아웃바운드 트래픽을 허용하는 아웃바운드 규칙이 포함돼 있습니다. 이  때 기본 VPC 보안 그룹 설정으로 들어가 해당 규칙을 제거하고 특정 아웃바운드  트래픽만 허용하는 아웃바운드 규칙을 추가할 수 있습니다. 보안 그룹에 아웃바운드 규칙이 없는 경우, 인스턴스에서 시작되는 아웃바운드 트래픽이 허용되지 않습니다. 프로토콜, 서비스 포트 및 소스 IP 주소 또는 보안 그룹을 기준으로 트래픽을 제한할 수 있습니다.

보안 그룹은 다른 클래스의 인스턴스에 대해 서로 다른 규칙을 설정하도록 구성할 수 있습니다. 기존 3 티어 웹 애플리케이션(WEB, WAS, DB)의 경우를 예로 들어 보겠습니다.

• 웹 서버 그룹: 포트 80(HTTP) 또는 443(HTTPS)이 인터넷에서 액세스 가능하도록 설정
• 애플리케이션 서버 그룹: 포트 8000(앱마다 차이가 있을 수 있습니다)이 웹 서버 그룹만 액세스 가능하도록 설정
• 데이터 베이스 서버 그룹: 포트 3306(MySQL)이 애플리케이션 서버 그룹만 액세스 가능하도록 설정

세 그룹 모두 포트 22(SSH)에 대한 관리 액세스는 허용하지만, 고객의 회사 네트워크에서만 이 포트에 액세스할 수 있습니다. 이러한 매커니즘을 통해 매우 안전한 애플리케이션을 배포할 수 있게 됩니다.

트래픽이 상위 티어에서 하위 티어로만 흐른 후 다시 반대로 흐를 수 있도록 인바운드와 아웃바운드 규칙이 설정되야 합니다. 보안 그룹은 특정 티어의 보안 위반 시 손상된 클라이언트가 서브넷 전체에서 모든 리소스에 자동으로 액세스할 수 있게 되는 현상을 방지하는 방화벽 역할을 합니다.

자세한 설명

사용자 정의 보안 그룹 규칙

보안 그룹 규칙을 사용하면 프로토콜 및 포트 번호를 기준으로 트래픽을 필터링할 수 있습니다. 보안 그룹은 상태 저장 그룹입니다. 즉, 인스턴스에서 요청을 전송하면 인바운드 보안 그룹 규칙에 관계없이 해당 요청의 응답 트래픽 수신이 허용됩니다.

다중 방어 계층이 있는 인프라 설계

다중 방어 계층으로 인프라를 보호하는 것이 모범 사례라고 할 수 있습니다. 인터넷 게이트웨이와 라우팅 테이블이 적절하게 구성된 VPC에서 인프라를 실행하면서 인터넷에 노출되는 인스턴스를 제어할 수 있습니다. 또한 보안 그룹과 네트워크 ACL을 정의하여 인터페이스 및 서브넷 수준에서 인프라를 추가로 보호할 수도 있습니다. 뿐만 아니라 운영 체제 수준에서 방화벽으로 인스턴스를 보호하고 다른 보안 모범 사례도 준수해야 합니다.

AWS 고객은 대개 보안 그룹을 프라이머리 네트워크 패킷 필터링 방법으로 사용합니다. 보안 그룹은 네트워크 ACL에 비해 더욱 다양하게 활용할 수 있습니다. 상태 저장 패킷 필터링을 수행할 수 있으며, 다른 보안 그룹을 참조하는 규칙을 사용할 수 있기 때문입니다. 반면 네트워크 ACL은 특정 트래픽 하위 집합을 거부하거나 서브넷용으로 대략적인 가드레일을 제어하는 등의 보조 제어 기능으로 사용하면 효율적입니다.

네트워크  ACL과 보안 그룹을 모두 심층 방어 수단으로 구현하면 이러한 컨트롤 중 한가지를 잘못 구성하더라도 호스트가 예기치 못한 트래픽에 노출되지 않습니다.

프라이머리 네트워크 패킷 필터링?
프라이머리 네트워크 패킷 필터링 방법은 네트워크에서 전송되는 패킷을 필터링하는 방법 중 하나입니다. 프라이머리 네트워크 패킷 필터링 방법은 패킷의 소스 IP 주소, 목적지 IP 주소, 프로토콜, 포트 번호 등을 기준으로 패킷을 필터링합니다.

프라이머리 네트워크 패킷 필터링 방법은 네트워크의 보안을 강화하는 데 사용됩니다. 예를 들어, 프라이머리 네트워크 패킷 필터링 방법을 사용하여 특정 IP 주소에서 들어오는 패킷을 차단하거나 특정 프로토콜을 사용하는 패킷을 차단할 수 있습니다.

프라이머리 네트워크 패킷 필터링 방법은 네트워크의 성능을 저하시키는 단점이 있습니다. 프라이머리 네트워크 패킷 필터링 방법은 패킷을 하나하나 검사하기 때문에 네트워크의 트래픽이 많아지면 성능이 저하될 수 있습니다.

프라이머리 네트워크 패킷 필터링 방법은 네트워크의 보안을 강화하는 데 유용한 방법이지만, 네트워크의 성능을 저하시키는 단점이 있습니다. 따라서, 프라이머리 네트워크 패킷 필터링 방법을 사용할 때는 네트워크의 보안과 성능을 모두 고려해야 합니다.

상태 저장 패킷 필터링?
상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링의 한 종류입니다. 상태 저장 패킷 필터링은 패킷의 소스 IP 주소, 목적지 IP 주소, 프로토콜, 포트 번호뿐만 아니라 패킷의 흐름 상태를 고려하여 패킷을 필터링합니다.

상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링보다 보안이 뛰어납니다. 프라이머리 네트워크 패킷 필터링은 패킷의 흐름 상태를 고려하지 않기 때문에, 공격자가 패킷의 흐름 상태를 조작하여 보안을 우회할 수 있습니다.

상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링보다 성능이 좋은 만큼 네트워크의 성능을 더 저하시킨다는 단점이 있습니다. 상태 저장 패킷 필터링은 패킷의 흐름 상태를 저장하고 관리하기 때문에 네트워크의 트래픽이 많아지면 성능이 저하될 수 있습니다. 따라서, 상태 저장 패킷 필터링을 사용할 때는 네트워크의 보안과 성능을 모두 고려해야 합니다.

보안 그룹과 NACL 비교 정리

기본 VPC

각 AWS 계정에는 즉시 사용 가능하도록 미리 구성된 기본 VPC가 포함되어 있습니다. 기본 VPC를 사용하면 블로그나 간단한 웹 사이트 등을 빠르게 시작할 수 있으며 퍼블릭 인스턴스도 쉽게 시작할 수 있습니다.

기본 VPC는 /16의 CIDR를 가지고 있고 기본 서브넷은 /20의 CIDR를 가지고 있습니다. 

탄력적 IP(EIP)

탄력적 IP 주소는 동적 클라우드 컴퓨팅을 위해 설계된 정적 퍼블릭 IPv4 주소입니다. 계정의 어떤 VPC에 대해서든 탄력적 IP 주소를 인스턴스 또는 네트워크 인터페이스와 연결할 수 있습니다. 탄력적 IP 주소를 사용하면 주소를 VPC의 다른 인스턴스에 신속하게 다시 매핑하여 인스턴스의 장애를 마스킹할 수 있습니다.

예를 들어 인스턴스의 퍼블릭 IP는 중지 후 다시 켜지면 다른 퍼블릭 IP가 지정됩니다. 때문에 이와 연결된 정보를 변경해야 하는 번거로움이 있습니다. 이럴 때 EIP를 적용해 재시작하더라도 동일한 IP가 적용되도록 해줄 수 있습니다.

하나의 인스턴스에서 다른 인스턴스로 EIP를 이전할 수 있습니다. EIP 주소는 VPC의 인터넷 게이트웨이를 통해 액세스 할 수 있습니다. VPC와 네트워크 간에 VPN 연결을 설정한 경우 VPN 트래픽은 인터넷 게이트웨이가 아닌 가상 프라이빗 게이트웨이를 통과하기 때문에 EIP  주소를 액세스 할 수 없습니다.

EIP는 5개로 제한됩니다. 이를 절약하기 위해 NAT 디바이스를 사용할 수 있습니다. 인스턴스 장애 발생 시 주소를 다른 인스턴스로 다시 매핑할 수 있도록 주로 탄력적 IP 주소를 사용하는 것이 좋습니다. 그 외의 ㅁ ㅗ든 노드 간 통신에는 도메인 이름 시스템(DNS) 호스트 이름을 사용합니다.

고유 IP 주소 가져오기(BYOIP)를 만들 수 있지만 여기에는 상당한 추가 구성이 필요합니다.

탄력적 네트워크 인터페이스

탄력적 네트워크 인터페이스는 VPC 에서 가상 네트워크 카드를 나타내는 논리적 네트워킹 구성 요소입니다.

EC2에서는 네트워크 인터페이스를 생성하여 인스턴스에 연결할 수 있으며 인스턴스에서 해당 인터페이스를 분리한 후 다른 인스턴스에 연결할 수도 있습니다. 새 인스턴스로 이동하면 네트워크 인터페이스의 퍼블릭 및 EIP 주소, 프라이빗 IP 및 EIP 주소, MAC 주소가 유지됩니다. 네트워크 인터페이스의 속성은 이를 따릅니다.

네트워크 인터페이스를 인스턴스 간에 이동하면 네트워크 트래픽이 새 인스턴스로 리디렉션 됩니다. VPC의 각 인스턴스에는 프라이머리 네트워크 인터페이스가 있습니다.

각 인스턴스에는 VPC의 IP 주소 범위에서 프라이빗 IP 주소가 할당됩니다. 프라이머리 네트워크 인터페이스는 인스턴스에서 분리할 수 없습니다. 추가 네트워크 인터페이스를 생성하여 연결할 수 있습니다. 다음 태스크를 수행하려는 경우 인스턴스 하나에 여러 네트워크 인터페이스를 연결하면 유용합니다.

• 관리 네트워크 생성
• VPC에서 네트워크 및 보안 어플라이언스 사용
• 워크로드 또는 역할이 서로 다른 서브넷에 있는 이중 홈 인스턴스 생성
• 저비용 고가용송 솔루션 생송

특정 서브넷의 네트워크 인터페이스를 같은 VPC 내 다른 서브넷의 인스턴스에 연결할 수 있습니다. 단, 이경우 두 네트워크 인터페이스와 인스턴스가 같은 가용 영역에 있어야 합니다. 이 제한으로 인해 다른 가용 영역으로 트래픽을 리디렉션 하려는 재해 복구(DR) 시나리오에서는 네트워크 인터페이스 사용 가능 범위가 제한됩니다.

NAT 게이트웨이를 통한 Network Address Translation(NAT)

NAT에서는 메시지의 특정 IP 주소가 다른 주소에 매핑됩니다. 사용되는 IP 주소 보호를 위해 NAT를 사용합니다. NAT에서는 프라이빗 IP 주소가 퍼블릭 IP 주소에 매핑되므로 NAT를 사용하면 프라이빗 IP 주소의 인터넷연결을 허용할 수 있습니다. 라우터 등의 단일 디바이스를 인터넷(퍼블릭 네트워크)과 로컬 네트워크(프라이 빗네트워크) 간의 에이전트로 사용할 수 있습니다.

NAT 게이트웨이를 통해 VPC의 인스턴스와 인터넷 간에 통신을 할 수 있습니다. NAT 게이트웨이는 기본적으로 수평적으로 확장되고 중복되며 가용성이 높습니다. NAT 게이트웨이는 서브넷 라우팅 테이블에서 인터넷 라우팅 가능한 트래픽에 대한 대상을 제공합니다.

• 프라이빗 서브넷의 인스턴스는 인터넷 또는 다른 AWS 서비스로의 아웃 바운드트래픽을 시작할 수 있습니다.
• AWS가 관리하는 NAT 게이트웨이 사용 시에는 프라이 빗인스턴스가 인터넷에서 전송되는인바운드 트래픽을 수신할 수 없습니다.

NAT 게이트웨이는 퍼블릭 서브넷과 프라이빗 서브넷에 모두 배치할 수 있습니다. NAT 게이트웨이를 더 많이 제어해야 하는 경우 EC2 인스턴스에 NAT 게이트웨이를 설치하여 NAT 인스턴스를 생성할 수 있습니다. 또한 CIDR 범위가 겹치더라도 프라이빗 NAT 게이트웨이를 사용하여 네트워크 간 통신을 원활하게 진행할 수 있습니다.

인터넷에 프라이빗 서브넷 연결

프라이빗 서브넷 인스턴스와 인터넷 또는 기타 AWS 서비스 간의 단방향 연결에 NAT 게이트웨이를 사용할 수 있습니다. 이러한 유형의 연결에서는 외부 트래픽이 프라이빗 인스턴스와 연결될 수 없습니다.

• 프라이빗 서브넷용 라우팅 테이블은 모든 IPv4 인터넷 트래픽을 NAT 게이트웨이로 전송합니다.
• NAT 게이트웨이는 프라입시 서브넷에서 전송되는 트래픽용 소스 IP 주소로 탄력적 IP 주소를 사용합니다.
• 퍼블릭 서브넷용 라우팅 테이블은 몯느 인터넷 트래픽을 인터넷 게이트웨이로 전송합니다. IPv6에서는 지원하지 않는 기능입니다.

여러 가용 영역에서 VPC 배포

여러 가용 영역에 VPC를 배포하면 생성되는 아키텍처에서는 데이터 보안을 유지하면서 트래픽을 분사하는 방식으로 고가용성이 보장됩니다. 가용 영역 하나의 작동이 중단되면 다른 가용 영역으로 장애 조치할 수 있습니다.

이 구조를 통해 인스턴스에 접근은 가능하지만 인스턴스의 IP를 알 수는 없습니다. 이와 같이 인스턴스나 DB같은 중요 서비스들은 프라이빗 존에 배치하고 외부에서 접근만 가능하도록 아키텍처를 구성하는 것이 바람직합니다. 로드 벨런서에 대해서는 차후에 자세히 알아보도록 하겠습니다.

AWS VPC(Virtual Private Cloud)

Amazon VPC는 클라우드의 네트워크 환경입니다. 이를 통해 사용자가 정의한 가상 네트워크 안에서 AWS 리소스를 시작할 수 있습니다. VPC는 AWS 리전 중 하나에 배포되며, 해당 리전 내의 어떤 가용 영역에서나 리소스를 호스트할 수 있습니다.

VPC는 다음과 같은 사용자 환경과 해당 리소스의 격리에 대한 제어 기능을 제공합니다. VPC로 다음과 같은 작업을 수행할 수 있습니다.

• 원하는 IP 주소 범위 선택
• 서브넷 생성
• 라우팅 테이블과 네트워크 게이트웨이 구성

VPC 상세 내용

서브넷

서브넷은 VPC 내의 IP 범위입니다. 지정된 서브넷으로 AWS 리소스를 시작할 수 있습니다. 인터넷에 연결되어야 하는 리소스에는 퍼블릭 서브넷을 사용하고, 인터넷에 연결되지 않는 시소스에는 프라이빗 서브넷을 사용해야 합니다. 서브넷은 하나의 가용 영역 안에 포함됩니다.

각 서브넷  CIDR 블록에서 처음 4개와 마지막 IP 주소는 사용할 수 없습니다. 이에 대한 내용은 이전 포스팅에서 확인할 수 있습니다.

퍼블릭 서브넷(Public Subnet)

퍼블릭 서브넷 구성에는 양방향(초대됨/초대되지 않음)으로 트래픽 흐름을 허용합니다. 자동 아웃바운드 라우팅은 적용되지 않으므로 서브넷은 퍼블릭으로 구성해야 합니다.

퍼블릭 서브넷에 필요한 항목은 다음과 같습니다.

• 인터넷 게이트웨이(IG, Internet Gateway): VPC의 리소스와 인터넷 간 통신을 허용합니다.
• 라우팅 테이블(Route Table): 네트워크 트래픽이 전달되는 위치를 결정하는 데 사용되는 규칙(경로) 집합을 포함합니다. 인터넷 게이트웨이로 트래픽을 전송할 수 있습니다.
• 퍼블릭 IP 주소: 인터넷에 액세스 할 수 있는 주소입니다. 퍼블릭 IP 주소 사용 시에는 프라이빗 IP 주소를 모호화할 수 있습니다.

모호화는 어떤 것을 흐리게 하거나, 불명확하게 만드는 것을 말합니다. 퍼블릭 IP 주소를 사용하면 프라이빗 IP 주소를 모호화할 수 있습니다. 즉, 퍼블릭 IP 주소로 프라이빗 IP 주소에 접근할 수 있지만, 프라이빗 IP 주소를 직접 알 수는 없습니다.

프라이빗 서브넷(Private Subnet)

프라이빗 서브넷은 인터넷 간접적으로 액세스를 허용합니다. 트래픽은 프라이빗 네트워크 내에 유지됩니다. EC2(Elastic Compute Cloud) 인스턴스의 네트워크 인터페이스에 새 IP 주소를 수동을 ㅗ배정하는 경우가 아니면 해당 EC2 인스턴스에 배정된 프라이빗 IP 주소는 변경되지 않습니다.

웹 티어 인스턴스는 퍼블릭 서브넷에 배치할 수 있습니다. 하지만 퍼블릭 서브넷에 배치된 로드 밸런서를 기반으로 프라이빗 서브넷 내에 웹 티어 인스턴스를 배치하는 것이 좋습니다. 즉, 서비스는 모두 프라이빗 공간에서 작동시키고 다른 수단을 사용해 연결해주는 것입니다.

인터넷 게이트웨이(Internet Gateway)

인터넷 게이트웨이(이하 IG)는 수평적으로 확장되고 중복적인 고가용성 VPC 구성 요소로, VPC 내 인스턴스와 인터넷 간 통신을 허용합니다. 따라서 네트워크 트래픽에 가용성 위험이나 대역폭 제약이 발생하지 않습니다.

* 수평적 확장?
IG의 용량을 늘리기 위해 IG의 수를 늘리는 것을 말합니다. IG가 수평적으로 확장되기 때문에, VPC의 트래픽이 증가하더라도 IG의 용량을 쉽게 늘릴 수 있습니다.

* 고가용성?
IG가 장애가 발생하더라도 계속 작동할 수 있도록 IG를 여러 개로 복제하는 것을 말합니다. IG가 고가용성을 갖추고 있기 때문에, IG 중 하나가 장애가 발생하더라도 다른 IG가 계속 작동하여 VPC의 가용성을 유지할 수 있습니다.

IG는 다음 2 가지 목적을 위해 사용됩니다.

1. 인터넷 라우팅 가능 트래픽용(인터넷으로 향하는 트래픽)으로 라우팅 테이블에서 대상 제공합니다.

서브넷은 기본적으로 아웃바운드 트래픽을 허용하지 않습니다. VPC는 라우팅 테이블을 사용하여 트래픽을 라우팅할 위치를 결정합니다. VPC가 인터넷 트래픽을 라우팅하도록 허용하려면 인터넷 게이트웨이를 대상 또는 대상 위치로 지정하여 라우팅 테이블에 아웃바운드 경로를 생성합니다.

2.  NAT를 수행하여 네트워크 IP 주소 보호

인터넷에 연결하는 네트워크의 리소스는 두 가지 종류의 IP 주소를 사용해야 합니다.

• 프라이빗 IP: 프라이빗 네트워크 내의 통신에는 프라이빗 IP를 사용합니다. 이러한 주소는 인터넷을 통해 연결할 수 없습니다.
• 퍼블릭 IP:  VPC의 리소스와 인터넷 간의 통ㅅ니에는 퍼블릭 IP 주소를 사용합니다. 퍼블릭 IP 주소는 인터넷을 통해 연결할 수 있습니다.

NAT?
NAT는 Network Address Translation의 약자로, 네트워크 주소 변환을 의미합니다. NAT는 하나의 공인 IP 주소를 여러 개의 사설 IP 주소로 변환하여 사용하는 기술입니다.

인터넷 게이트웨이는 퍼블릭 IP 주소와 프라이빗 IP 주소를 매핑하여 NAT를 수행합니다. 

라우팅 테이블

라우팅 테이블은 VPC가 네트워크 트래픽이 전달되는 위치를 결정하는 데 사용되는 규칙 세트(경로)를 포함합니다. VPC를 생성하면, 자동으로 기본 라우팅 테이블이 생성됩니다. 처음에는 기본 라우팅 테이블에 단일 경로만 포함돼 있습니다. 이 로컬 경로는 VPC 내의 모든 리소스에 대해 통신을 허용합니다. 라우팅 테이블의 로컬 경로는 수정할 수 없습니다. VPC에서 인스턴스를 시작할 때마다 로컬 경로는 그 인스턴스를 자동으로 포함합니다. VPC에 대한 사용자 지정 라우팅 테이블을 추가로 생성할 수 있습니다.

VPC 내의 각 서브넷은 라우팅 테이블과 연결되어야 합니다. 서브넷을 특정 라우팅 테이블과 명시적으로 연결하지 않는 경우, 서브넷은 암시적으로 기본 라우팅 테이블과 연결되어 이를 사용합니다. 서브넷은 한 번에 하나의 라우팅 테이블에만 연결할 수 있지만, 여러 서브넷을 같은 라우팅 테이블에 연결할 수 있습니다. 각 서브넷에 대한 사용자 지정 라우팅 테이블을 사용하여 대상 위치에 대해 세부적인 라우팅을 허용합니다.

상세한 내용

IP 주소

IP 주소는 네트워크 내의 리소스 로케이션에 대한 정보를 포함합니다. 주소의 한 부분은 네트워크를 식별하고 다른 부분은 호스트를 식별합니다.

예시 - 172.50(네트워크 식별).2.15(호스트 로케이션 식별)

IP 주소에는 IPv4와 IPv6가 있습니다.

• IPv4
  32비트의 주소 체계를 사용합니다. 8개의 비트(옥텟) 집합을 4개를 사용합니다.
  [Ex_10.10.10.10]
  
  
• IPv6
  IPv4의 개수가 부족해 개발된 주소입니다. 128비트 주소 체계를 사용합니다. 16진수 숫자 4개로 구성된 8개의 그룹으로 사용합니다. 보통 자동으로 부여해 사용합니다.
  [Ex_50b2:6400:0000:0000:0000:6c3a:b17d:0:10a9  =  50b2:6400::6c3a:b17d:0:10a9]

CIDR(Classless Inter-Domain Routing)

CIDR 표기법에 따라 네트워크나 서브넷의 IP 주소 범위를 정의합니다. 이 범위를 CIDR 브록이라고 합니다.AWS VPC 구성 요소를 사용하여네트워크를 구축할 때 VPC와 서브넷용 CIDR 블록을 지정합니다. 네트워크의 리소스를 지원하기에 충분한 IP 주소를 할당해야 합니다. VPC에는 최대 CIDR 블록이 있을 수 있으며 CIDR 블록의 주소 범위는 중복될 수 없습니다.

CIDR 블록에서는 숫자와 점을 사용하는 표기법으로 네트워크를 식별합니다. 그리고 슬래시 표기법으로 서브넷 마스크를 지정합니다. 서브넷 마스크는 IP 주소에서 네트워크 식별 전용 부분과 호스트 IP 주소용으로 사용 가능한 부분을 정의합니다. 예를 들어 IPv4 주소에서는 32 비트가 옥텟 4개로 분할됩니다. 서브넷 마스크가 /16인 경우 첫 16비트(2옥텟)가 네트워크 식별용으로 예약되고 나머지 16비트가 호스트 식별에 사용됩니다.

블로그 초창기에 작성했던 IP 주소에 관한 포스팅 있으니 참고하면 더 도움이 될 것입니다.

CIDR에 따른 총 IP 개수는 어떻게 계산 할 수 있을까요? [2^(32-CIDR)]로 계산하면 간단하게 알 수 있습니다.

하지만 이렇게 부여된 IP를 모두 사용할 수 있는 것은 아닙니다. 다음과 같은 이유로 기본적으로 3개가 예약됩니다.

• IP의 처음 주소 : 네트워크 주소
• IP의 마지막 주소 : 네트워크 브로드캐스트 주소
• 게이트 웨이 주소(선택)

AWS에서는 다음과 같은 이유로 처음 4개와 마지막 주소, 총 5가지가 미리 예약됩니다.

• XX.XX.0.0: 네트워크 주소
• XX.XX.0.1: VPC 라우터용
• XX.XX.0.2: AWS에서 예약(DNS 서버의 IP 주소는 항상 VPC 네트워크 범위의 기본 IP 주소에 2를 더한 값입니다.)
• XX.XX.0.3: 차후 사용을 위해 AWS에서 예약
• XX.XX.0.255: 네트워크 브로드캐스트 주소(VPC에서는 브로드캐스트가 지원되지 않아 이 주소를 예약할 수 있습니다.)

Amazon VPC에서는 IPv4, IPv6를 둘 다 지원하고, CIDR 블록 크기 제한이 존재합니다. 기본적으로 IPv4를 포함해야 합니다. 즉, IPv4와 IPv6를 함께 사용해 이중 스택 VPC와 연결할 수 있지만, IPv6만 사용할 수는 없습니다. 또한 CIDR는 IPv4에서는 /28~/16 사이로 지정할 수 있고, IPv6에서는 /64로 고정됩니다.