DEV Community

Sangwoo Lee
Sangwoo Lee

Posted on • Edited on

[AWS] 3. EC2 - Solutions Architect Associate Level (Private IP vs Public IP), Elastic IP

Private IP vs Public IP (IPv4)

  • Networking has two sorts of IPs. IPv4 and IPv6.

    • IPv4: 1.160.10.240
    • IPv6: 3ffe: 1900:4545:3:200:f8ff:fe21:67cf
  • In this course, we will only be using IPv4.

  • IPv4 is still the most common format used online.

  • IPv6 is newer and solves problems for the Internet of Things (IoT).

  • IPv4 allows for 3.7billion different addresses in the public space

  • IPv4: [0-255].[0-255].[0-255].[0-255]. (IPv4형식)

사설IP vs 공인IP 네트워킹에는 두 가지 IP 형식 존재: IPv4와 IPv6
이 과정에서는 IPv4만 사용 - IPv4는 여전히 온라인에서 가장 일반적으로 사용되는 형식, IPv6는 더 새롭고 사물 인터넷(IoT) 문제를 해결, IPv4는 퍼블릭 공간에서 37억 개의 서로 다른 주소 허용

Private IP vs Public IP Example

Private IP vs Public IP Fundamental Differences

  • Public IP:

    • Public IP means the machine can be identified on the internet (WWW)
    • Must be unique across the whole web (not two machines can have the same public IP).
    • Can be geo-located easily
  • Private IP:

    • Private IP means the machine can only be identified on a private network only
    • The IP must be unique across the private network
    • BUT two different private networks (two companies) can have the same IPs.
    • Machines connect to WWW using an internet gateway (a proxy)
    • Only a specified range of IPs can be used as private IP

공인IP: 인터넷(WWW)에서 머신 식별 가능, 전체 웹에서 고유해야 함(두 머신이 동일한 공IP를 가질 수 없음), 지리적 위치 추적 용이

사설IP: 사설 네트워크 내에서만 머신 식별 가능, 사설 네트워크 내에서 고유해야함, 단, 두 개의 서로 다른 사설 네트워크(두 회사)는 동일한 IP 사용 가능, 인터넷 게이트웨이(프록시)를 사용하여 WWW에 연결, 지정된 IP 범위만 프라이빗 IP로 사용 가능

Elastic IPs

  • When you stop and then start an EC2 instance, it can change its public IP.
  • If you need to have a fixed public IP for your instance, you need an Elastic IP
  • An Elastic IP is a public IPv4 IP you own as long as you don't delete it
  • You can attach it to one instance at a time

Elastic IP

  • With an Elastic IP address, you can mask the failure of an instance of software by rapidly remapping the address to another instance in your account.
  • You can only have 5 Elastic IP in your account (you can ask AWS to increase that).
  • Overall, try to avoid using Elastic IP:
    • They often reflect poor architectural decisions
    • Instead, use a random public IP and register a DNS name to it
    • Or, as we'll see later, use a Load Balancer and don't use a public IP

탄력적IP : EC2 인스턴스를 중지했다가 시작하면 퍼블릭 IP가 변경될 수 있음, 고정된 공인IP가 필요한 경우 Elastic IP 필요. Elastic IP는 삭제하지 않는 한 소유하는 공인 IPv4 IP, 한 번에 하나의 인스턴스에만 연결 가능

Elastic IP 주소를 사용하면 계정의 다른 인스턴스로 주소를 빠르게 재매핑하여 인스턴스 또는 소프트웨어 장애를 마스킹 가능 - 전반적으로 Elastic IP 사용을 피하는 것이 좋음. 잘못된 아키텍처 결정을 반영하는 경우가 많기 때문, 대신 랜덤 공인IP를 사용하고 DNS 이름을 등록 또는 나중에 볼 Load Balancer를 사용하고 공인IP를 사용하지 않음

Private IP vs Public IP (IPv4) In AWS EC2 - Hands On

  • By default, your EC2 machine comes with:

    • A private IP for the internal AWS Network
    • A public IP, for the WWW.
  • When we are doing SSH into our EC2 machines:

    • We can't use a private IP, because we are not in the same network
    • We can only use the public IP.
  • If your machine is stopped and then started, the public IP can change

Placement Groups

  • Sometimes you want control over the EC2 Instance placement strategy
  • That strategy can be defined using placement groups
  • When you create a placement group, you specify one of the following strategies for the group:
    • (1) Cluster: clusters instances into a low-latency group in a single Availability Zone
    • (2) Spread: spreads instances across underlying hardware (max 7 instances per group per AZ) - critical applications
    • (3) Partition: spreads instances across many different partitions (which rely on different sets of racks) within an AZ. Scales to 100s of EC2 instances per group (Hadoop, Cassandra, Kafka)

