[AWS 네트워크 지식 02] AWS 네트워크 설계 및 구축하기

2026년 3월 11일조회 9

이 글은 《AWS 잘하는 개발자 되기》에서 발췌했습니다.

AWS 잘하는 개발자 되기

ISBN 9791194383512지은이 김재욱₩40,000

[AWS 네트워크 지식 02] AWS 네트워크 설계 및 구축하기

1. AWS 네트워크 설계 시 고려 사항

AWS에서 네트워크를 생성하고 서비스를 운영할 때 잘못된 네트워크 설계로 인해 발생하는 문제는 복구가 어려울 수 있습니다. 한 번 생성된 네트워크는 수정되거나 되돌릴 수 있는 기능이 제한 적이므로 신중한 네트워크 설계가 중요합니다. 특히, VPC와 서브넷의 경우 잘못된 네트워크 설계로 인해 IP 주소가 부족하더라도 네트워크 설정을 되돌릴 수 없으며, 이는 서비스 운영에 치명적인 영향을 끼칠 수 있습니다. 이에 따라 초기에 올바르게 구축된 네트워크 아키텍처는 시스템의 안정성과 신뢰성을 유지하는 데 중요한 역할을 합니다. 이번에는 AWS 네트워크 설계 시 고려해야 하는 사항을 알아보겠습니다.

1.1 CIDR는 어떻게 나누어야 할까?

먼저 할당받은 IP 주소를 바탕으로 현재 구축할 환경에 서브넷을 몇 개 생성해야 할지 생각해야 합니다. 예를 들어 VPC에 172.100.16.0/24를 할당하고 이 VPC를 8개의 서브넷으로 나누고 싶다면 다음과 같이 정확하게 8개 서브넷으로 나눌 수 있으며 각 서브넷은 27개 사용 가능한 호스트 ID 즉 IP 주소를 가질 수 있습니다.

하지만 /27로 설정하여 서브넷을 나눈다면 서브넷을 추가할 수 없는 상황이 발생할 수 있으므로, 항상 여유분을 고려하여 CIDR을 설정하는 것이 중요합니다. 다음과 같이/28로 설정하여 여유분을 가지고 만들어두는 것이 좋습니다.

서브넷을 생성할 때는 사용할 IP 주소의 양과 서브넷의 확장 가능성을 고려해야 합니다. 만약 최소 11개 이상의 IP 주소가 필요한 환경이라면, /28로 설정하여 여유분을 가지고 만들어두는 것이 좋습니다. 그러나 서브넷 확장이 불필요하고 IP 주소 수가 중요한 때에는 /27로 서브넷을 생성하는 것이 더 적합할 수 있습니다. 이렇듯 서브넷을 나눌 때 IP 주소를 우선시할지, 서브넷 확장을 우선시할지 결정하는 것이 중요합니다. 또한 AWS에서 서브넷의 CIDR 중 다음 5가지는 사용할 수 없습니다.

10.94.4.0 : 네트워크 주소입니다.

10.94.4.1 : AWS가 VPC 라우터용으로 예약했습니다.

10.94.4.2 : AWS에서 예약

10.94.4.3 : 향후 사용을 위해 AWS에서 예약합니다.

10.94.4.255 : 네트워크 브로드캐스트 주소입니다.

이 외, IP 사용이 필요하게 되는 케이스는 다음과 같습니다.

EC2 인스턴스 생성

탄력적(Elastic) IP 할당

NAT 게이트웨이 생성

VPC 엔드포인트 생성

로드 밸런서(Load Balancer) 생성

ELB를 배치하는 서브넷은 /27이상의 CIDR이며, 적어도 빈 IP를 8개 준비해야 합니다. 서브넷 여유분까지 고려했다면 VPC CIDR를 생각할 차례입니다. 복수의 VPC를 생성할 때에도 VPC CIDR의 중복에 주의해야 합니다. 예를 들어 VPC CIDR가 172.100.16.0/20으로 설정된 경우, 이는 172.100.16.0부터 172.100.31.255까지의 IP 주소 범위를 포함합니다. 만약 두 번째 VPC의 세 번째 옥텟을 16 ~ 31 사이로 지정한다면 IP 주소 범위가 중복됩니다. 따라서 VPC를 생성할 때는 이미 생성된 다른 VPC의 CIDR 범위와 겹치지 않는지를 확인해야 합니다.

1.2 VPC 분할 패턴

AWS를 사용함에 있어 복수의 VPC를 구성할 수 있고, 목적에 따라 VPC를 나누거나 계정별로 VPC를 나눌 필요가 있습니다. 이번에는 VPC를 분할하는 패턴을 알아보겠습니다.

