LabEx
무료 가입

애플리케이션 서브넷이 있는 VPC 생성

AWSBeginner
지금 연습하기

소개

택배 배송 애플리케이션에는 외부 공개 서비스와 내부 작업자를 위한 별도의 주소 범위가 필요합니다. VPC를 만들고 겹치지 않는 두 서브넷을 서로 다른 가용 영역에 배치한 뒤 AWS View에서 주소 계획을 확인합니다.

AWS CLI 명령 실행과 리소스 ID 읽기에 익숙해야 합니다. CLI는 이 새로운 환경에 맞게 구성되어 있습니다. 마지막에는 직접 생성한 리소스만 삭제합니다.

자격증 시험 관련 주제

이 실습은 다음 시험 주제에 대한 실무 연습을 제공합니다.

배송 VPC 생성

이 단계에서는 애플리케이션 전체의 주소 범위를 선택하고 VPC를 생성합니다.

**Virtual Private Cloud(VPC)**는 하나의 AWS 리전에 있는 리소스를 위한 격리된 네트워크입니다. CIDR 블록은 서브넷에서 사용할 수 있는 주소를 정의합니다. IPv4 CIDR 표기는 시작 주소와 접두사 길이를 결합합니다. 10.20.0.0/16은 10.20.0.0부터 10.20.255.255까지 포함합니다. 접두사 숫자가 작을수록 주소에 사용할 비트가 많으므로 /16이 /24보다 큽니다.

준비된 Terminal에서 명령을 실행하고 옆의 AWS View 탭을 클릭합니다. 이 화면은 CLI와 동일한 리소스 상태를 읽고 생성한 네트워크 리소스를 표시합니다. 작업하는 동안 두 화면을 모두 사용할 수 있게 유지하세요.

작업 디렉터리에서 시작합니다:

cd /home/labex/project

변경하기 전에 기존 VPC 목록을 읽습니다. --query는 ID와 CIDR 필드를 선택하고 --output table은 비교하기 쉬운 표를 만듭니다:

aws ec2 describe-vpcs --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}' --output table

참조 네트워크는 10.99.0.0/16을 사용합니다. 다른 기존 VPC도 나타날 수 있습니다. 기존 네트워크는 그대로 두고 자신의 10.20.0.0/16 네트워크를 생성한 후 마지막에 삭제합니다.

EC2 명령 그룹에는 VPC 네트워크 작업이 포함됩니다. --cidr-block은 주소 범위를 설정하고 --tag-specifications는 생성 시 Name과 Project 태그를 추가합니다. 따옴표는 대괄호와 쉼표가 포함된 값을 하나의 인수로 묶습니다.

셸 표현식 $(...)는 명령을 실행하고 출력을 가져옵니다. 출력을 VPC_ID에 할당하면 이후 명령에 사용할 생성된 VPC ID가 저장됩니다. --query 'Vpc.VpcId' --output text는 해당 ID만 반환합니다:

VPC_ID=$(aws ec2 create-vpc \
  --cidr-block 10.20.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=delivery-network},{Key=Project,Value=parcel}]' \
  --query 'Vpc.VpcId' \
  --output text)

출력을 가져오는 명령은 결과를 화면에 표시하지 않습니다. 저장한 ID로 리소스를 다시 읽습니다. "$VPC_ID"는 변수 값을 하나의 인수로 대입합니다:

aws ec2 describe-vpcs \
  --vpc-ids "$VPC_ID" \
  --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock,State:State}' \
  --output table

CIDR은 10.20.0.0/16이고 상태는 available입니다. AWS View에 동일한 CIDR을 가진 delivery-network가 표시되며 아직 애플리케이션 서브넷은 없습니다. 저장한 ID를 유지하려면 이 Terminal을 열어 두세요.

공개 서비스용 서브넷 추가

이 단계에서는 VPC 안에 더 작은 주소 범위를 할당하고 가용 영역에 배치합니다.

서브넷은 VPC 주소 범위의 일부입니다. 각 서브넷은 해당 리전의 정확히 하나의 **가용 영역(AZ)**에 속하며 VPC 자체는 리전 전체에 걸쳐 있습니다. us-east-1a 같은 AZ 이름은 서브넷 리소스가 배치될 위치를 나타냅니다.

향후 공개 서비스에 사용할 10.20.1.0/24를 예약합니다. 이 범위는 10.20.1.0부터 10.20.1.255까지이며 10.20.0.0/16 안에 들어갑니다. 일반 IPv4 서브넷에서 AWS는 처음 네 주소와 마지막 주소를 예약하므로 이 /24에는 할당 가능한 주소가 251개 있습니다. 예약된 주소는 워크로드에 할당하지 않습니다.

사용 가능한 영역 이름을 확인합니다. 리전은 환경 시작 시 구성되었습니다:

aws ec2 describe-availability-zones \
  --query 'AvailabilityZones[].{Zone:ZoneName,State:State}' \
  --output table

이 서브넷에는 us-east-1a, 다음 서브넷에는 us-east-1b를 사용합니다. --vpc-id는 상위 네트워크를, --availability-zone은 배치 위치를 선택합니다. 정리를 위해 새 서브넷 ID를 저장합니다:

PUBLIC_SUBNET_ID=$(aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.1.0/24 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=delivery-public},{Key=Project,Value=parcel}]' \
  --query 'Subnet.SubnetId' \
  --output text)

상위 네트워크, 주소 범위 및 영역을 다시 읽습니다:

