AWS - VPC peering, Volume생성, Snapshot, AMI

1. VPC 만들기

1.1. vpc 생성

- ip 대역대를 만드는 순가 DHCP서버가 생성되어 해당 대역대에서 임의로 IP 할당

- 기본적인 라우팅 테이블이 만들어진다

- nacl 역시 자동으로 생성

 

- DNS 호스티 이름 활성화 버튼 클릭

 

* 서브넷 생성

1.2.  public subnet 만들기

- subnet 화면에서 오른쪽 상단에 서브넷 생성 클릭

- my-pub-2a : 10.37.0.0/20

- my-pub-2b : 10.37.16.0/20

- my-pub-2c : 10.37.32.0/20

- my-pub-2d : 10.37.48.0/20

 

 

1.3. Public subnet에 공인 IP 할당

- public subnet에는 공인 IP를 할당하여 외부에서 접근이 가능하도록 만들어야한다.

 

1.4.  private subnet 만들기

- my-pvy-2a : 10.37.64.0/20

- my-pvy-2b : 10.37.80.0/20

- my-pvy-2c : 10.37.96.0/20

- my-pvy-2d : 10.37.112.0/20

 

1.5. 인터넷 게이트웨이 생성

- 이름만 주면 된다

- vpc -> subnet -> 인터넷 게이트웨이 순서로 생성

 

- vpc와 연결해야 라우팅 테이블 생성가능

- 이전에 생성한 vpc를 선택해서 연결한다.

1.6. 라우팅 테이블 추가

- VPC를 생성하면 기본적으로 내부통신이 가능한 라우팅 테이블이 생성된다.

 

- igw를 대상으로 하고 모든 IP(0.0.0.0/16)을 목적지로 하는 테이블을 하나더 만든다

 

- 명시적 서브넷 생성(라우팅 테이블에 명시된 라우팅 정보를 선택한 서브넷에 전달하기 위해서 명시적 서브넷을 생성)

- my-pub-rtb 화면에서 아래 태그의 서브넷 연결을 누르고 

- 서브네 연결 편집을 눌러 명시적 서브넷을 생성한다.

 

- private 라우팅 테이블에도 명시적 서브넷 연결을 설정해준다.

 

- 최종적으로 만들어진 라우팅 테이블을 확인한다.

 

2. 인스턴스 생성

2.1. Seoul instance

- 이름 : Seoul

- OS : Amazon Linux

- 기존에 사용하던 Key가 있지만 새로운 Key 생성해서 사용해본다.

 

- vpc : my-vpc

- 서브넷 : my-pub-2a

- 보안그룹 : my-sg-web

 

- ssh, HTTP, HTTPS, ICMP의 인바운드(inbound) 규칙을 생성한다.

 

- 마지막으로 사용자데이터를 넣어주고 인스턴스를 생성한다.

- 이 인스턴스는 서울의 인스턴스고 추후에 도쿄 리전의 인스턴스를 생성하여 서로의 VPC를 연결할 예정이다.

 

2.2. Tokyo instance

- 오른쪽 상단에서 리전을 도쿄로 변경해준다

 

- 이름 : tokyo

- OS : Ubuntu Server 20.04 LTS

 

- 인스턴스 유형은 

- 키 페어는 리전 별로 존재하기 때문에 Key가 없다

- 도쿄리전의 인스턴에 접근하기 위한 새로운 Key를 생성

 

- 도쿄 리전은 vpc를 사용하지 않고 default vpc 활용한다

- 도쿄 리전은 가용 영역이 총 3개

 

- ssh, HTTP, HTTPS, ICMP의 인바운드(inbound) 규칙을 생성한다.

- 대부분 어디서든 접근할 수 있도록 소스 유형을 위치무관을 해주었다.

3. VPC Peering

1. VPC 피어링 연결은 프라잆 IPv4 주소 또는 IPv6주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워킹 연결.

2. 동일한 네트워크에 속하는 경우와 같이 VPC의 인스턴스가 서로 통신이 가능하다.

3. VPC는 다른 리전에 있을 수 있다. (리전 간 VPC 피어링 연결이라고도 함)

 

- 서울리전의 VPC와 도쿄 리전의 VPC를 연결

- 각 리전의 VPC의 Private 서브넷들이 서로 통신되도록 만드는게 목표다

 

- 서울과 도쿄리전에서 생성한 인스턴스들을 MobaXterm을 이용하여 접근한다.

- curl 127.0.0.1 명령어를 통해 접근한 리전들을 확인한다.

 

- 서울이나 도쿄 한곳에서 VPC 연결 요청이 필요하다

 

- 서울 리전에서 도쿄 리전으로 VPC 피어링 연결 생성

- CIDR : 인터넷상의 데이터 라우팅 효율성을 향상시키는 IP 주소 할당 방법