단일 계정으로 VPC 분할

단일 계정을 사용한다면 네 가지 패턴으로 나누어볼 수 있습니다.

단일 VPC 구성 : 단일 VPC에 복수의 환경과 시스템을 구성하는 방법입니다.

환경, 시스템별 VPC 구성 : 환경, 시스템에 따라서 VPC를 나누어 구성하는 방법입니다.

시스템별 VPC 구성 : 여러 시스템을 각 VPC로 나누는 방법입니다.

환경별 VPC 구성 : 각 환경(예 : 개발, 테스트, 운영)을 별도의 VPC로 나누어 구성하는 방법입니다.

환경별 AWS 계정 분할

환경별로 AWS 계정을 분할하면 두 가지 패턴으로 나누어볼 수 있습니다.

시스템별 VPC 구성 : 환경별로 AWS 계정을 나누고, 시스템별로 VPC를 나누어 구성하는 방법입니다.

단일 VPC 구성 : 환경별로 AWS 계정을 나누고, 단일 VPC에 시스템을 구성하는 방법입니다.

시스템별 AWS 계정 분할

환경별 VPC 구성 : 시스템별로 AWS 계정을 나누고, 환경별로 VPC를 나누어 구성하는 방법입니다.

단일 VPC 구성 : 시스템별로 AWS 계정을 나누고, 단일 VPC에 환경을 구성하는 방법입니다.

2. AWS 네트워크 구축을 위한 다양한 서비스 알아보기

AWS에서 네트워크를 구축함에 있어 VPC뿐만 아니라 다양한 서비스를 제공하고 있습니다. 온프레미스 환경과 VPC를 연결하고 싶다면 어떻게 해야 할까요? 또, 서로 다른 VPC를 연결하여 송수신을 하고 싶다면 어떻게 해야 할까요? 이번에는 이런 문제를 해결하는 다양한 서비스를 알아보겠습니다.

2.1 VPC 피어링

VPC 피어링Peering은 서로 다른 VPC를 연결하여 데이터 송수신을 도와주는 서비스입니다. 이 서비스는 복수의 VPC를 연결할 수 없으며, 일대일 관계를 가집니다. 같은 계정 내 VPC 간 연결과 계정과 계정 사이의 VPC 연결을 지원합니다. 또한 VPC 피어링 생성에 대한 비용은 무료이며, VPC 피어링을 통한 데이터 전송도 무료로 이용할 수 있습니다.

▼ VPC 피어링 구성 예

2.2 Site to Site VPN

AWS에서는 온프레미스와의 연결을 위한 다양한 방법을 제공하고 있으며, 그중 Site-to-Site VPN은 AWS와 온프레미스 간에 안전한 연결을 생성하는 서비스입니다. 이 서비스를 통해 온프레미스 네트워크와 AWS 클라우드 간에 암호화된 터널을 설정하여 데이터를 안전하게 전송할 수 있습니다. Site-to-Site VPN은 IPsec 프로토콜을 사용하여 터널을 설정하며, 고유한 공인 IP 주소를 사용하여 두 지점 간의 통신을 보호합니다. 이를 통해 민감한 데이터의 안전한 전송과 온프레미스 및 AWS 리소스 간의 확장 가능한 네트워크 연결이 가능해집니다. 2024년 서울 리전 기준으로 시간당 USD 0.05 요금이 발생합니다.

▼ Site to Site VPN 구성 예

2.3 트랜짓 게이트웨이

VPC 피어링은 VPC간 일대일 연결을 지원합니다. 그렇다면 VPC가 점점 늘어난다면 어떻게 될까요? VPC가 늘어나는 만큼 VPC 피어링 생성하여 연결한다면 네트워크 구성이 복잡해집니다. AWS에서는 이런 문제점을 해결할 수 있는 트랜짓 게이트웨이Transit Gateway를 제공하고 있습니다. 트랜짓 게이트웨이를 사용하면 여러 VPC 간의 연결을 중앙 집중화하여 관리할 수 있으며 Site to Stie VPN을 이용하여 다수의 VPC와 온프레미스가 상호작용할 수도 있습니다. 이를 통해 네트워크 관리 및 보안 정책 적용이 간편해지며, 확장성과 유연성을 제공합니다. 따라서 VPC 수가 늘어나더라도 네트워크 구성을 효율적으로 관리할 수 있습니다. 트랜짓 게이트웨이는 시간당 요금이 발생하며, 2024년 서울 리전 기준으로 연결당 0.07 USD이고,, 트랜짓 게이트웨이를 통해 처리된 데이터는 GB당 0.02 USD 요금이 발생합니다.

▼ 트랜짓 게이트웨이 구성 예