기본적으로 EC2 머신은 내부 AWS 네트워크용 사설IP 및, WWW용 공인IP를 제공받음. EC2 머신에 SSH 접속 시 동일 네트워크에 있지 않기 때문에 사설IP는 사용 불가, 공인 IP만 사용가능. 머신을 중지했다가 시작하면 공인IP가 변경될 수 있음

배치그룹 - EC2 인스턴스 배치 전략을 제어하고 싶을때, 해당 전략은 배치 그룹을 사용하여 정의 가능. 배치 그룹 생성 시 다음 전략 중 하나를 지정.
(1) 클러스터: 단일 가용 영역 내 저지연 그룹으로 인스턴스를 클러스터링
(2) 분산: 기본 하드웨어 전체에 인스턴스를 분산. AZ당 그룹당 최대 7개 인스턴스, 중요 애플리케이션
(3) 파티션: AZ 내의 여러 파티션에 인스턴스를 분산, 서로 다른 랙 세트에 의존. 그룹당 수백 개의 EC2 인스턴스로 확장 (Hadoop, Cassandra, Kafka)

(1) Placement Group Cluster

  • Pros: Great network (10Gbps bandwidth between instances with Enhanced Networking enabled - recommended)
  • Cons: If the AZ fails, all instances fails at the same time
  • Use case:
    • Big Data job that needs to complete fast
    • Application that needs extremely low latency and high network throughput

(1) Cluster 배치 그룹 장점 : 우수한 네트워크(Enhanced Networking 활성화 시 인스턴스 간 10Gbps 대역폭 - 권장), 단점 : AZ 장애 발생 시 모든 인스턴스가 동시에 실패
사례 : 빠르게 완료해야 하는 빅데이터 작업, 매우 낮은 지연 시간과 높은 네트워크 처리량이 필요한 애플리케이션

(2) Placement Group Spread

  • Pros:

    • Can span across Availability Zones (AZ)
    • Reduced risk is simultaneous failure
    • EC2 Instances are on different physical hardware
  • Cons:

    • Limited to 7 instances per AZ per placement group
  • Use case:

    • Application that needs to maximize high availability
    • Critical Applications where each instance must be isolated from failure from each other

(2) 분산배치그룹 장점 : 가용 영역(AZ) 전체에 걸쳐 확장 가능, 동시 장애 위험 감소, EC2 인스턴스가 서로 다른 물리적 하드웨어에 위치. 단점: 배치 그룹당 AZ당 7개 인스턴스로 제한
사례 : 고가용성을 극대화해야 하는 애플리케이션, 각 인스턴스가 서로의 장애로부터 격리되어야 하는 중요한 애플리케이션

(3) Placement Group Spread

  • Up to 7 partitions per AZ
  • Can span across multiple AZs in the same region
  • Up to 100s of EC2 instances
  • The instances in a partition do not share racks with the instances in the other partitions
  • A partition failure can affect many EC2 but won't affect other partitions
  • EC2 instances get access to the partition information as metadata
  • Use cases: HDFS, HBase, Cassandra, Kafka

(3) Placement Group Partition (파티션 배치 그룹) AZ당 최대 7개 파티션, 동일 리전 내 여러 AZ에 걸쳐 확장 가능, 최대 수백 개의 EC2 인스턴스, 파티션 내 인스턴스는 다른 파티션의 인스턴스와 랙을 공유하지 않음, 파티션 장애는 많은 EC2에 영향을 줄 수 있지만 다른 파티션에는 영향 없음, EC2 인스턴스는 메타데이터로 파티션 정보에 액세스 가능

Elastic Network Interfaces (ENI)

  • Logical component in a VPC that represents a virtual network card
  • The ENI can have the following attributes:

    • Primary private IP (IPv4), one or more secondary IPv4
    • One Elastic IP (IPv4) per private IPv4
    • One Public IPv4
    • One or more security groups
    • A MAC address
  • You can create ENI independently and attach them on the fly (move them) on EC2 instances for failover

  • Bound too a specific Availability Zone (AZ)

