AWS Virtual Private Cloud(VPC)는 AWS 안에서 논리적으로 격리된 Private Network를 구축하는 개념이다.
대부분의 AWS 리소스는 설정 단계에서 VPC와 Subnet을 요구한다.
AWS 사용에 필수적인 개념이므로 계정은 Default로 설정된 VPC와 Subnet들을 가지고 있다.
개인 프로젝트를 진행할 때는 Default로 충분하지만, 실무에서는 최소한 Dev와 Prod로는 VPC를 구분할 필요가 있다.
AWS 서비스 검색을 통해서 vpc 를 검색하자.
의외로 많이 들어갈 페이지니까 별표를 눌러서 즐겨찾기 해두는 것도 좋다.
VPC 페이지에 들어가면 AWS VPC 리소스의 종류가 꽤 많다는 것을 알 수 있다.
이미지는 화면의 일부만 캡처한 것이다.
주로 사용하게될 AWS 리소스들을 나열해보면 아래와 같다.
AWS를 좀 더 잘 활용하면 몇 가지 더 있을텐데, 내 수준에서는 이 정도로만 사용하고 있다.
이전의 VPC 대시보드 화면에서 [Virtual Private Cloud] 하위의 **[VPC]**를 클릭한다.
다음 화면에서 [VPC 생성] 버튼을 누른다.
[생성할 리소스] 에 [VPC만] 과 [VPC 등] 의 선택지가 존재하는데, 우리는 [VPC만] 을 선택한다.
[VPC등] 을 선택하면 VPC, Public Subnet, Private Subnet, Routing Table, IGW까지 생성해준다.
(심지어 선택하면 S3에 연결되는 VPC 엔드포인트까지…)
하지만 자동으로 다 생성해버리면 이후에 서비스 구성 도중 문제가 생길 경우 오히려 해결을 못한다.
귀찮더라도 처음에는 하나씩 직접 만들면서 이해도를 높이는 것을 추천한다.
이름 태그는 dev-vpc 로 했다.
나는 {env}-{resource}-{etc} 로 이름 태그를 구성하는 것을 선호하는 편이다.
IPv4 CIDR는 10.0.0.0/16 으로 했는데, VPC의 CIDR는 서비스 구성을 고려해서 신중하게 써야 한다.
CIDR 설정에 따라서 사용할 수 있는 IP 갯수가 고정되기 때문이다.
서비스가 성장하면서 더 많은 호스트를 추가해야하는데, 네트워크에 가용 IP가 없으면 추가가 불가능하다.
나중에 귀찮아지기 싫으면 처음에 적당히 크게 잡아두는 것이 좋다.
10.0.0.0/16 의 경우, 10.0.0.0 ~ 10.0.255.255 의 IP 범위를 갖는다.
총 65,536 개의 호스트(서비스)를 생성할 수 있는 것이다.
저 숫자가 상당히 많아보일 수 있지만 서비스 특성에 따라서는 적은 숫자일 수도 있다.
아무튼 [VPC 생성] 버튼을 누르면 VPC 생성은 끝이다.
VPC 생성이 끝나면 다음과 같은 화면을 볼 수 있을텐데, DNS 호스트 이름 이 기본 비활성화 되어 있다.
뭔가 문제가 생기면… [VPC 설정 편집] 에 들어가서 켜보면 해결될 수도 있다.
나는 지금까지 두 번 해당 설정으로 인한 문제를 겪었다.