2.4 다이렉트 커넥트

다이렉트 커넥트Direct Connect는 Site-to-Site VPN과 유사하게 AWS 환경과 온프레미스를 연결하는 서비스입니다. Site-to-Site VPN은 온프레미스와 AWS 사이에 VPN 터널을 설정하여 안전한 연결을 제공하는 반면, 다이렉트 커넥트는 물리 전용선을 통해 비공개 접속을 시도하며, 고속 네트워크 대역에서 안정적인 통신을 제공합니다. Site-to-Site VPN은 단기간에 도입이 가능하고 비용이 비교적 낮다는 장점이 있습니다. 반면에 다이렉트 커넥트는 물리 전용선을 사용하여 고속 및 안정적인 연결을 제공하나, 초기 설정 및 구축에는 시간과 비용이 더 많이 소요될 수 있습니다. 이런 다이렉트 커넥트의 접속 방식은 두 가지로 나누어볼 수 있습니다.

▼ 단일 가상 프라이빗 게이트웨이를 통한 다이렉트 커넥트 구성

먼저 단일 가상 프라이빗 게이트웨이Virtual Private Gateway를 통한 다이렉트 커넥트 구성입니다. 데이터센터 운영 업체 등 별도의 전문 업체를 통해 전용선을 구성하면 AWS에서는 가상 인터페이스Virtual Interface가 생성됩니다. 가상 인터페이스는 AWS 환경과 온프레미스 환경을 원활하게 연결하게 도와줍니다. 이런 가상 인터페이스와 가상 프라이빗 게이트웨이를 연결하는 것으로 온프레미스와 AWS 환경을 연결할 수 있습니다. 가상 프라이빗 게이트웨이 구성 자체에 비용은 발생하지 않습니다. 단일 가상 프라이빗 게이트웨이의 장단점은 다음과 같습니다.

▼ 다이렉트 커넥트 게이트웨이와 가상 프라이빗 게이트웨이를 통한 다이렉트 커넥트 구성

다음은 다이렉트 커넥트 게이트웨이Direct Connect Gateway와 가상 프라이빗 게이트웨이를 통한 다이렉트 커넥트 구성입니다.

다이렉트 커넥트 구성은 가상 프라이빗 게이트웨이와 유사하게 동작하지만 가상 프라이빗 게이트웨이 앞에 다이렉트 커넥트 게이트웨이를 추가하는 차이가 있습니다. 다이렉트 커넥트 게이트웨이는 가상 인터페이스와 일대일 관계를 갖지만, 최대 20개의 가상 프라이빗 게이트웨이를 연결할 수 있어서 하나의 가상 인터페이스로 여러 VPC를 연결할 수 있습니다. 이를 통해 네트워크 구성을 더욱 유연하게 관리할 수 있습니다. 다이렉트 커넥트 게이트웨이 구성 자체에 비용은 발생하지 않습니다. 다이렉트 커넥트 게이트웨이와 가상 프라이빗 게이트웨이 구성의 장점은 다음과 같습니다.

이 구성에는 이렇다할 단점은 없기 때문에 현재 AWS에서는 다이렉트 커넥트 게이트웨이와 가상 프라이빗 게이트웨이 구성으로 다이렉트 커넥트를 구성하는 것을 권장하고 있습니다.

3. AWS 네트워크 환경 구축하기

이번에는 앞에서 살펴본 내용을 바탕으로 AWS 클라우드포메이션을 이용하여 AWS 상에서 네트워크 환경을 구축하겠습니다.

3.1 클라우드포메이션으로 네트워크 환경 구축하기

01 단계 네트워크 환경 구축을 위한 클라우드포메이션의 yml 파일은 다음과 같습니다.

```네트워크 환경 구축을 위한 클라우드포메이션 yml 파일

파일 이름 : VPC.yml

클라우드포메이션 스택 생성 순서 : VPC.yml

```

클라우드포메이션 전체 코드는 깃허브 리포지터리 「chapter2」→「VPC」 폴더에서 확인할 수 있습니다. 이번에 구축할 네트워크 환경은 다음과 같습니다.

네트워크 구성은 2개의 퍼블릭 서브넷과 4개의 프라이빗 서브넷으로 구성되며, 인터넷 게이트웨이를 배치하여 퍼블릭 서브넷에서 인터넷과 송수신할 수 있도록 합니다.

02 단계부터는 클라우드포메이션 코드에 대해 설명하며, 클라우드포메이션으로 네트워크 환경을 구축하고 결과를 확인하고 싶다면 2.6.2절 ‘UI로 불러와 AWS 네트워크 환경 구축하기’부터 진행하시기 바랍니다.

