온디맨드 온디맨드 인스턴스를 사용하면 장기 약정 없이 컴퓨팅 용량 비용을 초나 시간 단위로 지불할 수 있습니다. 온디맨드 인스턴스는 중단할 수 없는 불규칙한 단기 워크로드가 있는 앱에 가장 적합합니다. 또한 처음에 온디맨드 방식을 선택해 사용량에 따라 요구 사항을 확인할 수도 있습니다. 온디맨드의 특징은 다음과 같습니다.
장기 약정 X
선결제 금액 X
애플리케이션 수요에 따라 컴퓨팅 용량을 늘리거나 줄일 수 있습니다.
Saving Plans 예약형 인스턴스 보다는 아래의 플랜을 통해 인스턴스 요금 할인을 받는 것이 더욱 현명합니다. Saving Plans의 유형은 다음과 같습니다.
Compute Savings Plans 최대 유연성을 제공하는 플랜입니다. 온디맨드 요금의 최대 66% 할인 혜택을 받을 수 있습니다. 이 플랜은 인스턴스 패밀리, 규모, 리전, 가용 영역, OS 또는 테넌시에 관계없이 EC2 인스턴스 사용량에 자동으로 적용됩니다. 또한 Fargate 및 Lambda에도 적용됩니다.
이 플랜을 통해 워크로드를 C5에서 M5로 이동하거나, 아일랜드에서 런든으로 전환할 수 있습니다. 또한 언제든지 Fargate를 사용하여 앱을 EC2에서 ECS로 마이그레이션할 수도 있습니다.
EC2 Instance Savings Plans 선택한 AWS 리전에서 특정 인스턴스 패밀리 사용 약정을 체결하면 온디맨드 요금의 최대 72% 할인 혜택을 받을 수 있습니다. 그럼 해당 리전의 지정된 패밀리 내 인스턴스를 사용할 때 이러한 요금제가 자동 적용됩니다. 가용영역, 크기, OS 또는 테넌시에 관계없이 해당 요금제가 적용됩니다.
이 플랜을 통해 인스턴스 패밀리 또는 OS 내의 인스턴스 크기를 변경할 수 있습니다. 전용 테넌시에서 기본으로 전환할 수도 있으며, 이 경우에도 해당 플랜에서 제공되는 할인 혜택을 계속 제공 받을 수 있습니다.
EC2 스팟 인스턴스 스팟 인스턴스는 여분의 EC2 용량을 저렴하게 사용할 수 있는 인스턴스입니다. 스팟 인스턴스 사용 시에는 비용을 온디맨드 인스턴스 요금 대비 최대 90%까지 절약할 수 있습니다. 스팟 인스턴스에서는 대폭 할인된 요금으로 미사용 EC2 인스턴스를 요청할 수 있으므로, 유동적으로 수행할 수 있는 워크로드에서 EC2 비용을 절약할 수 있습니다.
스팟 인스턴스의 시간당 요금을 스팟 요금이라고 하는데, 각 가용 영역 내 인스턴스 유형의 스팟 요금은 EC2에 의해 설정됩니다. 이 욕므은 스팟 인스턴스의 장기적인 수요와 공급에 따라 점진적으로 조정됩니다. 사용자가 요청한 최고가가 스팟 요금보다 높으면 사용 가능한 용량이 있을 때마다 스팟 인스턴스가 실행됩니다.
현재 최고가에서 요청에 사용 가능한 용량이 현재 없으면 인스턴스가 중단됩니다. 이 경우 이벤트 2분 전에 알림을 받게 됩니다.
예상 범위 내에서 처리량을 10배까지 늘려 원하는 결과를 더욱 빠르게 달성할 수 있습니다. 그리고 다양한 유형, 크기, 가용 영역 중에서 선택해 인스턴스를 다양한 방식으로 설정할 수 있습니다. ECS, Batch EMR 등 AWS 서비스나 통합 서드 파티를 통해 스팟 인스턴스를 시작할 수 있습니다.
내결함성을 갖춘 워크로드, 유동적 워크로드, 느슨하게 결합된 워크로드, 상태 비저장 워크로드에서 스팟 인스턴스를 사용하기 적합합니다. 몇 가지 일반적인 사용 사례는 다음과 같습니다.
이미지/미디어 렌더링 온프레미스 또는 클라우드 렌더링 워크로드를 비용 효율적으로 관리하고 크기를 조정할 수 있으며, 용량도 사실상 무제한으로 사용할 수 있습니다.
웹 서비스 로드 벨런서를 통해 EC2 스팟 플릿을 배포하면 수만 개 인스턴스로 확장하여 서비스 요청 수십억 개를 처리할 수 있습니다.
빅 데이터 및 분석 스팟 인스턴스를 통해 빅 데이터, 기계 학습 및 자연어 처리(NLP) 워크로드를 빠르게 실행할 수 있습니다. 스팟 인스턴스를 사용할 때에는 시간을 엄수해야 하는 초대형 워크로드를 대규모로 빠르게 실행하여 데이털르 신속하게 분석하면서 비용도 대폭 절약할 수 있습니다.
이 외에도 컨테이너화된 워크로드, CI/CD(지속 통합/지속 배포) 및 테스트, HPC(고성능 PC)에서 사용하기 좋습니다.
구매 옵션 조합
예산을 최대한 효율적으로 활용하기 위해 EC2 인스턴스 구매 전략을 작성해야 합니다.
Saving Plans를 사용해 정의된 컴퓨팅 요구를 기준으로 예산을 책정합니다. 컴퓨팅 비용은 고정비에 가까워 금액이 일정합니다.
장애 발생 상황이나 단기적으로 용량을 사용할 수 없는 상황을 고려하는 유동적인 워크로드를 대상으로 Spot Instance를 시작합니다.
EBS 볼륨은 EC2 인스턴스를 위해 안정적이고 분리 가능한 블록 수즌 스토리지를 제공합니다. EBS 볼륨은 인스턴스에 탑재되므로 데이터가 저장된 위치와 인스턴스에서 사용되는 위치 간에 매우 짧은 지연 시간은 제공할 수 있습니다. 이런 이유로 EBS 볼륨은 EC2 인스턴스를 사용해 DB를 싱행하는데 사용할 수 있습니다.
데이터의 특정 시점 복사본으로 EBS 스냅샷을 생성할 수 있습니다. AMI의 데이터를 저장하는 데 사용됩니다. 스냅샷은 S3에 보관되며 나중에 새 EC2 인스턴스를 생성하는 데 재사용할 수 있습니다.
범용 SSD 볼륨(gp2, gp3)에서는 광범위한 사용 사례에 이상적인 비용 효율적인 스토리지를 제공합니다. 부팅 볼륨, 중소형 DB, 그래고 개발 및 테스트 환경에 이상적인 볼륨입니다.
프로비저닝된 IOPS 볼륨(io1, io2)은 I/O 집약적 워크로드를 충족하도록 설계되었습니다. 스토리지 성능과 일관성이 높아야 하는 데이터베이스 워크로드를 예로 들 수 있습니다. 프로비저닝된 IOPS SSD 볼륨은 일관된 IOPS 속도를 사용합니다. 볼륨을 생성할 때 속도를 지정할 수 있습니다. EBS에서는 전체 사용 시간 중 99.9% 동안 프로비저닝된 성능을 제공합니다.
IOPS? IOPS(Input/Output Operations Per Second)는 초당 입출력 작업 수입니다. IOPS는 스토리지의 성능을 나타내는 지표 중 하나입니다. IOPS가 높을수록 스토리지가 더 빠르게 데이터를 읽고 쓸 수 있습니다.
처리량 최적화 HDD 볼륨(st1)에서는 IOPS가 아닌 처리량을 기준으로 성능을 정의하는 저비용 마그네틱 스토리지를 제공합니다. 이 볼륨 유형은 EMR, 추출, 전환, 적재(ETL), 데이터 웨어하우스, 로그 처리 등의 대규모 순차 워크로드에 적합합니다.
콜드 HDD(sc1) 볼륨에서는 st1과 마찬가지로 저비용 마그네틱 스토리지를 제공하는데, sc1은 대규모 순차 콜드 데이터 워크로드에 적합합니다. sc1은 데이터에 자주 액세스하지 않는 경우 저렴한 블록 스토리지를 제공합니다.
M, C, R, T, X 패밀리의 140가지가 넘는 인스턴스 중에서 EC2 및 EC2 Auto Sacling 그룹에 가장 적합한 인스턴스를 선택할 수 있습니다.
Optimizer(옵티마이저)? 옵티마이저는 머신 러닝 모델의 가중치를 조정하는 알고리즘입니다. 가중치는 모델의 학습을 위해 중요한 요소입니다. 옵티마이저는 가중치를 조정하여 모델의 손실 함수의 값을 최소화합니다. 손실 함수는 모델의 예측이 실제 값과 얼마나 다른지를 나타내는 함수입니다. 옵티마이저는 손실 함수의 값을 최소화하기 위해 가중치를 조정합니다. 옵티마이저는 모델의 성능을 향상시키는 데 중요한 역할을 합니다.
시작 개인 계정, 관리 계정 또는 조직 내 모든 구성원 계정을 AWS Compute Optimizer에 옵트인합니다. Compute Optimizer는 기계 학습을 사용해 CloudWatch에서 제공되는 사용 데이터와 리소스의 현재 구성을 분석합니다. 구성과 사용량 분석 결과에 따라 권장 컴퓨팅이 제공됩니다.
서비스간 통합 권장 사항을 S3(Simple Storage Serivce)로 내보낼 수 있습니다. 그럼 Cost Explorer 및 Systems Manager와 권장 사항이 통합됩니다.
리소스 재구성 권장 사항을 사용해 비용을 줄이고 성능을 개선할 수 있도록 리소스를 재구성할 수 있습니다.
EC2 키 페어
프라이빗 키와 퍼블릭 키로 구성된 키 페어는 보안 자격 증명 세트입니다. 인스턴스에 연결할 때는 키 페어를 사용해 신원을 증명해야 합니다. 퍼블릭 키는 EC2에 저장되고 프라이빗 키는 사용자가 저장합니다. 암호 대신 프라이빗 키를 사용하여 인스턴스에 안전하게 액세스할 수 있습니다. 프라이빗 키를 소유한 모든 사용자는 인스턴스에 연결할 수 있으므로 프라입시 키는 안전한 곳에 저장해야합니다.
EC2 인스턴스 하드웨어 사용 방식
공유 테넌시 하드웨어를 공유하는 방식으로 EC2 인스턴스는 기본적으로 이 방식을 사용합니다. 따라서 여러 AWS 계정이 같은 물리적 하드웨어를 공유할 수 있습니다.
전용 인스턴스 호스트 하드웨어 수준에서 물리적으로 격리되는 EC2 인슽너스를 말합니다. 즉, 전용이 아닌 인스턴스와 다른 AWS 계정에 속하는 인스턴스로부터 격리됩니다.
전용 호스트 시작하는 인스턴스는 고객이 EC2 인스턴스 용량을 완전히 전용으로 사용하는 물리적 서버에서 실행됩니다. 사용자가 구성을 제어할 수 있는 격리된 서버가 제공됩니다. 전용 호스트에서는 AWS가 인스턴스를 배치할 서버를 자동으로 선택할 수 있는 옵션이 있습니다. 또는 인스턴스를 배치할 때 전용 서버를 사용자가 수동으로 선택할 수도 있습니다.
EC2 서비스는 상호 연관된 장애를 최소화하기 위해 기본 하드웨어 전체에 모든 인스턴스를 분산합니다. 배치 그룹을 사용하면 워크로드 요구를 충족하도록 상호 종속된 인스턴스 집합의 배치 방식을 결정할 수 있습니다.
클러스터 배치 그룹 낮은 네트워크 지연 시간, 높은 네트워크 처리량 또는 두 가지 요건이 모두 충족될 경우 혜택을 받는 애플리케이션일 때 사용을 권장합니다. 또한 대부분의 네트워크 트래픽이 그룹의 인스턴스 간에 전송되는 경우에도 권장됩니다. HPC 워크로드에는 VPC에 이 수준의 연결을 사용해야 할 수 있습니다.
분산 배치 그룹 서로 분리한 상태로 유지해야 하는 소수의 중요 인스턴스가 포함된 애플리케이션의 경우 사용을 권장합니다. 예를 들어 의료 기록 시스템과 같이 최대 가대 가동 시간이 필요한 서비스는 분산형 배치 그룹을 사용하면 내결함성을 높일 수 있습니다.
파티션 배치 그룹 대구모 분산 및 복제된 워크로드를 배포할 수 있습니다. 파티션을 사용하면 여러 구성 요소에서 하드웨어 장애가 동시에 발생하는 상황을 방지할 수 있습니다.
내결함성과 고가용성 내결함성(fault tolerance)은 시스템이 고장에 견딜 수 있는 능력을 말합니다. 가용성(availability)은 시스템이 사용 가능한 시간의 비율을 말합니다. 내결함성과 가용성은 서로 밀접하게 관련되어 있습니다. 내결함성이 높을수록 가용성도 높아집니다.
내결함성을 높이는 방법에는 여러 가지가 있습니다. 예를 들어, 시스템에 여러 개의 인스턴스를 만들고, 인스턴스를 서로 다른 서버에 배치할 수 있습니다. 이렇게 하면 한 인스턴스에 고장이 발생하더라도 다른 인스턴스가 계속해서 작동할 수 있습니다.
가용성을 높이는 방법에도 여러 가지가 있습니다. 예를 들어, 시스템에 장애 조치(failover) 기능을 추가할 수 있습니다. 장애 조치 기능은 한 인스턴스에 고장이 발생하면 다른 인스턴스로 자동으로 전환하는 기능입니다.
내결함성과 가용성은 시스템의 중요한 요소입니다. 내결함성과 가용성이 높을수록 시스템이 장애에 견딜 수 있고, 사용자에게 안정적으로 서비스를 제공할 수 있습니다.
EC2 인스턴스를 생성할 때 사용자 데이터를 인스턴스에 전달할 수 있는 옵션이 있습니다. 사용자 데이터는 인스턴스 시작 완료를 자동화할 수 있습니다. 예를 들어 인스턴스 AMI를 패치 및 업데이트하거나, 소프트웨어 라이센스 키를 가져와 설치하거나, 추가 소프트웨어를 설치할 수 있습니다. 사용자 데이터는 루트 또는 관리자 권한으로 실행되는 shell 스크립트나 cloud-init 지시문으로 구현됩니다. 이 스크립트/지시문은 인스턴스가 시작된 후 네트워크에서 해당 인스턴스 액세스가 가능해지기 전에 실행됩니다.
Linux : cloud-init Windows : EC2Launch
Bash 스크립트와 Powershell 스크립트 둘 다 지정할 수 있습니다. 그럼 인스턴스 사요자 데이터에서 표시되는 순서에 관계없이 Bash 스크립트가 먼저 실행된 후 Powershell 스크립트가 실행됩니다.
인스턴스 메타데이터
인스턴스 메타데이터는 실행 중인 인스턴스를 구성 또는 관리하는 데 사용할 수 있는 인스턴스 관련 데이터입니다. 인스턴스 메타데이터는 예를 들어 호스트 이름, 이벤트, 보안 그룹 등의 범주로 구분됩니다.
EC2는 가상 머신을 생성하고 실행하는 서비스입니다. EC2 인스턴스는 EC2 서버스에서 사용하는 가상 머신(VM)입니다. 기존의 온프라미스와 비슷하지만 클라우드 환경에서 제공된다는 차이가 있습니다. EC2는 웹 호스팅, 애플리케이션, DB, 인증 서비스 등 워크로드와 서비스가 제공할 수 있는 기타 모든 워크로드를 지원할 수 있습니다.
워크로드? 워크로드는 비즈니스 요구 사항을 지원하는 데 필요한 리소스 및 코드의 집합입니다. 워크로드는 고객 대면 애플리케이션, 백엔드 프로세스, 데이터베이스 및 기타 구성 요소와 같은 다양한 요소로 구성될 수 있습니다. 워크로드는 비즈니스 요구 사항을 지원하고 비즈니스 목표를 달성하는 데 사용됩니다.
AWS에서는 서버, DB, 스토리지 및 상위 수준의 애플리케이션 구성 요소를 몇 초 내에 인스턴스화할 수 있습니다. 즉, 고정된 IT 인프라의 제약 없이 이러한 구성 요소를 일회용 임시 리소스로 사용할 수 있습니다. 탄력적인 클라우드 컴퓨팅에서는 이과는 전혀 다른 방식으로 변경 관리, 테스트, 용량 계획을 수행하고 신뢰성을 보장할 수 있습니다.
인스턴스 시작 시 고려 사항
이름 및 태그 - 인스턴스 식별 방법
애플리케이션 및 OS(운영 체제) 이미지 - 부팅 시 시작할 항목
인스턴스 유형 및 크기 - CPU와 RAM, 스토리지의 용량(기술적 요구 사항)
인증 및 키 페어 - 인스턴스에 연결하는 방법
네트워크 설정 및 보안 - 사용할 VPC, 서브넷 및 보안 그룹
스토리지 구성 - 사용 사례에 가장 적합한 블록 스토리지 유형
배치 및 테넌시 - EC2 인스턴스를 실행할 위치
스크립트 및 메타데이터 - 시작을 자동화하기 위해 수행할 수 있는 작업
OS(운영 체제)? 운영 체제(OS)는 컴퓨터 하드웨어와 소프트웨어 간의 상호 작용을 관리하고 사용자가 컴퓨터를 사용할 수 있도록 하는 소프트웨어입니다. 운영 체제는 컴퓨터 하드웨어의 리소스를 관리하고, 사용자와 컴퓨터 하드웨어 간의 상호 작용을 관리하고, 소프트웨어를 실행하고 관리하는 역할을 합니다.
EC2 태그
AWS에서는 메타데이터를 태그 형태로 리소스에 할당할 수 있습니다. 각 태그는 고객 정의 키와 선택적 값으로 구성된 간단한 레이블입니다. 태그를 사용해 리소스를 필터링할 수 있습니다. 태그를 통해 리소스 액세스 제어를 관리하고 비용을 추적할 수 있으며, 태스크를 자동화하고 조직을 관리할 수 있습니다.
태그를 필수적으로 작성해야 하는 것은 아니지만 이를 활용해 용도, 소유자, 환경 또는 기타 기준을 정해 리소스를 분류할 수 있습니다. 태그의 키-값 페어는 대소문자를 구분하므로 정확히 일치하는 문자열을 사용해야 합니다.
예시 CLI(명령줄 인터페이스)로 "XXX 태그를 가지고 있는 인스턴스를 중지해줘" 작업이 가능합니다.
AMI는 클라우드의 가성 서버인 인스턴스를 시작할 때 필요한 정보를 제공합니다. 동일한 구성의 인스턴스가 여러 개 필요할 때는 한 AMI에서 여러 인스턴스를 시작할 수 있습니다. 서로 다른 구성의 인스턴스가 필요할 때는 다양한 AMI를 사용하여 인스턴스를 시작할 수 있습니다. 인스턴스를 시작할 때 소스 AMI를 지정합니다.
즉, 한 종류의 템플릿이라고 봐도 됩니다. 이러한 AMI는 직접 만들어서 사용할 수도 있습니다. AMI에 포함되는 속성은 다음과 같습니다.
인스턴스 루트 볼륨 템플릿(OS, APP, APP 서버)
어떤 AWS 계정이 해당 AMI를 사용하여 인스턴스를 시작할 수 있는지 제어하는 시작 허용 권한
시작될 때 인스턴스에 첨부할 볼륨을 지정하는 블록 디바이스 매핑
AMI를 받을 수 있는 수단
AWS에서 제공하는 사전 구축된 AMI 사용
AWS Marketplace에서 여러 솔루션이 포함된 카탈로그를 검색
AMI를 수동으로 직접 생성하거나 EC2 Image Builder 사용
AMI는 구매하거나 판매도 할 수 있습니다. AWS 사용자 커뮤니티나 Marketplace에 구매 혹은 자신의 AMI를 등록해 판매도 할 수 있고, 공유를 할 수도 있습니다. 이 때 게시자는 프로덕션에서 사용하는 시스템 이미지의 초기 보안 상태를 책임져야 합니다.
Graviton 프로세서는 여러 작은 인스턴스 간에 로드를 공유할 수 있는 스케일 아웃을 위해 제작
Graviton2 프로세서는 Arm Neoverse 코어를 사용해 클라우드 워크로드에서 가성비 증가
Graviton3 프로세서는 EC2 워크로드에서 가성비 증가
프로비저닝? 프로비저닝은 IT 인프라를 설정하고 관리하는 과정입니다. 프로비저닝에는 컴퓨터, 네트워크, 저장소, 보안 및 기타 IT 자산이 포함됩니다. 프로비저닝은 IT 자산을 생성하고, 구성하고, 배포하는 것을 포함합니다.
종량제 요금? 사용한 만큼만 지불하는 것을 뜻합니다.
런타임? 런타임(runtime)은 컴퓨터 프로그램이 실행되고 있는 동안의 동작을 말합니다. 런타임에는 프로그램의 실행을 관리하는 런타임 시스템이 포함됩니다. 런타임 시스템은 프로그램의 메모리 할당, 함수 호출, 오류 처리를 담당합니다. 런타임 시스템은 또한 프로그램의 성능을 향상시키기 위해 최적화를 수행할 수 있습니다.
런타임 환경? 런타임 환경(runtime environment)은 컴퓨터 프로그램이 실행되는 동안 필요한 코드, 라이브러리, 데이터 및 기타 리소스를 포함하는 환경입니다. 런타임 환경은 프로그램의 실행을 관리하고 프로그램이 정상적으로 실행되도록 보장합니다.
런타임 환경은 프로그램의 종류에 따라 다릅니다. 예를 들어, Java 프로그램의 런타임 환경은 Java Virtual Machine(JVM)입니다. JVM은 Java 프로그램이 실행되는 데 필요한 코드, 라이브러리 및 데이터를 포함합니다. JVM은 또한 Java 프로그램의 실행을 관리하고 프로그램이 정상적으로 실행되도록 보장합니다.
런타임 환경은 프로그램의 중요한 부분이며 프로그램의 안정성과 성능에 영향을 미칩니다. 런타임 환경을 잘 설계하고 구현하면 프로그램의 안정성과 성능을 향상시킬 수 있습니다.
네트워크 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)에 대한 관리 액세스는 허용하지만, 고객의 회사 네트워크에서만 이 포트에 액세스할 수 있습니다. 이러한 매커니즘을 통해 매우 안전한 애플리케이션을 배포할 수 있게 됩니다.
보안 그룹 연결 예시(WEB에는 로드 벨런서 등을 통해서 접속한다고 가정합니다)
트래픽이 상위 티어에서 하위 티어로만 흐른 후 다시 반대로 흐를 수 있도록 인바운드와 아웃바운드 규칙이 설정되야 합니다. 보안 그룹은 특정 티어의 보안 위반 시 손상된 클라이언트가 서브넷 전체에서 모든 리소스에 자동으로 액세스할 수 있게 되는 현상을 방지하는 방화벽 역할을 합니다.
보안 그룹 규칙을 사용하면 프로토콜 및 포트 번호를 기준으로 트래픽을 필터링할 수 있습니다. 보안 그룹은 상태 저장 그룹입니다. 즉, 인스턴스에서 요청을 전송하면 인바운드 보안 그룹 규칙에 관계없이 해당 요청의 응답 트래픽 수신이 허용됩니다.
다중 방어 계층이 있는 인프라 설계
다중 방어 계층으로 인프라를 보호하는 것이 모범 사례라고 할 수 있습니다. 인터넷 게이트웨이와 라우팅 테이블이 적절하게 구성된 VPC에서 인프라를 실행하면서 인터넷에 노출되는 인스턴스를 제어할 수 있습니다. 또한 보안 그룹과 네트워크 ACL을 정의하여 인터페이스 및 서브넷 수준에서 인프라를 추가로 보호할 수도 있습니다. 뿐만 아니라 운영 체제 수준에서 방화벽으로 인스턴스를 보호하고 다른 보안 모범 사례도 준수해야 합니다.
AWS 고객은 대개 보안 그룹을 프라이머리 네트워크 패킷 필터링 방법으로 사용합니다. 보안 그룹은 네트워크 ACL에 비해 더욱 다양하게 활용할 수 있습니다. 상태 저장 패킷 필터링을 수행할 수 있으며, 다른 보안 그룹을 참조하는 규칙을 사용할 수 있기 때문입니다. 반면 네트워크 ACL은 특정 트래픽 하위 집합을 거부하거나 서브넷용으로 대략적인 가드레일을 제어하는 등의 보조 제어 기능으로 사용하면 효율적입니다.
네트워크 ACL과 보안 그룹을 모두 심층 방어 수단으로 구현하면 이러한 컨트롤 중 한가지를 잘못 구성하더라도 호스트가 예기치 못한 트래픽에 노출되지 않습니다.
프라이머리 네트워크 패킷 필터링? 프라이머리 네트워크 패킷 필터링 방법은 네트워크에서 전송되는 패킷을 필터링하는 방법 중 하나입니다. 프라이머리 네트워크 패킷 필터링 방법은 패킷의 소스 IP 주소, 목적지 IP 주소, 프로토콜, 포트 번호 등을 기준으로 패킷을 필터링합니다.
프라이머리 네트워크 패킷 필터링 방법은 네트워크의 보안을 강화하는 데 사용됩니다. 예를 들어, 프라이머리 네트워크 패킷 필터링 방법을 사용하여 특정 IP 주소에서 들어오는 패킷을 차단하거나 특정 프로토콜을 사용하는 패킷을 차단할 수 있습니다.
프라이머리 네트워크 패킷 필터링 방법은 네트워크의 성능을 저하시키는 단점이 있습니다. 프라이머리 네트워크 패킷 필터링 방법은 패킷을 하나하나 검사하기 때문에 네트워크의 트래픽이 많아지면 성능이 저하될 수 있습니다.
프라이머리 네트워크 패킷 필터링 방법은 네트워크의 보안을 강화하는 데 유용한 방법이지만, 네트워크의 성능을 저하시키는 단점이 있습니다. 따라서, 프라이머리 네트워크 패킷 필터링 방법을 사용할 때는 네트워크의 보안과 성능을 모두 고려해야 합니다.
상태 저장 패킷 필터링? 상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링의 한 종류입니다. 상태 저장 패킷 필터링은 패킷의 소스 IP 주소, 목적지 IP 주소, 프로토콜, 포트 번호뿐만 아니라 패킷의 흐름 상태를 고려하여 패킷을 필터링합니다.
상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링보다 보안이 뛰어납니다. 프라이머리 네트워크 패킷 필터링은 패킷의 흐름 상태를 고려하지 않기 때문에, 공격자가 패킷의 흐름 상태를 조작하여 보안을 우회할 수 있습니다.
상태 저장 패킷 필터링은 프라이머리 네트워크 패킷 필터링보다 성능이 좋은 만큼 네트워크의 성능을 더 저하시킨다는 단점이 있습니다. 상태 저장 패킷 필터링은 패킷의 흐름 상태를 저장하고 관리하기 때문에 네트워크의 트래픽이 많아지면 성능이 저하될 수 있습니다. 따라서, 상태 저장 패킷 필터링을 사용할 때는 네트워크의 보안과 성능을 모두 고려해야 합니다.