- 계정 : 내 계정 안에 있는 VPC 연결

- 리전 : 현재 서울 리전에 있기 때문에 도쿄로 연결 요청을 위해 "다른 리전"을 선택

- VPC ID : 도쿄 리전에 있는 VPC의 아이디를 확인하고 적어준다.

 

- 피어링 생성이 완료되면 서울 리전에서 요청을 보냈다는 메세지가 나온다

 

- 도쿄 리전으로 이동하여 피어링 연결 화면을 보면 수락 대기 중인 상태를 확인할 수 있다.

- 요청 수락을 누르면 서울과 도쿄, 두 리전의 VPC 간의 연결이 이루어 진다.

- 하지만, 라우팅 테이블을 작성하지 않았기 때문에 서로의 Private subnet 간의 통신은 불가능 하다.

 

 

- 도쿄 리전 VPC의 라우팅 테이블 수정

- PCX을 Next Hop으로 설정하여 Seoul리전 VPC의 대역대(10.37.0.0/20)로 연결한다.

- 서울 리전에서도 라우팅 테이블 설정을 해야 양방향으로 통신이 가능하다.

 

- 라우팅 편집 버튼을 눌러서 도쿄 리전의 private IP 대역을 넣어서 라우팅 테이블 설정을 맞춰준다

 

- 서울 -> 도쿄로 Ping Test 진행 : 정상

- 도쿄-> 서울로 Ping Test 진행 : 정상

 

- 알리바바 클라우드에서 Domain 생성 후 접근

- GCP나 다른 서비스에서도 DNS 서버를 따로 두어서 다른 플랫폼과 연결이 가능하다

- DNS 주소로 접근하면 사용자 데이터로 정의한 정보가 나온다.

 

4. 볼륨

4.1. 볼륨 생성 후 마운트

- 서울 리전 인스턴스에 붙일 볼륨을 하나 생성한다.

- 크기 : 1GB

- 가용영역 : ap-northeast-2a

- 생성한 볼륨을 인스턴스에 연결하기 위해서 볼륨연결 버튼을 눌러준다.

- 인스턴스를 서울리전에 있는 인스턴스로 설정하고, /dev/sdf라는 이름을 볼륨을 연결한다.

 

lsblk
sudo mkfs -t ext4 /dev/xvdf
sudo mount /dev/xvdf /mnt
df -h

- mobaXterm으로 접근한 서울의 인스턴스에서 마운트 진행

- 볼륨 연결 완성

 

4.2. 루트 볼륨의 확장

- 볼륨의 축소는 불가능하다.

- root 볼륨을 8 -> 10GB로 늘렸다.

 

- 용량은 확장되었지만 root 볼륨과 연결되어 있는 파티션의 크기는 여전히 8GB

- sudo growpart /dev/xvda 1

- root 볼륨과 연결되어 있는 xvda1의 용량을 늘려준다.

- 하지만, 마운트 된 /dev/xvda1의 용량은 여전히 8GB

- sudo xfs_growfs -d /

- 마운트되어 있는 /def/xvda1의 용량을 키워준다

- df -Th 명령어로 확인 가능

5. 스냅샷

- seoul-root 볼륨의 스냅샷을 생성한다

- 왼쪽 탭의 스냅샷 항목에서 스냅샷으로 만들어진 Seoul-root-volume을 확인

 

- 스냅샷에서 이미지 생성 버튼 클릭

- 스냅샷 자체를 이미지로 만들 수 없기 때문에 스냅샷을 이미지 인스턴스로 만듬

 

- 왼쪽 항목에서 AMI 항목 선택 후 이미지로 생성된 seoul-root-snapshot의 AMI를 복사한다

- 복사 리전을 도쿄로 설정해준다.

- 이런식의 리전을 달리해서 이미지 복사본을 옮기는 과정을 백업이라고 볼 수 있다.

- data transfer에서 비용 발생 ; Outbound에 대한 비용(스냅샷에 10GB의 용량이 존재하기 때문에)

 

- 도쿄 리전에서 복사된 서울의 snapshot ami를 확인할 수 있다.

- AMI는 스냅샷과 함께 존재한다

 

- 백업된 됴쿄 리전에 있는 AMI를 활용해서 인스턴스 생성

 

- 가용 영역을 습관적으로 분리

- Alibaba의 DNS 서버의 seoul 부분을 변경

- modify 버튼 클릭

 

- Record Value에 Ami로 생성한 instance의 주소를 넣어준다

- TTL(도메인이 생성되는데 걸리는 시간) 시간을 좁힐 수록 비용이 더 발생함

 

- AMI인스턴의 주소를 입력하면 Seoul 리전에서 생성했던 인스턴의 정보와 똑같이 나온다.

- 서울 리전의 인스턴스가 망가졌다고 가정하면 이런 식의 Snapshot 활용 법은 백업의 과정과 같다