02 단계 VPC.yml 파일에 네트워크 환경 구축에 사용할 파라미터를 추가하겠습니다.

```VPC.yml

Parameters: # ➊

SystemName: # ➋

Description: “System name of each resource names.”

Type: String

Default: “gr”

EnvName: # ➌

Description: “Environment name of each resource names.”

Type: String

Default: “product”

VPCParam: # ➍

Description: gr-product-vpc

Type: String

Default: 10.0.0.0/24

PublicSubnet1aParam: # ➎

Description: gr-product-public-subnet-1a

Type: String

Default: 10.0.0.0/27

PublicSubnet1bParam:

Description: gr-product-public-subnet-1b

Type: String

Default: 10.0.0.32/27

WebSubnet1aParam: # ➏

Description: gr-product-web-subnet-1a

Type: String

Default: 10.0.0.64/27

WebSubnet1bParam:

Description: gr-product-web-subnet-1b

Type: String

Default: 10.0.0.96/27

DatastoreSubnet1aParam: # ➐

Description: gr-product-datastore-subnet-1a

Type: String

Default: 10.0.0.128/27

DatastoreSubnet1bParam:

Description: gr-product-datastore-subnet-1b

Type: String

Default: 10.0.0.160/27

```

➊ 클라우드포메이션에서는 파라미터를 이용해 각 항목에 사용자 지정 값을 입력할 수 있습니다. 하드 코딩을 피하고 코드를 간결하게 유지하고자 파라미터를 이용합니다. 파라미터 이름은 SystemName과 같이 임의로 지정할 수 있으며 String문자열 , Number정수와 같은 여러 입력 타입을 지원합니다. ➋ 구축할 환경의 시스템 이름을 정의하는 파라미터입니다. ➌ 구축할 환경의 이름을 정의하는 파라미터입니다. ➍ VPCParam이라는 파라미터 이름을 정의하여 VPC의 CIDR를 정의합니다. ➎ 퍼블릭 서브넷의 CIDR를 정의합니다. ➏ 프라이빗 서브넷의 CIDR를 정의합니다. 이 프라이빗 서브넷은 웹 서버를 배치하기 때문에 주로 NAT 게이트웨이의 라우팅을 설정합니다. ➐ DatastoreSubnet이라고 정의한 프라이빗 서브넷은 외부와의 연결이 완전히 차단되어 있으며, 인터넷 게이트웨이, NAT 게이트웨이의 라우팅 설정 또한 없습니다. 이런 서브넷에는 주로 데이터베이스와 같이 외부와의 연결을 완전히 차단하고자 하는 서비스를 배치합니다.

03 단계 VPC.yml 파일에 VPC와 서브넷 생성을 위한 Resources를 추가하겠습니다.

```VPC.yml

Resources: # ➊

VPC: # ➋

Type: “AWS::ec2::VPC” # ➌

Properties: # ➍

CidrBlock: !Ref VPCParam

EnableDnsSupport: “true”

EnableDnsHostnames: “true”

InstanceTenancy: default

Tags: # ➎

- Key: Name

Value: !Sub ${SystemName}-${EnvName}-vpc

- Key: Env

Value: !Sub ${EnvName}

PublicSubnet1a: # ➏

Type: “AWS::ec2::Subnet”

Properties: # ➐

AvailabilityZone:

Fn::Select:

- 0

- Fn::GetAZs: “”

CidrBlock: !Ref PublicSubnet1aParam # ➑

VpcId: !Ref VPC # ➒

Tags: # ➓

- Key: Name

Value: !Sub ${SystemName}-${EnvName}-public-subnet-1a

- Key: Env

Value: !Sub ${EnvName}

```

