지난 번에 그려놨던 아키텍쳐를 토대로 VPC 및 서버(인스턴스) 설정의 절차를 소개하겠다.
1. Root 사용자 vs IAM 사용자
일단 AWS "콘솔에 로그인" 을 누르면
IAM 사용자 로그인창이 먼저 뜨지만,
아래의 Sign in using root user email을 클릭하도록 하자.
그러면 오른쪽과 같이 나올 것이다.
우리는 서버(인스턴스)를 생성하고,
초기 설정을 해야하기 때문에 root 사용자를 선택해야 한다.
- Root 사용자 : 모든 AWS의 권한을 갖고 있는 사용자
- 인스턴스 및 서비스의 생성, 관리 및 삭제를 할 수 있다.
- 서버를 관리할 관리자 개념인 IAM 계정을 등록할 수 있다.
- 그 외의 루트 권한이 필요한 모든 작업을 수행 가능하다.
- IAM( Identity and Access Management ) 사용자
- 루트 사용자가 만든 서비스에 접근이 가능한 사용자
- AWS에서 만들어진 서비스에 접근해 관리를 해야 할 경우, 루트 사용자의 허가를 받아 권한을 얻어야 한다.
- 참고로, IAM의 경우는 어디에서나 접근이 가능해야 하기 때문에
이 서비스는 Region에 상관없는 Global 서비스로 다뤄진다.
2. VPC 생성
루트 사용자로 로그인 했다면, VPC를 검색해 왼쪽의 VPC 탭을 누른다.
그 후, 오른쪽 상단의 vpc 생성을 클릭
- VPC만
- 이름은 아무렇게나 지정 : namu-cy-vpc로 지정했다.
- IP v4 CIDR 수동 입력
- IP v4 CIDR에 10.0.0.0 / 24 를 입력
- 8개의 가변영역 비트, 즉 256개의 private IP를 사용할 것이다.
- 참고로 10.0.0.0에는 아무런 값을 집어 넣어도 된다. 불변 영역을 건드리지 않는다는 가정하에 말이다.
- 테넌시는 기본 값
- 태그 추가 상관없음.
참고로 "VPC 등"을 선택할 경우,
아래의 그림처럼 미리 깔끔하게 초기설정이 진행된 것을 전부 생성한다.
(VPC, 서브넷, 라우팅 테이블, 네트워크 연결까지.)
그렇지만 우리가 만들 것은 서버만이 있을 뿐, S3를 통한 정적 리소스 관리는 안 할 것이므로
이 방식을 선택하지는 않겠다.
3. 서브넷 생성
VPC 탭의 밑에 있는 서브넷을 누른 후 오른쪽 상단의 서브넷 생성을 누른다.
그런 뒤 아까 만들어 둔 서브넷을 선택하고,
public 2개와 private 2개를 각각 만들어야 한다. (이름은 어떻게 되든 좋다. public과 private의 구분,
그리고 각각의 서브넷끼리의 구분이 가능하도록 구성해야 한다.)
또한, 256개의 사설 IP를 4등분하는 것이 좋다.
가용성을 생각하면 아래와 같이 구성하는게 좋을 것이다.
subnet 이름 | 가용 영역 | IPv4 서브넷 CIDR 블록 |
namu-cy-public-0 | ap-northeast-2a | 10.0.0.0/26 |
namu-cy-public-1 | ap-northeast-2b | 10.0.0.64/26 |
namu-cy-private-0 | ap-northeast-2a | 10.0.0.128/26 |
namu-cy-private-1 | ap-northeast-2b | 10.0.0.192/26 |
맨 아래의 "새 서브넷 추가"를 통해서 4개를 한 번에 만들 수 있으니 활용하는게 좋다.
4. 인터넷 게이트웨이 : public 서브넷에 public 속성을 부여하기 위한 준비물
VPC의 인터넷 게이트웨이 탭에 들어가 우측 상단의 인터넷 게이트웨이 생성을 누르고,
IGW의 이름을 정한뒤 생성한다.
그리고 다시 인터넷 게이트웨이로 돌아와 아까 생성한 IGW를 선택한 후,
우측 상단의 "작업" ➡️ "VPC에 연결"
➡️ 만들어둔 VPC를 선택 ➡️ "인터넷 게이트웨이 연결" 버튼으로 VPC와 연결한다.
5. 라우팅 테이블 : private IP의 교통 정리, 주소록 같은 느낌이다.
public 라우팅 테이블과 private 라우팅 테이블을 생성하고
아래의 "서브넷 연결" 에서
public 라우팅 테이블에는 두 개의 public 서브넷을, private에도 같은 방식으로 두 개를 연결해주고
"라우팅" 탭에서 아래와 같이 라우팅을 진행해줘야한다.
public route table의 경우 | |
대상 (CIDR로 이뤄진 목적지 (Destination)) | 대상 (Target) |
0.0.0.0 / 0 | IGW |
10.0.0.0 / 24 | local |
private route table의 경우 | |
대상 (CIDR로 이뤄진 목적지 (Destination)) | 대상 (Target) |
0.0.0.0 / 0 | IGW |
10.0.0.0 / 24 | local |
public설명하자면, 0.0.0.0 / 0,
즉 내부의 private 인스턴스들이 향하는 목적지가 0.0.0.0 / 0 의 대역의 트래픽일 경우,
IGW로 보내 외부로의 요청을 하도록 라우팅하고,
10.0.0.0 / 24 대역의 트래픽일 경우 local의 private IP를 가진 서버들로 보낸다.
그런데 저 두 개의 가용 영역은 서로 중복되지 않는가?
0.0.0.0 / 0에는 10.0.0.0 / 24가 포함되어 있다.
이렇게 될 경우, 조금 더 구체적인 범위의 규칙을 적용한다.
후자가 더 구체적이므로 후자의 규칙이 적용된다.
'연재작 > Network' 카테고리의 다른 글
Image 파일은 서버를 거치지 않아도 된다. (0) | 2024.11.01 |
---|---|
GET 요청 시 Body(JSON)를 사용하지 않는 이유 (2) | 2024.10.28 |
AWS EC2 Private Instance 구축 (1) Architecture (0) | 2024.10.26 |
TCP/IP 4계층, OSI 7계층, Handshaking? chatGPT와 정리 (5) | 2024.09.01 |