DB를 로컬에 둔다면,
따라서 웹 서버를 EC2에 둔 것 처럼, DB도 외부에 두는 게 좋다
EC2에 DB를 설치해서 사용하는 방법도 있지만, 더 유연하게 DB를 사용할 수 있도록 RDS를 설정해서 사용해보자
RDS는 만약을 대비해서 서브넷 2개 요구
따라서 VPC의 서브넷에 배치를 하기 위해선 2개의 서브넷을 지정해줘야 한다
기존에 생성했던 서브넷이 있으므로 추가로 1개 더 생성
가용영역과 IPv4 CIDR을 다르게 설정해준다
🧐 가용영역과 IPv4 CIDR을 다르게 설정해주는 이유
[1] 고가용성을 보장하기 위해
: 서브넷을 다른 가용 영역에 배치함으로써 단일 가용 영역의 장애로부터 데이터베이스를 보호할 수 있음
(AWS에서는 보통 하나 이상의 가용 영역을 사용하여 서비스를 고가용성으로 운영하도록 권장)
[2] 네트워크 보안을 강화하기 위해
: 서로 다른 IPv4 CIDR을 사용함으로써 네트워크 보안을 강화할 수 있음. 서로 다른 CIDR을 사용하면 서브넷 간에 트래픽이 완전히 격리되므로 보안 측면에서 추가적인 장점을 얻을 수 있음
(VPC의 IPv4 CIDR : 10.0.0.0/16 로 설정)
🧐 하필 이 대역으로 설정해준 이유?
VPC : Virtual Private Cloud
AWS에서 가상 사설(개인) 네트워크 구성을 가능하게 해주는 네트워크 서비스
IPv4의 IP Address 체계에서 크게 2가지로 분류하면,
✔ Public(공인) IP Address
1. 인터넷에서 사용할 수 있는 공인 IP Address
2. 예를 들어 112.475.136.xxx 라는 IP Address 대역
✔ Private(사설) IP Address
1. 인터넷상에서는 사용할 수 없고 내부망에서만 사용할 수 있는 IP Address
2. 대표적인 3개의 IP Address 대역으로 10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/24 가 있음
3. AWS 에서는 10.0.0.0/16, 172.16.0.0/16, 192.168.0.0/24 등을 사용할 수 있음
4. 따라서 VPC 내부에서는 선언한 CIDR 10.0.0.0/16 의 Private IP Address 로 EC2 같은 리소스들에게 IP Address 를 할당
5. 인터넷 방향으로 통신을 하고자 하면 Public Subnet 은 Internet Gateway 를 통해서, Private Subnet 은 NAT Gateway 를 통해서 아웃바운드 통신하게 됨


새로 추가한 서브넷도 기존의 서브넷과 마찬가지로 외부와 연결이 된 라우팅 테이블에 연결해준다
(기존에 생성했던 라우팅 테이블에 연결. tomato_subnet1과 같은 라우팅 테이블에 연결된 것)
✔ 라우팅 테이블에 연결해줘야하는 이유
서브넷을 퍼블릭 서브넷으로 만들어주기 위해
DB 서브넷 생성하기 위한 사전 준비가 끝났다.
이제 새로 만들 DB를 원하는 VPC의 퍼블릭 서브넷에 배치하기 위한 DB 서브넷을 생성해보자

그 전에, VPC 에서 DNS 호스트 이름 활성화 체크 (오른쪽 사진 참고)
안하면 왼쪽 사진 처럼 생성 실패됨




Hostname = 생성한 DB의 엔드포인트
참고
| 4️⃣ ERD 설계 (0) | 2024.05.09 |
|---|