➊ 클라우드포메이션에서는 Resources를 이용해 생성하고자 하는 리소스를 정의할 수 있습니다. ➋ 생성할 리소스의 이름은 VPC와 같이 임의로 지정할 수 있습니다. ➌ Resources 내에서 Type을 이용해 생성할 서비스를 정의합니다. ➍ Properties에서는 생성할 리소스의 속성을 정의할 수 있습니다. CidrBlock 항목은 VPC의 CIDR를 의미하는 것으로, VPC CIDR를 입력했던 파라미터를 불러와 CIDR를 정의합니다. 불러오는 방법은 !Ref 내장 함수를 사용하여 불러올 수 있는데, Ref는 reference의 약자로 파라미터 혹은 리소스에 대한 정보를 반환할 때 사용합니다. ➎ 생성할 리소스의 이름과 환경 이름을 입력합니다. 태그는 키밸류 형식으로 입력할 수 있습니다. 입력한 파라미터의 문자열 변수를 불러오기 위해서 내장 함수 !Sub를 이용합니다. ➏ 이어서 서브넷을 정의하는 데, VPC와 마찬가지로 PublicSubnet1a라는 임의의 리소스 이름을 지정하고, Type에는 생성할 서비스 즉 서브넷을 정의합니다. ➐ 서브넷 속성을 지정합니다. 먼저 서브넷을 생성할 가용 영역을 지정합니다. 클라우드포메이션에서는 Fn::GetAZs 내장 함수로 간단하게 가용영역을 지정할 수 있으며, 이 내장 함수에는 지정된 지역의 가용 영역을 알파벳순으로 나열하고 있습니다. 예를 들어 서울 리전을 기준으로는 ap-northeast-2a, ap-northeast-2b, ap-northeast-2c, ap-northeast-2d와 같은 가용 영역이 저장되어 있으며 0은 배열의 첫 번째 값을 의미하므로 ap-northeast-2a가 됩니다. ➑ 파라미터를 불러와 서브넷의 CIDR를 정의합니다. ➒ VPC에서 작은 네트워크 단위로 나눈 서브넷은 VPC에 속해 있어야 하기 때문에 속할 VPC를 지정합니다. ➓ 마지막으로 서브넷의 이름과 환경명을 지정합니다. 나머지 서브넷들도 이와 같은 형식으로 정의합니다.

04 단계 VPC.yml 파일에 인터넷 게이트웨이 생성과 연결을 위한 Resources를 추가하겠습니다.

```VPC.yml

InternetGateway: # ➊

Type: “AWS::ec2::InternetGateway” # ➋

Properties: # ➌

Tags:

- Key: Name

Value: !Sub ${SystemName}-${EnvName}-igw

- Key: Env

Value: !Sub ${EnvName}

InternetGatewayAttachment: # ➍

Type: “AWS::ec2::VPCGatewayAttachment” # ➎

Properties: # ➏

InternetGatewayId: !Ref InternetGateway

VpcId: !Ref VPC

```

➊ 인터넷 게이트웨이를 생성하기 위해 임의의 리소스 이름을 지정합니다. ➋ Type을 이용해 생성할 인터넷 게이트웨이를 정의합니다. ➌ 인터넷 게이트웨이는 태그 이외에는 지정할 속성값이 없으므로 태그를 이용해 인터넷 게이트웨이의 이름과 환경명만을 지정합니다. ➍ 인터넷 게이트웨이를 생성했다면 VPC에 연결할 필요가 있기 때문에 연결을 위한 리소스를 별도로 생성합니다. ➎ Type에는 인터넷 게이트웨이 연결을 위해 VPCGatewayAttachment를 정의합니다. ➏ 연결을 위해 인터넷 게이트웨이와 연결하고자 하는 VPC를 입력합니다. 인터넷 게이트웨이는 서브넷 단위가 아닌 VPC 단위에서 생성되는 서비스입니다.

05 단계 VPC.yml 파일에 라우팅 테이블 생성하는 데 사용할 Resources를 추가하겠습니다.

```VPC.yml

PublicRTB : # ➊

Type: “AWS::ec2::RouteTable” # ➋

Properties: # ➌

VpcId: !Ref VPC

Tags: # ➍

- Key: Name

Value: !Sub ${SystemName}-${EnvName}-public-rtb

- Key: Env

Value: !Sub ${EnvName}

```

➊ 라우팅 테이블을 생성하기 위해 임의의 리소스 이름을 지정합니다. ➋ Type을 이용해 생성할 라우팅 테이블을 정의합니다. ➌ 라우팅 테이블은 VPC 단위에서 생성되는 서비스이기 때문에 라우팅 테이블을 생성할 VPC를 지정합니다. ➍ 마지막으로 라우팅 테이블의 태그를 입력합니다.

06 단계 VPC.yml 파일에 생성한 라우팅 테이블에 인터넷 게이트웨이 경로를 추가하는 Resources를 추가하겠습니다.

```VPC.yml

PublicRoute: # ➊

Type: “AWS::ec2::Route” # ➋

Properties: # ➌

RouteTableId: !Ref PublicRTB

DestinationCidrBlock: “0.0.0.0/0"

GatewayId: !Ref InternetGatew

```

➊ 라우팅을 위한 임의의 리소스 이름을 지정합니다. ➋ Type을 이용해 라우팅 작업을 위해 Route를 정의합니다. ➌ 라우팅 설정을 하고자 하는 라우팅 테이블을 입력하고, 목적지 CIDR를 입력하고 마지막으로 게이트웨이에는 인터넷 게이트웨이를 입력합니다.