가상 네트워크 카드를 나타내는 VPC의 논리적 구성 요소

  • ENI가 가질 수 있는 속성: 기본 프라이빗 IPv4, 하나 이상의 보조 IPv4, 프라이빗 IPv4당 하나의 Elastic IP (IPv4), 하나의 퍼블릭 IPv4, 하나 이상의 보안 그룹, MAC 주소

  • ENI를 독립적으로 생성하고 장애 조치를 위해 EC2 인스턴스에 즉시 연결(이동) 가능, 특정 가용 영역(AZ)에 종속

EC2 Hibernate

  • We know we can stop, terminate instances

    • Stop: the data on disk(EBS) is kept intact in the next start
    • Terminate: any EBS volumes(root) also set-up to be destroyed is lost
  • On start, the following happens:

    • First start: the OS boots & the EC2 User Data script is run
    • Following starts: OS boots up
    • Then your application starts, caches get warmed up, and that can take time!
  • Introducing EC2 Hibernate:

    • The in-memory (RAM) state is preserved
    • The instance boot is much faster! (the OS is not stopped/restarted)
    • Under the hood: the RAM state is written to a file in the root EBS volume
    • The root EBS volume must be encrypted
  • Use cases:

    • Long-running processing
    • Saving the RAM state
    • Services that take time to initialize

EC2 Hibernate (EC2 최대 절전 모드)

  • 인스턴스를 중지하거나 종료할 수 있음 (중지): 디스크(EBS)의 데이터는 다음 시작 시에도 그대로 유지, (종료): 삭제하도록 설정된 모든 EBS 볼륨(루트)이 손실

  • 시작 시 발생하는 일: 첫 시작: OS 부팅 및 EC2 User Data 스크립트 실행, 이후 시작: OS 부팅, 그런 다음 애플리케이션 시작, 캐시 워밍업, 시간이 걸릴 수 있음

  • EC2 Hibernate: 메모리(RAM) 상태가 보존됨, 인스턴스 부팅이 훨씬 빠름(OS가 중지/재시작되지 않음), 내부 동작: RAM 상태가 루트 EBS 볼륨의 파일에 기록됨, 루트 EBS 볼륨은 반드시 암호화되어야 함

  • 사용 사례: 장기 실행 처리 작업, RAM 상태 저장, 초기화에 시간이 걸리는 서비스

EC2 Hibernate - Good to know

  • Supported Instance Families - C3, C4, C5, I3, M3, M4,R3, R4, T2, T3
  • Instance RAM Size - must be less than 150GB.
  • Instance Size - not supported for bare metal instances.
  • AMI - Amazon Linux2, Linux AMI, Ubuntu, RHEL, CentOS & Windows
  • Root Volume - must be EBS, encrypted, not instance store, and large
  • Available for On-Demand, Reserved and Spot Instances
  • An instance can NOT be hibernated more than 60days

인스턴스 RAM 크기 150GB 미만, 인스턴스 크기는 베어 메탈 인스턴스는 지원되지 않음. 루트 볼륨은 EBS여야 하며, 암호화되어야 하고, 인스턴스 스토어가 아니어야 하며, 충분히 커야 함. On-Demand, Reserved 및 Spot 인스턴스에서 사용 가능, 인스턴스는 60일 이상 최대 절전 모드로 유지할 수 없음


[추가] Private IP 범위 (RFC 1918)

Private IP의 사용 가능한 범위

  • 10.0.0.0 - 10.255.255.255 (10.0.0.0/8) - Large-scale networks
  • 172.16.0.0 - 172.31.255.255 (172.16.0.0/12) - AWS VPC default range
  • 192.168.0.0 - 192.168.255.255 (192.168.0.0/16) - Small-scale networks

AWS VPC uses 172.31.0.0/16 range by default

In production, 10.x.x.x range is commonly used because it provides wider IP space and easier subnet design

AWS VPC는 기본적으로 172.31.0.0/16 대역을 사용. 실무에서는 10.x.x.x 대역을 많이 사용하는데, 더 넓은 IP 범위를 확보할 수 있고 서브넷 설계가 용이하기 때문

[추가] Elastic IP 비용 정책

Elastic IP 과금 구조

Free when:

Elastic IP is attached to a running instance
The instance has only one Elastic IP

무료 조건: Elastic IP가 실행 중인 인스턴스에 연결되어 있고, 해당 인스턴스에 하나의 Elastic IP만 연결된 경우

Charged ($0.005/hour) when:

Elastic IP is allocated but not attached to any instance
Attached to a stopped instance
Second Elastic IP is attached to an instance

과금 조건 (시간당 $0.005):

