Private IP vs Public IP vs Elastic IP
공용 웹 서버가 하나 있다고 가정해보겠습니다. 이 서버들은 공용 IP를 사용해서 서로 통신할 수 있습니다. 회사엔 사설 네트워크가 있고 사설 네트워크에는 기본적으로 사설 IP 범위가 있는데 사설 IP는 매우 구체적으로 정의되지만 기본적으로 사설 네트워크 내의 모든 컴퓨터가 사설 IP를 이용하여 서로 통신할 수 있음을 의미합니다.
반면 공용 게이트웨이인 인터넷 게이트웨이를 이용하게 되면 이 인스턴스들도 다른 서버들에 액세스 할 수 있게 됩니다. 만일 여러분이 사설 네트워크가 있는 다른 회살을 갖고 있다면 사설 네트워크 안에서 모든 컴퓨터들은 다른 컴퓨터들과 통신할 수 있고 IP가 있는 인터넷 게이트와도 연결되어 있어 인터넷을 통해 어디든 연결하며 다른 서버들과 통신할 수 있게 됩니다.
공용 IP가 있으면 인터넷 전역에 액세스할 수 있고 사설 IP로는 사설 네트워크 내에서만 액세스할 수 있다는 점입니다. 공용 IP는 곧 기기가 인터넷상에서 식별될 수 있음을 의미합니다. 그리고 각 공용 IP는 전체 웹에서 유일한 것이어야 하는데 즉 두 개 이상의 기기가 같은 공용 IP를 가질 수는 없다는 것입니다. 그리고 IP가 있으면 Google 검색으로 그 IP의 지리적 위치를 쉽게 찾을 수 있습니다. 반면 사설 IP는 기기가 오직 사설 네트워크 안에서만 식별될 수 있으며 따라서 IP가 사설 네트워크 안에서만 유일한 것이면 됩니다.
기기가 사설 네트워크에 있을 때 NAT 장치와 프록시 역할을 할 인터넷 게이트웨이를 통해 인터넷에 연결됩니다. 마지막으로 지정된 범위의 IP만 사설 IP로 사용될 수 있습니다.
마지막으로 탄력적 IP의 경우 EC2 인스턴스를 시작하고 중지할 때 공용 IP를 바꿀 수 있습니다. 어떤 이유에서든 인스턴스에 고정된 공용 IP를 사용하려면 탄력적 IP가 필요하게 됩니다. 탄력적 IP는 공용 IPv4인데 삭제하지 않는 한 계속 가지고 있게 됩니다. 당연하게도 한 번에 한 인스턴스에만 첨부할 수 있습니다. IP 주소가 탄력적이면 한 인스턴스에서 다른 인스턴스로 빠르게 이동함으로써 인스턴스 또는 소프트웨어의 오류를 마스킹할 때 사용할 수 있지만 이런 일은 사실 드뭅니다. 왜냐하면 계정당 탄력적 IP를 5개만 쓸 수 있기 때문입니다. 결론적으로 탄력적 IP는 사용하지 않는 것이 좋습니다.
대신 임의의 공용 IP를 써서 DNS 이름을 할당하는 것이 좋습니다. DNS는 Route 53에서 살펴볼 텐데 훨씬 더 많은 제어가 가능하고 확장 가능성도 더 큽니다. 또한 로드 밸런서를 사용해서 공용 IP를 전혀 사용하지 않을 수도 있습니다.
EC2 분산 배치 그룹 (Spread)
분산 배치 그룹은 인스턴스가 다른 하드웨어에 분산된다는 의미입니다. 여기에는 가용 영역별로 분산된 배치 그룹당 7개의 EC2 인스턴스만 가질 수 있다는 제한 사항이 있습니다. 따라서 크리티컬 애플리케이션이 있는 경우 분산 배치 그룹을 사용합니다.
EC2 분할 배치 그룹 (Partition)
분산 배치 그룹과 비슷하게 인스턴스를 분산하지만 분산 배치 그룹과는 다르게 여러 파티션에 인스턴스가 분할되어 있고 이 파티션은 가용 영역 내의 다양한 하드웨어 랙 세트에 의존합니다. 즉 인스턴스가 여전히 분산되어 있지만 다른 실패로부터 격리되지 않았다는 것입니다. 하지만 파티션은 다른 오류 파티션과 격리되어야 합니다. 즉 그룹당 수백 개의 EC2 인스턴스를 통해 확장할 수 있고 이를 통해 Hadoop, Cassandra, Kafka 같은 애플리케이션을 실행할 수 있다는 겁니다.
EC2 클러스터 배치 그룹
클러스터 배치 그룹의 경우 이는 모든 EC2 인스턴스가 동일한 랙에 있다는 겁니다. 즉 동일한 하드웨어와 동일한 가용 영역에 있다는 겁니다. 클러스터 배치 그룹을 만들려고 하고 지연 시간이 매우 짧은 10GB 속도 정도의 네트워크를 원하기 때문에 우린 이들을 동일한 랙에 배치합니다. 즉 우리는 빠른 속도의 네트워크를 갖게 됩니다. 그러나 이 네트워크가 가지는 단점은 랙에 실패가 발생하면 즉 하드웨어에 실패가 발생하면 모든 EC2 인스턴스가 동시에 실패한다는 겁니다. 그래서 전체 스택에 걸쳐 실패가 전파될 위험이 있습니다. 매우 높은 대역폭과 짧은 지연 시간이 필요한 경우 클러스터 배치 그룹이 이를 수행하는 좋은 방법입니다.
EC2의 절전모드
인스턴스를 시작할 경우 먼저 운영체제가 부팅되고 EC2 사용자 데이터에서 스크립트를 실행합니다. EC2 인스턴스에 내부 캐시가 있는 경우 캐시가 워밍업됩니다. 애플리케이션이 시작되는 속도가 느리거나 캐시가 워밍업되는 속도가 느린 경우 이 모든 작업에 시간이 걸릴 수 있습니다. 이 경우 EC2 절전모드라는 옵션을 사용할 수 있습니다.
EC2 절전모드를 사용하면 모든 메모리 내 상태가 보존되므로 RAM의 모든 데이터가 보존됩니다. 즉 메모리가 보존된다는 겁니다. 절전 모드 후 인스턴스를 재시작하면 운영체제가 중지되거나 재시작되지 않았기 때문에 인스턴스 부팅이 훨씬 빨라집니다.
EC2 절전모드 작동방식
실행 중인 EC2 인스턴스가 있다고 가정할 때 RAM에 암호화된 Amazon EBS 루트 볼륨이 있으면 중지 후 절전모드로 전환하면 RAM이 암호화된 Amazon EBS 루트 볼륨에 덤프됩니다. 그러면 인스턴스가 중지되어 인스턴스가 종료되지만 OS는 종료되지 않습니다. 그런 다음 다시 시작하면 RAM이 EBS 볼륨에서 인스턴스의 RAM으로 이동하고 인스턴스가 실행됩니다.
EC2 절전모드 사용 사례
장기 실행 프로세스를 계속 실행하려는 경우나 RAM 상태를 저장하려는 경우나 초기화하는 데 시간이 많이 걸리는 서비스가 있는 경우 시작할 때 실제로 초기화하고 싶지 않다면 인스턴스를 절전모드로 전환하고 재시작하면 인스턴스 상태가 유지됩니다. 하지만 절전모드 옵션은 모든 인스턴스를 지원하지는 않습니다.
탄력적 네트워크 인터페이스 (ENI)
VPC의 논리적 구성 요소이며 가상 네트워크 카드를 나타냅니다. ENI는 EC2 인스턴스가 네트워크에 액세스할 수 있게 해줍니다. 또한 ENI는 EC2 인스턴스 외부에서도 사용됩니다. 예를 들어 가용 영역이 있고 하나의 EC2 인스턴스가 있다고 하면 기본 ENI인 Eth0에 연결되어 EC2 인스턴스 네트워크 연결을 제공합니다. 각 ENI는 다음과 같은 속성을 가질 수 있습니다. 첫 번째로 주요 사설 IPv4와 하나 이상의 보조 IPv4를 가질 수 있습니다. 따라서 이 예시에서는 Eth0 하나만 있지만 EC2에 보조 ENI를 얼마든지 추가해도 됩니다. 각 ENI는 사설 IPv4당 탄력적 IPv4를 갖거나 혹은 하나의 공용 IPv4를 가질 수 있으므로 사설 및 공용 IP가 한 개씩 제공됩니다. 참고로 ENI는 특정 가용 영역 즉 AZ에 바인딩됩니다. 즉 특정 AZ에서 ENI를 생성하면 해당 AZ에만 바인딩할 수 있습니다. 만약 이 인스턴스에 다른 문제가 생겼는데 또 다른 ENI가 연결되어 있다고 가정하면 첫 번째 EC2 인스턴스에서 두 번째 EC2 인스턴스로 Eth1을 옮겨서 사설 IP를 이동시킬 수 있습니다. 그러면 사설 IP가 첫 번째 문제 인스턴스에서 두 번째 EC2 인스턴스로 연결되게 됩니다.
탄력적 네트워크 인터페이스는 VPC에서 가상 네트워크 카드를 나타내는 논리적 네트워킹 구성 요소입니다. 여기에는 다음 속성이 포함될 수 있습니다.
VPC의 IPv4 주소 범위 중 기본 프라이빗 IPv4 주소VPC의 IPv4 주소 범위 중 하나 이상의 보조 프라이빗 IPv4 주소프라이빗 IPv4 주소당 한 개의 탄력적 IP 주소(IPv4)한 개의 퍼블릭 IPv4 주소한 개 이상의 IPv6 주소하나 이상의 보안 그룹MAC 주소원본/대상 확인 플래그설명네트워크 인터페이스를 생성 및 구성하고 동일한 가용 영역의 인스턴스에 연결할 수 있습니다. 계정에는 사용자가 다른 리소스 및 서비스를 사용할 수 있도록 AWS 서비스가 생성하고 관리하는 요청자 관리 네트워크 인터페이스가 있을 수도 있습니다. 이러한 네트워크 인터페이스는 사용자가 직접 관리할 수 없습니다. 또한 이 AWS 리소스를 AWS Management Console 및 Amazon EC2 API에서는 네트워크 인터페이스라고 합니다
요청자 관리 네트워크 인터페이스
요청자 관리형 네트워크 인터페이스는 AWS 서비스가 사용자를 대신하여 VPC에서 생성하는 네트워크 인터페이스입니다. 네트워크 인터페이스는 Amazon RDS의 DB 인스턴스, NAT 게이트웨이, AWS PrivateLink의 인터페이스 VPC 엔드포인트 등의 다른 서비스에 대한 리소스와 연결됩니다.
네트워크 인터페이스 기본 사항
네트워크 인터페이스를 만들고, 인스턴스에 연결하고, 인스턴스에서 분리한 후 다른 인스턴스에 연결할 수 있습니다. 인스턴스에 연결하거나 분리한 후 다른 인스턴스에 다시 연결하면 네트워크 인터페이스의 속성이 해당 네트워크 인터페이스를 따릅니다. 네트워크 인터페이스를 인스턴스 간에 이동하면 네트워크 트래픽이 새 인스턴스로 리디렉션됩니다.
기본 네트워크 인터페이스
각 인스턴스는 기본 네트워크 인터페이스라는 기본 네트워크 인터페이스를 갖습니다. 주 네트워크 인터페이스는 인스턴스에서 분리할 수 없습니다. 추가 네트워크 인터페이스를 만들고 연결할 수 있습니다. 사용 가능한 최대 네트워크 인터페이스 수는 인스턴스 유형에 따라 다릅니다.
네트워크 인터페이스용 퍼블릭 IPv4 주소
VPC에서 모든 서브넷은 해당 서브넷에서 생성된(따라서 인스턴스가 그 서브넷으로 시작된) 네트워크 인터페이스가 퍼블릭 IPv4 주소에 할당될 것인지 결정하는 수정 가능한 속성을 갖습니다.
퍼블릭 IPv4 주소는 Amazon의 퍼블릭 IPv4 주소 풀에서 할당됩니다. 인스턴스를 시작하면 생성된 기본 네트워크 인터페이스에 IP 주소가 할당됩니다.네트워크 인터페이스를 생성할 때 네트워크 인터페이스는 서브넷에서 퍼블릭 IPv4 주소 지정 속성을 상속합니다. 이후에 서브넷의 퍼블릭 IPv4 주소 지정 속성을 수정하면 네트워크 인터페이스는 처음 생성될 때 적용된 설정을 그대로 유지합니다. 인스턴스를 시작하고 기존 네트워크 인터페이스를 기본 네트워크 인터페이스로 지정하는 경우 퍼블릭 IPv4 주소 속성은 이 네트워크 인터페이스에 의해 결정됩니다.
퍼블릭 IPv4 주소
퍼블릭 IP 주소는 인터넷을 통해 연결할 수 있는 IPv4 주소입니다. 퍼블릭 주소는 인스턴스와 인터넷의 상호 통신을 위해 사용될 수 있습니다.
기본 VPC에서 인스턴스를 시작할 때 기본적으로 퍼블릭 IP 주소가 할당됩니다. 기본 VPC가 아닌 VPC로 인스턴스를 시작하는 경우 서브넷은 이 서브넷으로 시작되는 인스턴스가 퍼블릭 IPv4 주소 풀로부터 퍼블릭 IP 주소를 부여받는지 여부를 결정하는 속성을 갖습니다. 기본적으로 기본 서브넷이 아닌 서브넷에서 시작된 인스턴스에 퍼블릭 IP 주소가 할당되지 않습니다.
퍼블릭 IP 주소는 Amazon의 퍼블릭 IPv4 주소 풀에서 사용자 인스턴스로 지정되고 AWS 계정과는 관련이 없습니다. 인스턴스와 퍼블릭 IP 주소의 연결이 해제되면 해당 퍼블릭 IP 주소는 퍼블릭 IPv4 주소 풀로 해제되지만 사용자가 해당 주소를 다시 사용할 수 없습니다.
인스턴스에서 퍼블릭 IP 주소(IPv4)를 수동으로 연결하거나 연결 해제할 수 없습니다. 어떤 경우에는 Amazon에서 귀하의 인스턴스로부터 퍼블릭 IP 주소를 해제하거나 새 인스턴스에 할당합니다.
인스턴스가 중지되거나 최대 절전 모드로 전환되거나 종료되면 인스턴스의 퍼블릭 IP 주소는 릴리스됩니다. 중지되거나 최대 절전 모드로 전환된 인스턴스가 시작되면 새 퍼블릭 IP 주소가 할당됩니다.
탄력적 IP 주소를 인스턴스와 연결하는 경우 인스턴스의 퍼블릭 IP 주소가 릴리스됩니다. 사용자가 인스턴스에서 탄력적 IP 주소의 연결을 해제하면 새 퍼블릭 IP 주소가 할당됩니다.
VPC 인스턴스의 퍼블릭 IP 주소가 해제되고 인스턴스에 1개 이상의 네트워크 인터페이스가 연결된 경우 새 퍼블릭 IP 주소가 할당되지 않습니다.
인스턴스의 퍼블릭 IP 주소가 릴리스된 가운데 탄력적 IP 주소와 연결된 보조 프라이빗 IP 주소를 보유한 경우 인스턴스는 새 퍼블릭 IP 주소를 수신하지 않습니다.
필요에 따라 인스턴스 간에 연결할 수 있는 영구 퍼블릭 IP 주소가 필요한 경우 탄력적 IP 주소를 대신하여 사용합니다.
동적 DNS를 사용하여 새 인스턴스의 퍼블릭 IP 주소에 기존 DNS 이름을 연결하는 경우 IP 주소가 인터넷을 통해 전해지는 데 24시간까지 걸릴 수 있습니다. 따라서 종료된 요청을 계속 받는 동안 새 인스턴스가 트래픽을 받지 못할 수 있습니다.
- NodeJS 애플리케이션을 호스트하게 될 EC2 인스턴스를 실행합니다. 모든 필수 소프트웨어를 설치하고 애플리케이션을 구성한 후, 액세스를 위해 EC2 인스턴스 공용 IPv4를 기록해 두었습니다. 그 다음, 실행을 중단하고 애플리케이션 구성을 완료하기 위해 EC2 인스턴스를 다시 시작했습니다. 그러나 재시작 후, EC2 인스턴스에 액세스할 수 없었으며 EC2 인스턴스 공용 IPv4가 변경된 것을 알게 되었습니다. 이 경우, EC2 인스턴스에 고정적인 공용 IPv4를 할당하려면 어떻게 해야 할까요 ?
A. EC2 인스턴스에 탄력적 IP 할당- B. EC2 인스턴스 OS에서 네트워크 구성을 DHCP에서 정적으로 변경한 뒤 공용 IPv4에 할당
- C. AWS 지원 센터에 연락해 EC2 인스턴스를 위한 정적 공용 IPv4 요청
- D. 불가능, EC2 인스턴스에는 고정 사설 IPv4만 할당 가능
✅ 탄력적 IP는 여러분이 원하는 기간만큼 소유할 수 있는 공용 IPv4로 한 번에 하나의 인스턴스에만 연결할 수 있습니다.
- 한 세트의 EC2 인스턴스가 필요한 배치 작업을 수행하려 합니다. 배치 작업은 4시간 동안 수행되며 중단되어서는 안 됩니다. 이러한 배치 작업을 가장 저렴한 비용으로 수행하기 위해서는 다음 중 어떤 EC2 구매 옵션을 선택해야 할까요 ?
- A. 온디맨드 인스턴스
- B. 예약 인스턴스
- C. 스팟 인스턴스
D. 스팟 블록 인스턴스
✅ 스팟 블록 인스턴스를 사용하면 한 세트의 EC2 인스턴스를 지정된 기간(1~6시간)동안 중단 없이 예약할 수 있습니다.
- 스팟 플릿은 한 세트의 스팟 인스턴스로 선택적 ()입니다.
- A. 예약 인스턴스
B. 온디맨드 인스턴스- C. 전용 호스트
- D. 전용 인스턴스
✅ 스팟 플릿은 한 세트의 스팟 인스턴스로 선택적 온디맨드 인스턴스입니다. 이를 사용하면 가장 낮은 가격의 스팟 인스턴스를 자동으로 요청할 수 있습니다.
- EC2 인스턴스 플릿에서 대규모의 데이터 분석을 수행하는 애플리케이션이 있습니다. 여러분은 EC2 인스턴스들이 서로 소통하면서도 가장 높은 수준의 네트워킹 성능을 유지했으면 합니다. 이런 경우, 다음 중 어떤 EC2 배치 그룹을 선택해야 할까요 ?
- A. 분산 배치 그룹
B. 클러스터 배치 그룹- C. 분할 배치 그룹
✅ 클러스터 배치 그룹을 사용하면 EC2 인스턴스들이 나란히 위치하게 되어 고성능의 컴퓨팅 및 네트워킹 성능을 제공하게 됩니다.
- EC2 인스턴스 플릿에 호스팅된 중요 애플리케이션이 있습니다. 이 애플리케이션에서 AZ 실패가 일어난 경우, 최대 가용성을 달성했으면 합니다. 이런 경우, 다음 중 어떤 EC2 배치 그룹을 선택해야 할까요 ?
- A. 클러스터 배치 그룹
- B. 분할 배치 그룹
C. 분산 배치 그룹
✅ EC2 분산 배치 그룹은 EC2 인스턴스들이 서로 다른 AZ에 위치하게 됩니다.
- 탄력적 네트워크 인터페이스(ENI)는 다른 AZ에 있는 EC2 인스턴스와 연결될 수 있습니다.
- A. 맞습니다.
B. 아닙니다.
✅ 탄력적 네트워크 인터페이스(ENI)는 특정 AZ로 국한됩니다. 다른 AZ에 있는 EC2 인스턴스에 ENI를 연결할 수는 없습니다.
- EC2 절전 모드와 관련된 내용 중, 옳지 않은 설명을 고르세요.
A. EC2 인스턴스 루트 볼륨은 반드시 인스턴스 스토어 볼륨이어야 함- B. 온디맨드 및 예약 인스턴스를 지원함
- C. EC2 인스턴스 RAM은 150GB 미만이어야 함
- D. EC2 인스턴스 루트 볼륨 유형은 EBS 볼륨이어야 함
✅ EC2 절전 모드를 활성화하기 위해서는 EC2 인스턴스 루트 볼륨 유형이 EBS 볼륨이어야만 하며, 민감한 내용을 보호할 수 있도록 암호화되어야 합니다.