07 단계 VPC.yml 파일에 라우팅 테이블과 서브넷을 연결하는 Resources를 추가하겠습니다.

```VPC.yml

PublicRTBAssociation1: # ➊

Type: “AWS::ec2::SubnetRouteTableAssociation” # ➋

Properties: # ➌

SubnetId: !Ref PublicSubnet1a

RouteTableId: !Ref PublicRTB

```

➊ 라우팅 테이블과 서브넷 연결을 위한 임의의 리소스 이름을 지정합니다. ➋ Type에는 라우팅 테이블과 서브넷 연결에 사용할 SubnetRouteTableAssociation을 정의합니다. ➌ 속성에는 서로 연결할 서브넷과 라우팅 테이블을 입력합니다. 나머지 서브넷들도 같은 방식으로 서브넷과 연결합니다.

08 단계 VPC.yml 파일에 템플릿의 출력을 반환하는 Outputs를 추가하겠습니다.

```VPC.yml

Outputs: # ➊

# VPC

VPC: # ➋

Value: !Ref VPC # ➌

Export: # ➍

Name: !Sub ${EnvName}-vpc

```

➊ Resources는 클라우드포메이션 템플릿에서 생성할 서비스의 리소스를 생성하는 속성들을 정의하는 것이었다면, Outputs는 템플릿에서 생성한 리소스를 출력하고 반환하는 역할을 합니다. Outputs를 이용하여 리소스를 출력한다면, 출력한 리소스를 다른 템플릿에서 사용할 수 있습니다. ➋ VPC를 출력하기 위해 임의의 이름을 지정합니다. ➌ Value에는 출력할 리소스를 지정합니다. ➍ Export에서는 어떤 이름으로 리소스를 출력할지 지정합니다. 나머지 서브넷을 포함한 리소스들도 같은 방법으로 출력을 진행합니다.

3.2 UI로 불러와 AWS 네트워크 환경 구축하기

다음은 AWS 네트워크 환경 구축을 어떻게 하는지 UI를 통해 확인해봅시다.

01 단계 우선 클라우드포메이션 스택을 생성합니다. ➊ 클라우드포메이션 스택 이름을 입력합니다. ➋ 클라우드포메이션 템플릿에서 입력했던 파라미터들이 UI로 반환되어 자동으로 파라미터가 완성됩니다. 필요에 따라 UI에서 파라미터 값을 변경할 수 있습니다. ➌ 스택 이름과 파라미터 값을 확인했다면 [다음]을 클릭합니다.

02 단계 스택 옵션 구성을 확인합니다.

스택 옵션 구성은 기본값을 유지한 상태로 ➍ [다음]을 클릭합니다.

03 단계 생성할 템플릿을 확인하고 클라우드포메이션 스택을 생성합니다. 검토 및 작성 화면에서 입력한 스택 이름과 파라미터 값을 확인하고 ❶ [전송] 버튼을 클릭하여 스택을 생성합니다.

04 단계 클라우드포메이션 스택 생성을 확인합니다. 스택 생성은 ‘CREATE_IN_PROGRESS’를 거쳐 ‘CREATE_COMPLETE’로 변경되는 과정을 확인할 수 있습니다. 이벤트 탭에서 생성된 리소스를 확인할 수 있으며 출력 탭을 통해서 Outputs를 이용해 출력한 리소스 목록을 확인할 수 있습니다.

05 단계 VPC 콘솔 화면에서 구축한 네트워크 환경을 확인합니다. VPC 콘솔 화면으로 이동하면 생성된 네트워크 리소스를 확인할 수 있습니다.

📚 더 읽기

저자 소개

📚《AWS 잘하는 개발자 되기》 자주 묻는 질문

Q.AWS를 시작하려는데, 어디서부터 시작해야 할지 막막합니다. 이 책이 도움이 될까요?

AWS 입문을 망설이는 분들을 위해 이 책은 매우 훌륭한 길잡이가 될 수 있습니다. AWS는 방대한 서비스 집합체이기 때문에, 처음 접하는 사람에게는 어디서부터 시작해야 할지 막막하게 느껴질 수 있습니다. 이 책은 바로 이러한 어려움을 해소하기 위해 'AWS를 쓰려면 알아야 하는 넓고 얕은 배경지식'과 'AWS를 잘 쓰려면 반드시 필요한 네트워크 지식'을 체계적으로 정리하여 제공합니다. AWS의 기본적인 개념부터 필수적인 네트워크 지식까지, 탄탄한 기초를 다질 수 있도록 돕는 것이죠. 특히, 3년 연속 〈Japan AWS All Certifications Engineer〉를 수상한 저자의 노하우가 담겨 있어, 이론적인 설명뿐만 아니라 실제 개발 현장에서 마주칠 수 있는 문제들을 해결하는 데에도 큰 도움이 될 것입니다. 입문자뿐만 아니라, 기본을 다시 다지고 싶은 초보 개발자, 대규모 서비스 운영 경험을 엿보고 싶은 중급 개발자 모두에게 유용한 책입니다. AWS 여정을 시작하는 데 든든한 동반자가 되어줄 것입니다. 《AWS 잘하는 개발자 되기》를 통해 AWS 전문가로 발돋움해보세요.