Elastic IP가 할당되었지만 인스턴스에 연결되지 않은 경우
중지된 인스턴스에 연결된 경우
하나의 인스턴스에 두 번째 Elastic IP가 연결된 경우
Production tip: Release unused Elastic IPs immediately - you'll be charged $3.6/month if forgotten

실무 팁: 사용하지 않는 Elastic IP는 즉시 릴리스해야하며, 잊어버리면 월 $3.6씩 과금됨

[추가] ENI 실무 사용 케이스
ENI의 주요 활용 시나리오

1. Failover (장애 조치):

Move ENI to standby instance instantly on primary failure
No DNS update needed as private IP remains same

Primary 인스턴스 장애 시 ENI를 Standby 인스턴스로 즉시 이동
Private IP가 변경되지 않아 DNS 업데이트 불필요

2. License Management (라이선스 관리):

Use ENI's MAC address for MAC-based licensing software

MAC 주소 기반 라이선스 소프트웨어 사용 시 ENI의 MAC 주소 활용

  1. Dual-homed Instances (듀얼 홈 인스턴스):

Attach multiple ENIs to different subnets (e.g., management + data network)

서로 다른 서브넷에 여러 ENI 연결 (예: management + data network)
ENI 제한사항

Limits:

Max ENIs per instance type (e.g., t3.micro: max 2 ENIs)
ENIs can only move within the same AZ

인스턴스 타입별로 연결 가능한 ENI 개수 제한 있음 (예: t3.micro는 최대 2개)
ENI는 같은 AZ 내에서만 이동 가능

[추가] Placement Groups 실무 주의사항

Cluster Placement Group

Network performance:

Enhanced Networking must be enabled (enabled by default on most modern instance types)
Best practice: Use homogeneous instance types for consistent network performance

네트워크 성능: Enhanced Networking 활성화 필수 (기본적으로 대부분 최신 인스턴스 타입에서 활성화됨)
제한사항: 서로 다른 인스턴스 타입을 혼합하지 않는 것을 권장 (동일한 네트워크 성능 보장)
Spread Placement Group

7-instance limit:

Absolute limit of 7 instances per AZ - use multiple AZs if you need more
Cost consideration: Cross-AZ data transfer costs $0.01/GB when distributed across multiple AZs

7개 제한: AZ당 7개 인스턴스 제한은 절대적. 더 많은 인스턴스가 필요하면 여러 AZ 사용
비용: 여러 AZ에 분산하면 AZ 간 데이터 전송 비용 발생 ($0.01/GB)
Partition Placement Group

Partition isolation: Instances in the same partition share the same rack - not complete isolation

Application must be partition-aware to leverage this feature effectively

파티션 격리: 같은 파티션 내 인스턴스들은 같은 랙을 공유하므로 완전한 격리는 아님
메타데이터 활용: 애플리케이션이 파티션 정보를 인식하도록 설계해야 최대 효과

[추가] EC2 Hibernate 실무 제약사항

Cannot hibernate if:

Root volume is Instance Store (must be EBS)
Root EBS volume is not encrypted
RAM exceeds 150GB

Hibernate 불가능한 경우
루트 볼륨이 Instance Store인 경우 (반드시 EBS여야 함)
암호화되지 않은 EBS 루트 볼륨 (보안 요구사항)
RAM이 150GB 초과하는 인스턴스
Hibernate 시 주의사항

EBS storage costs continue during hibernation
Hibernate is for fast restart, not cost savings
60-day limit encourages regular reboots for security patches

Hibernate 상태에서도 EBS 스토리지 비용은 계속 발생
Hibernate는 빠른 재시작이 목적이지, 비용 절감이 아님
60일 제한은 보안 패치 등을 위한 정기 재부팅 권장사항

실무에서 가장 자주 하는 실수들:

Mistake #1: Leaving Elastic IPs unattached → Unnecessary charges accumulate
Mistake #2: Building HPC/Big Data clusters without Placement Groups → Network latency issues
Mistake #3: Trying to move ENIs across different AZs → Impossible operation
Mistake #4: Using Hibernate for cost savings → Stop is actually cheaper

Elastic IP를 릴리스하지 않고 방치 → 불필요한 과금 발생
Placement Group 없이 HPC/빅데이터 클러스터 구성 → 네트워크 지연 발생
ENI를 서로 다른 AZ로 이동하려고 시도 → 불가능한 작업
Hibernate 인스턴스를 비용 절감 목적으로 사용 → 실제로는 Stop이 더 저렴

This covers essential knowledge for both Solutions Architect Associate exam and production environments.

Top comments (0)