aws ec2 describe-subnets \
  --subnet-ids "$PUBLIC_SUBNET_ID" \
  --query 'Subnets[].{ID:SubnetId,VPC:VpcId,CIDR:CidrBlock,Zone:AvailabilityZone}' \
  --output table

VPC ID는 저장한 ID와 같고 범위는 10.20.1.0/24, 영역은 us-east-1a입니다. AWS View는 이 서브넷을 delivery-network 안에 표시합니다.

delivery-public이라는 이름은 예정된 용도를 설명합니다. 이름만으로 서브넷이 퍼블릭이 되지는 않습니다. 다음 실습에서 구성할 인터넷 게이트웨이 경로도 필요합니다.

별도의 작업자 서브넷 추가

이 단계에서는 내부 작업자에게 겹치지 않는 별도의 서브넷을 제공하고 완성된 계획을 비교합니다.

같은 VPC의 두 서브넷은 겹칠 수 없습니다. 작업자에 10.20.2.0/24를 할당하면 10.20.1.0/24와 주소 범위가 분리됩니다. 두 범위 모두 VPC의 /16 안에 있습니다.

이 서브넷을 us-east-1b에 배치하여 하나의 VPC에 서로 다른 가용 영역의 서브넷이 들어갈 수 있음을 확인합니다. 이는 배치를 보여 주는 것이며 아직 영역 간에 이중화된 애플리케이션을 배포한 것은 아닙니다.

PRIVATE_SUBNET_ID=$(aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.2.0/24 \
  --availability-zone us-east-1b \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=delivery-private},{Key=Project,Value=parcel}]' \
  --query 'Subnet.SubnetId' \
  --output text)

서버 측 필터로 자신의 VPC에 속한 서브넷만 선택합니다. Name=vpc-id,Values=...에서 Name은 필터를 식별하고 Values는 일치하는 VPC ID를 포함합니다:

aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query 'Subnets[].{ID:SubnetId,CIDR:CidrBlock,Zone:AvailabilityZone}' \
  --output table

두 행은 다음 계획을 보여 줍니다. 생성된 ID와 행 순서는 달라질 수 있습니다:

용도 CIDR 가용 영역
공개 서비스 10.20.1.0/24 us-east-1a
내부 작업자 10.20.2.0/24 us-east-1b

겹침 경계를 확인하려면 10.20.1.128/25 추가를 시도합니다. 이 작은 범위는 이미 delivery-public 안에 있으므로 이 VPC의 다른 서브넷으로 만들 수 없습니다:

aws ec2 create-subnet \
  --vpc-id "$VPC_ID" \
  --cidr-block 10.20.1.128/25 \
  --availability-zone us-east-1a

예상 오류에는 InvalidSubnet.Conflict가 포함됩니다. 세 번째 서브넷은 생성되지 않습니다. 앞에서 만든 유효한 두 /24 범위를 유지하세요.

AWS View에서 같은 범위와 영역을 비교합니다. 두 서브넷 모두 아직 인터넷 경로가 없습니다. 별도의 주소 범위는 이후 실습에서 라우팅과 접근 규칙을 개별적으로 적용할 위치를 제공합니다.

배송 VPC에 서로 다른 가용 영역의 겹치지 않는 두 서브넷이 표시됨

결과 예시: 두 서브넷 CIDR 모두 VPC 범위 안에 있고 각 서브넷의 가용 영역이 표시됩니다. 환경에 따라 리소스 ID는 달라집니다.

연습 네트워크 삭제

이 단계에서는 기존 참조 네트워크를 유지하면서 자신의 두 서브넷과 VPC를 삭제합니다.

리소스에는 의존 관계가 있습니다. 자신의 서브넷이 남아 있는 VPC는 삭제할 수 없습니다. 저장한 서브넷 ID만 삭제합니다. 삭제 명령이 성공하면 출력이 없습니다:

aws ec2 delete-subnet --subnet-id "$PUBLIC_SUBNET_ID"

aws ec2 delete-subnet --subnet-id "$PRIVATE_SUBNET_ID"

이제 비어 있는 VPC를 삭제합니다:

aws ec2 delete-vpc --vpc-id "$VPC_ID"

변경 가능한 태그에 의존하지 말고 전체 VPC 목록을 다시 읽어 삭제를 확인합니다:

aws ec2 describe-vpcs --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}' --output table

10.20.0.0/16 VPC가 없습니다. 10.99.0.0/16 참조 네트워크와 다른 기존 네트워크는 남아 있습니다. 목록 조회 실패는 정리 완료를 증명하지 않습니다. AWS View에는 애플리케이션 VPC가 없다고 표시됩니다.

이 단계의 완료 검사를 실행하세요.

다음 실습은 별도의 준비된 애플리케이션이 있는 새 환경에서 시작합니다. 인터넷 게이트웨이, 경로, 퍼블릭 주소가 외부 요청을 애플리케이션에 전달하는 방법을 배웁니다.

요약

VPC 주소 범위를 생성하고 겹치지 않는 두 애플리케이션 서브넷으로 나눈 뒤 각 서브넷을 가용 영역에 배치했습니다. CLI와 AWS View로 상위 관계를 확인하고 자신의 연습 네트워크만 삭제했습니다.

주소 계획을 작동하는 애플리케이션 경로로 바꾸려면 '퍼블릭 서브넷을 인터넷에 연결' 실습을 계속 진행하세요.

관련 AWS 코스
초보자를 위한 AWS 기초

초보자를 위한 AWS 기초

aws
초보자를 위한 AWS S3

초보자를 위한 AWS S3

aws
초보자를 위한 AWS IAM

초보자를 위한 AWS IAM

aws