Q.이 책은 어떤 개발자에게 가장 적합한가요? 백엔드 개발 경험이 없어도 괜찮을까요?

《AWS 잘하는 개발자 되기》는 AWS를 처음 접하는 개발자뿐만 아니라, AWS를 사용하고 있지만 더욱 깊이 있는 이해를 원하는 개발자 모두에게 적합합니다. 특히, 백엔드 개발 경험이 부족하더라도 AWS의 기본적인 개념과 네트워크 지식을 쌓을 수 있도록 구성되어 있어, 충분히 따라갈 수 있습니다. 책에서는 AWS를 사용하기 위한 넓고 얕은 배경지식부터 시작하여, AWS를 효율적으로 활용하기 위한 네트워크 지식을 자세하게 설명합니다. 200여 개의 시스템 구성과 도표를 통해 시각적으로 이해를 돕고 있어, 개념을 더욱 명확하게 파악할 수 있습니다. 백엔드 개발 경험이 없더라도, 책에서 제시하는 로드맵을 따라 차근차근 학습하면 AWS를 활용한 개발 능력을 향상시킬 수 있습니다. 3년 연속 〈Japan AWS All Certifications Engineer〉를 수상한 저자의 경험과 노하우가 담겨 있어, 실제 개발 현장에서 마주할 수 있는 문제들을 해결하는 데에도 큰 도움이 될 것입니다. 백엔드 개발 경험이 없더라도 AWS를 배우고 싶다면, 《AWS 잘하는 개발자 되기》가 훌륭한 입문서가 될 것입니다.

Q.이 책에서 다루는 AWS 서비스는 어떤 것들이 있나요? 주요 서비스 위주로 설명되어 있나요?

《AWS 잘하는 개발자 되기》는 AWS의 핵심적인 서비스들을 폭넓게 다루면서도, 각 서비스의 깊이 있는 이해를 돕는 데 초점을 맞추고 있습니다. 단순히 나열하는 것이 아니라, 실제 개발 현장에서 자주 사용되는 주요 서비스들을 중심으로 설명하고, 각 서비스가 어떻게 연동되어 시너지를 내는지 보여줍니다. 이 책은 AWS 입문자와 초급 개발자를 대상으로 하기 때문에, 복잡하고 난해한 고급 기능보다는 기본적인 사용법과 핵심 개념을 중심으로 설명합니다. 3년 연속 〈Japan AWS All Certifications Engineer〉를 수상한 저자는, AWS 서비스를 효과적으로 활용하기 위한 실질적인 팁과 노하우를 아낌없이 공유합니다. 200여 개의 시스템 구성과 도표는 독자들의 이해도를 높이는 데 크게 기여합니다. AWS의 주요 서비스들을 체계적으로 학습하고, 실제 개발에 적용할 수 있는 능력을 키우고 싶다면, 《AWS 잘하는 개발자 되기》가 좋은 선택이 될 것입니다.

Q.책에서 설명하는 네트워크 지식은 어느 정도 수준인가요? 네트워크 기초가 부족해도 이해할 수 있을까요?

《AWS 잘하는 개발자 되기》는 AWS를 효과적으로 사용하기 위해 반드시 필요한 네트워크 지식을 상세하게 다룹니다. 네트워크 기초가 부족한 분들도 쉽게 이해할 수 있도록, 기본적인 개념부터 차근차근 설명합니다. IP 주소, 서브넷, 라우팅, 방화벽 등 네트워크의 핵심 요소들을 그림과 함께 설명하여 시각적인 이해를 돕고, AWS 환경에서 이러한 요소들이 어떻게 적용되는지 명확하게 보여줍니다. 또한, AWS의 Virtual Private Cloud (VPC)와 같은 네트워크 서비스를 설정하고 관리하는 방법을 단계별로 안내하여, 실제 환경에서 네트워크를 구축하고 운영하는 데 필요한 실질적인 능력을 키울 수 있도록 돕습니다. 3년 연속 〈Japan AWS All Certifications Engineer〉를 수상한 저자의 경험을 바탕으로, 네트워크 기초가 부족한 개발자도 AWS를 능숙하게 사용할 수 있도록 돕는 것이 이 책의 목표입니다. 《AWS 잘하는 개발자 되기》를 통해 네트워크 기초를 다지고 AWS 전문가로 거듭나세요.

