4/1 VPC (Virtual Private Cloud)

VPC란?

aws 리소스를 시작할 수 있는 가상의 독립된 네트워크망

왜 굳이 나누냐고 하면 캡슐화 때문 아닐까

 

VPC 만들기 단계

1. IP 주소 범위 선택
2. 가용 영역(AZ)별 서브넷 설정
3. 인터넷으로 향하는 경로(route) 만들기(routing table) 만들기
4. 방화벽으로 트래픽 통제

IP 주소 범위 선택

• 클래스
  • 기존에는 용도에 맞게 A, B, C 클래스로 나눠 썼으나
  • IP 주소 낭비가 심하고 확장성에도 문제가 있음
• 그래서 나온 게 CIDR
  • 172.31.0.0/16
    • 여기서 /16은 어느자리까지 고정된 건지 알려줌
    • 예시에서는 172.31.0.0 ~ 172.31.255.255 까지 자유롭게 내가 쓸 수 있음!

 

• Private IP
  • 로컬 네트워크 내(ex. 컴퓨터, 프린터, 폰)에서 통신하는데 사용되는 주소
  • 중복되어도 됨(어차피 안에서만 쓰고 public과 연결되지 않음)
  • -> 그래서 모든 iptime 설정 페이지가 192.168.0.1임

권장하는 private IP 주소

• Public IP
  • 외부와 통신하는데 쓰이는 주소이기 때문에 중복 X

권고하는 VPC 서브넷 설정이 있다

이때 subnet의 가능한 주소가 256이 아니라 251인 이유는,

• 0 -> 네트워크 주소
• 1~3 -> aws가 관리용으로 사용
• 255 -> broadcast 주소

 

 

예시

위 그림에서보면, VPC의 IP주소를 172.31.0.0/16으로 지정했다. 이 VPC안에서는 172.31. ~인 주소를 자유롭게 쓸 수 있다. 172.31.0.0/16

다음 자릿수에는 1개의 가용영역에 1개의 서브넷을 지정해준다. 서브넷은 /24로 172.31.의 다음 자리까지 고정된 주소를 가진다. 172.31.0.0/24

나머지 네번째 자리는 subnet안의 인스턴스에게 하나씩 할당된다.

 

인터넷 경로(Routing in VPC)

172.31.0.0/16으로 들어오는 주소는 로컬 네트워크 주소이므로 로컬 안에서 돌리고, 그 외의 주소는 인터넷 게이트웨이로 보낸다

 

VPC의 네트워크 보안

• Network ACLs
  • stateless 
    • statefull: 상태 유지, 들어올 때 허락했으면 나가기도 가능
    • stateless: 상태 잃음, 들어올 때 나갈 때 각각 허락 받아야 함
  • 서브넷 단위로 적용 가능
  • -> AWS 전문가용, 보통은 안 건드림
• Security Groups
  • 최소 권한 원칙(Principle of Least Privilege) 준수하기

• WebServer SG, Backends SG를 따로 만들어서
• WebServer SG에는 모든 웹 트래픽을 허용하고, Backends SG에는 MyWebServer에서 오는 트래픽만 허용하도록 할 수 있다

VPC의 연결