Q.스터디 모임 '내코부'는 무엇인가요? 책을 읽고 스터디에 참여하면 어떤 도움이 되나요?

'내코부, 내 코드를 부탁해'는 골든래빗에서 운영하는 개발자 성장 프로젝트의 일환으로, 함께 공부하고 토론하며 성장하는 스터디 모임입니다. 《AWS 잘하는 개발자 되기》를 읽고 내코부 스터디에 참여하면, 책의 내용을 더욱 깊이 있게 이해하고 실질적인 활용 능력을 키울 수 있습니다. 스터디에서는 책에서 다루는 AWS 서비스들을 직접 사용해보고, 서로의 경험을 공유하며 배우는 시간을 갖습니다. 또한, AWS 전문가의 멘토링을 통해 어려운 문제를 해결하고, 자신의 프로젝트에 AWS를 적용하는 방법을 배울 수 있습니다. 혼자 공부할 때는 놓치기 쉬운 부분을 스터디 멤버들과 함께 토론하며 보완하고, 다양한 관점을 접할 수 있다는 장점도 있습니다. 스터디를 통해 얻은 지식과 경험은 실제 개발 현장에서 문제를 해결하고, 더 나은 코드를 작성하는 데 큰 도움이 될 것입니다. 내코부 디스코드 채널(discord.com/invite/BYRpaDrfbH)에서 스터디에 참여하고, 함께 성장하는 기회를 잡아보세요. 《AWS 잘하는 개발자 되기》와 내코부 스터디를 통해 AWS 전문가로 도약하세요.

Q.책에 200여 개의 시스템 구성과 도표가 있다고 하는데, 그림 자료가 많은 편인가요? 시각적으로 이해하기 쉬운가요?

네, 《AWS 잘하는 개발자 되기》는 200여 개의 시스템 구성과 도표를 사용하여 AWS의 복잡한 개념을 시각적으로 명확하게 전달하는 데 중점을 두고 있습니다. 단순히 텍스트로만 설명하는 것이 아니라, 그림과 도표를 통해 AWS 서비스의 작동 방식, 아키텍처 구성, 데이터 흐름 등을 한눈에 파악할 수 있도록 돕습니다. 특히, AWS의 다양한 서비스를 조합하여 복잡한 시스템을 구축하는 과정을 그림으로 보여주기 때문에, 전체적인 구조를 이해하는 데 매우 효과적입니다. 또한, 각 도표에는 상세한 설명이 덧붙여져 있어, 그림만으로는 이해하기 어려울 수 있는 부분까지 명확하게 해소해줍니다. 그림 자료가 풍부하고 시각적으로 이해하기 쉽기 때문에, AWS를 처음 접하는 사람도 부담 없이 학습할 수 있습니다. 3년 연속 〈Japan AWS All Certifications Engineer〉를 수상한 저자의 노하우가 담긴 시각 자료들은, 독자들의 AWS 이해도를 높이는 데 크게 기여할 것입니다. 《AWS 잘하는 개발자 되기》로 시각적인 학습을 통해 AWS를 마스터하세요.

Q.이 책을 읽고 AWS Certified Cloud Practitioner 자격증 시험 준비에도 도움이 될까요?

《AWS 잘하는 개발자 되기》는 AWS Certified Cloud Practitioner 자격증 시험 준비에도 충분히 도움이 될 수 있습니다. 이 책은 AWS의 기본적인 개념과 서비스들을 폭넓게 다루고 있으며, 시험에서 자주 출제되는 핵심 내용들을 자세하게 설명합니다. 특히, AWS의 주요 서비스들에 대한 설명은 시험 준비에 필수적인 지식을 제공하며, 200여 개의 시스템 구성과 도표는 AWS 아키텍처에 대한 이해도를 높여줍니다. 또한, 책에서 다루는 네트워크 지식은 시험의 네트워크 관련 문제 해결에 도움이 될 것입니다. 물론, 이 책만으로 모든 시험 문제를 완벽하게 대비할 수는 없지만, AWS Certified Cloud Practitioner 시험의 기본적인 내용을 이해하고 합격에 필요한 기반 지식을 쌓는 데 매우 효과적입니다. 추가적으로 AWS에서 제공하는 공식 문서나 모의고사를 함께 활용하면 더욱 효과적인 시험 준비가 될 것입니다. 《AWS 잘하는 개발자 되기》로 AWS Certified Cloud Practitioner 자격증 취득에 한 걸음 더 다가가세요.