• (위에서 봤던) 인터넷 연결
• NAT gateway: 아웃바운드 전용 인터넷 허용
  • DB같이 인터넷 연결이 되어있지 않은 VPC 서브넷도 존재, 
  • 그렇지만 외부로 나가는 건 필요함
  • 예시
    • 상황 설명
      • 회사의 클라우드 환경에는 보안을 위해 외부 인터넷과 직접 연결되지 않는 네트워크 세그먼트에 데이터베이스(DB) 서버가 있습니다. 이 DB 서버는 운영체제나 DBMS의 정기적인 업데이트, 특정 소프트웨어의 다운로드가 필요할 수 있으나, 보안 정책상 인터넷에 직접 접속할 수 없는 상태입니다.
    • NAT Gateway의 역할
      • 인터넷 접근 제공: DB 서버가 인터넷에 접속해 업데이트나 필요한 소프트웨어를 다운로드하기 위해서는 NAT Gateway를 통해야 합니다. NAT Gateway는 내부 네트워크에서 오는 요청을 받아 공인 IP 주소를 사용하여 인터넷에 접속하고, 응답을 다시 내부 네트워크의 해당 서버로 전달합니다.
      • 보안 유지: NAT Gateway를 사용하면, 외부 인터넷에서는 DB 서버의 존재나 내부 IP 주소를 알 수 없습니다. 모든 인터넷 요청은 NAT Gateway가 중계하므로, 외부에서는 오직 NAT Gateway의 공인 IP 주소만이 보이게 됩니다. 이는 내부 네트워크의 보안을 강화하는 데 도움이 됩니다.
      • 네트워크 관리 용이성: NAT Gateway를 통해 네트워크 트래픽을 중앙 집중적으로 관리할 수 있으므로, 네트워크 구성이나 보안 정책을 효율적으로 관리할 수 있습니다.
• VPC Peering
  • VPC끼리 통신
• 회사 네트워크에 연결
  • 온프레미스 환경을 VPNor DX로 확장
  • VPN (Virtual Private Network): 가상의 네트워크 망
    • VPNd
  • DX(Direct Connect): 물리적인 선 연결

Amazon S3

VPC안에 있는 게 아니라, 서버가 아예 따로 있음

• 인터넷으로 연결하기 

• VPC의 endpoints를 만들어서 private하게 접속하게 하는 policy

 

* endpoints와 url의 차이

 

endpoints와 url의 차이

"Endpoints"와 "URL"은 종종 혼용되어 사용되지만, 웹 개발 및 API(애플리케이션 프로그래밍 인터페이스)에서는 각각 구체적인 의미를 가지고 있습니다.

Endpoints

• 정의: Endpoint는 API가 서비스를 제공하기 위해 통신하는 서버의 특정 위치를 의미합니다. 간단히 말해, API와 통신하기 위한 경로나 접점입니다.
• 용도: Endpoint는 특정 기능이나 자원에 접근하기 위한 목적지입니다. 예를 들어, 소셜 미디어 플랫폼의 API에서 사용자 정보를 요청하는 endpoint, 게시물을 업로드하는 endpoint 등이 있습니다.
• 특성: Endpoint는 일반적으로 URL을 포함하지만, URL 자체보다는 API 내에서의 특정 기능이나 자원에 대한 접근점을 의미하는 더 넓은 개념입니다.

URL (Uniform Resource Locator)

• 정의: URL은 인터넷 상의 자원이 위치한 주소입니다. 웹 브라우저 등에서 특정 웹페이지나 파일 등에 접근할 때 사용되는 고유한 주소입니다.
• 용도: URL은 인터넷 상의 어떤 자원의 정확한 위치를 가리키며, 웹 서버에 접근하여 해당 자원을 검색하거나 사용할 수 있게 해줍니다.
• 특성: URL은 프로토콜(예: http, https), 호스트 이름(도메인 이름), 파일 경로 및 이름, 때로는 추가적인 파라미터나 쿼리 스트링을 포함합니다.

차이점 요약

• 목적과 범위: Endpoint는 API와의 통신에서 특정 서비스나 자원에 접근하기 위한 접점을 의미하는 반면, URL은 인터넷 상의 어떤 자원의 구체적인 위치를 나타냅니다.
• 사용 문맥: Endpoint는 주로 API와의 상호작용에서 사용되며, URL은 웹 주소를 나타내는 데 널리 사용됩니다.
• 구성요소: 모든 endpoint는 URL을 포함할 수 있지만, 모든 URL이 endpoint는 아닙니다. Endpoint는 URL을 통해 접근되는 API의 특정 기능이나 자원을 의미합니다.

따라서, 개발자가 API를 설계하거나 웹 자원에 접근할 때 이 두 용어의 정확한 의미와 차이를 이해하는 것이 중요합니다.