Cloud Network

국민대학교에서 "클라우드 컴퓨팅" 교과목을 진행하시는
이경용 교수님의 강의 교안을 이용하여 수업 내용을 정리하였습니다

 

 

 

AWS의 Region들

 

us-west-2, ap-southeast-1 처럼 되어 있는 것을 볼 수 있음

 

=> 보통은 숫자 1로 갈수록 큰 도시를 의미하며  주요 Region부터 기능이 배포됨

 

 

AWS에서 Region을 선택할 때 고려 사항들

 

• 법률적 제약 사항
  
  => 특정 데이터는 본국을 떠나서는 안됨 등의 제약 사항 고려
  
  
• 주요 사용자와 가까운 곳에 위치
  
  => 응답시간 측면에서 바라봐야함
  
  
• 지역별로 가용한 서비스가 다름
  
  => 주로 미국 서부(us-west-2) 및 동부 (us-east-1) Region 부터 새로운 서비스가 가능해짐
  
  
• Region 별로 가격이 다름
  
  => 데이터센터의 장비 가격등을 고려해보면 규모의 경제 특성상 가격이 다를 수 밖에 없음
  (한국은 비싼편..)

 

Amazon Virtual Private Cloud (VPC)

 

아마존 VPC는 가상의 private 네트워크를 구성할 수 있게해줌

 

• 하나의 VPC는 다른 VPC와는 논리적으로 분리된 네트워크 구성을 가짐
  
  
• 다양한 AWS 서비스들이 VPC에서 시작될 수 있음 (ex. EC2)
  
  
• 다양한 네트워크 자원을 설정할 수 있게 해줌
  
  
  • IP 주소 대역
  • 서브넷
  • 라우트 테이블
  • 네트워크 게이트웨이
  • 보안 설정 등

 

아마존 VPC 특성

 

AWS의 Region과 여러 AZ의 안정성을 활용할 수 있음

 

=> 각각의 Amazon VPC는 하나의 Region에 존재 해야 함
(Region에 매핑)

 

 

VPC 서브넷 (AZ에 매핑)

하나의 Region안에 여러 VPC가 있을 순 있음

 

 

• VPC를 여러개의 논리적 집합으로 나누어줌
• 하나의 AZ에 하나의 서브넷이 존재할 수 있으며, 여러 AZ에 하나의 VPC가 존재하게 해줌

 

IP 주소와 Classless Inter Domain Routing (CIDR)

 

 

IP 주소에서 점(.) 으로 구분되는 3자리 수는 8비트로 표현되며 0~255 값을 가짐
(2^8 = 256)

 

 

CIDR 표기법

 

CIDR 표기에서 /16은 첫 시작 비트부터 바뀌지 않는 자릿수를 표현함

(이 부분이 일치하면 같은 네트워크로 간주)

 

VPC 에서의 IP 대역

 

Amazon VPC는 /16 ~ /28 사이의 CIDR 폭을 가질 수 있음

 

 

 

=> CIDR 범위 값이 1씩 증가함에 따라서 사용 가능한 IP 갯수는 절반씩 줄어듬

 

Amazon VPC 세부 내용

 

각각의 VPC는 CIDR 기반의 IP 주소 대역을 할당 받아야 함

 

• VPC 생성 후 IP 대역은 변할 수 없음
  
  
• IP 대역은 /16 (65536개 주소 가능) 을 최대로 하고, /28을 최소로 설정할 수 있음 (16개 주소 가능)

 

Internet gateway (IGW)

• VPC에서 외부 인터넷을 접근 가능하게 해줌
  
  

라우트 테이블

• VPC 외부로 향하는 트래픽을 설정하게해줌

 

서브넷은 VPC 내부에서 세분화된 IP를 할당하게 해줌

 

• 하나의 서브넷은 하나의 AZ에 할당 되어야함
  
  
• Public 또는 Private 서브넷으로 생성 가능
  
  
• 퍼블릭 서브넷은 라우트테이블에서 IGW로 접근이 가능함

 

Amazon VPC 세부 내용

 

Elastic IP 주소

 

• IPv4 주소 풀에서 할당 받은 IP로 여러 인스턴스 간에서 교차로 활용하게 해줌
  
  (ELB를 통해 하나의 Elastic IP로 여러 인스턴스에 트래픽 분산해주는 것을 생각해볼 수 있음)
• EC2 인스턴스를 새롭게 생성할 경우 새로운 IP가 할당 되는데, 같은 IP를 활용하고자 할 경우 Elastic IP 활용 가능!

 

Amazon VPC 예제

 

하나의 AZ안에 여러 서브넷이 존재할 수 있음

 

 

VPC 에서의 IP 설정

 

VPC를 생성시에 사용하게될 IP 대역을 설정함 (충돌 안나게끔 설정해야함)

 

=> Classless Inter Domain Routing(CIDR)은 특정 대역의 IP를 설정하게 해줌

 

(10.0.0.0/16 => 10.0.0.0 ~ 10.0.255.255 까지의 대역을 표현)

 

Amazon VPC에서 서브넷이란

 

VPC로 구성된 네트워크에서 CIDR에 의해 구분된 세그먼트로 나누어 둔 것

 

ex. CIDR /22로 구성된 VPC 네트워크는 2^10 = 1024개의 IP주소를 가질 수 있음

 

서브넷 구성시 첫 4개 IP 주소와 마지막 1개 IP 주소는 AWS에 의해서 예약되어 있어서 사용할 수 없음

(10.0.0.0/24 의 경우)

 

• 10.0.0.0 : 네트워크 주소
  
  
• 10.0.0.1 : VPC 라우터
  
  
• 10.0.0.2 : DNS 서버 매핑
  
  
• 10.0.0.3 : future use
  
  
• 10.0.0.255 : broadcast 주소

 

(총 5개가 미리 예약되어져 있어서 사용 불가)

 

VPC의 퍼블릭 서브넷과 프라이빗 서브넷

 

퍼블릭 서브넷

• 서브넷의 네트워크 트래픽이 인터넷 게이트웨이를 통해서 라우팅 되는 서브넷
  
  
• 퍼블릭 인터넷으로 부터의 inbound/outbound 트래픽 모두 가능

프라이빗 서브넷

• 서브넷의 네트워크 트래픽이 인터넷 게이트웨이를 통해서 라우팅 되지 않음
  
  
• 퍼블릭 인터넷으로 부터의 inbound 트래픽이 허용되지 않음
  
  
• NAT 게이트웨이를 통해서 outbound 트래픽은 가능함

 

실제 EC2가 시작하는 곳은 VPC 안에 있는 서브넷임
(VPC 내부에 있는 서브넷 안에서 실행 => EC2가 직접 VPC에 배치)

 

 

서브넷 구성 추천

 

 

1개의 AZ 마다 퍼블릭/프라이빗 서브넷 1개씩

 

=> 프라이빗 서브넷에 더 많은 IP를 할당 하는 것이 좋음

(대부분의 서비스들이 퍼블릭 인터넷 접근을 필요로 하지 않는 경우가 많기 때문)

 

서브넷 구성

 

일반적으로 작은 갯수의 서브넷을 생성 후 각 서브넷에서 많은 IP를 활용하는게 좋음

(= 큰 private subnet을 만들자)

 

=> 이렇게 하면 여러 개의 private 서브넷을 관리할 필요가 없어서 배포 작업이 간편하고 서브넷 내에서의 IP 고갈을 막을 수 있음

 

응용 예제별 적절한 서브넷을 살펴보면

 

• 데이터 저장 인스턴스 : private
  
  
• 배치 프로세싱 : private
  
  
• 백엔드 어플리케이션 : private
  
  
• 웹 서버 : public 또는 로드 벨런서를 활용할 경우 private
  
  (외부에서 접근해야하는 페이지도 있으니)

 

VPC의 보안 - Internet Gateway

 

Internet Gateway는 퍼블릭 인터넷에서 VPC로의 접근을 가능하게 해줌 (양방향)

 

Fully managed 서비스이고 

 

서브넷의 라우트 테이블의 Internet Gateway 등록을 통해서 외부와의 통신을 가능하게함

 

• EC2 인스턴스의 경우 public IP가 할당 되어 있어야함 (기본적으로 할당)
  
  
• Elastic IP 활용 가능
  
  
• NACL과 Security Group에서 트래픽을 허용해야함

 

Default VPC

 

각 AWS 계정당 하나의 Region에 하나의 VPC가 기본적으로 생성되어 있음

 

Default VPC의 CIDR은 172.31.0.0/16
(한 Region에서 모두 같음)

 

=> AWS 에서 자원 생성 시 VPC를 별도로 지정하지 않으면 default VPC를 이용함

(Subnet, Internet Gateway, route table, NACL 등도 기본적으로 생성됨)

 

Default VPC 내의 Default 서브넷의 경우

 

• Default VPC 내의 각각 AZ 마다 하나씩 생성
  
  
• CIDR /20 의 퍼블릭 서브넷으로 생성

실제 서비스 응용에서 사용은 추천 X => 시험용으로만

 

 

VPC 간의 통신

 

라우트 테이블

• 네트워크 트래픽의 루트를 설정하게 해줌
  
  
• Main 테이블과 사용자 지정 테이블 생성 가능
  (기본적으로 VPC의 모든 서브넷은 Main 테이블을 사용하지만, 서브넷 별로 사용자 지정 테이블을 설정할 수 있음)

 

 

모든 라우트 테이블은 local 엔트리를 포함

 

=> 이게 있어서 VPC 내부 서브넷들은 통신이 가능함

 

특정 VPC간의 통신을 가능하게 하려면 라우트 테이블에 추가 가능

 

VPC 내 서브넷에 라우트 테이블을 생성하지 않을 경우 VPC의 라우트테이블을 활용함
(공유되는걸 활용)

 

=> 하나의 라우트 테이블을 여러 서브넷에서 활용 가능

 

VPC 내에서 보안 강화

 

Security Group

 

 

• 인스턴스당 inbound/outbound 트래픽의 방화벽 역할 담당
  
  
• 기본적으로 모든 inbound 트래픽을 허용하지 않음
  
  
• 기본적으로 모든 outbound 트래픽은 허용
  
  
• 주요 서비스 (SSH, HTTP 등) 별로 필요한 서비스를 별도로 허용
  
  
• Incoming 요청의 경우 CIDR로 표현된 특정 소스 기기로 부터의 접근 허용 가능

 

Tier를 고려한 Security Group 구성 예제

 

각 tier 에서는 필요한 최소한의 IP주소와 포트 번호만 허용해주는 것이 좋음

 

Web은 외부의 인스턴스들로부터 접근할 수는 있음

하지만, application은 Web만, DB는 application만 허용

 

VPC의 보안 강화 방안 -NACL

 

 

 

Network Access Control List (NACL)

 

• 각 서브넷 단에서 incoming, outgoing을 설정해주는 기능을 제공함
  
  
• 기본적으로 생성된 NACL은 모든 포트의 incoming과 outgoing 트래픽이 허용됨
  
  ( <-> SG는 나가는 것만 전부 허용이었음)
  
  
• CIDR 주소, 포트등을 기준으로 허용 가능

 

Security Group과 달리 Allow 와 Deny 모두 설정 가능

 

=> SG는 기본이 모두 Deny이고 Allow만 명시적으로 표시
(NACL은 기본 설정이 Allow니까 필요한건 Deny => IP Black Listing 가능)

 

여러 규칙이 있을 때 우선 순위를 명시해줘야함
(allow, deny가 섞여있으므로 명시해주고, 낮은 번호의 규칙이 높은 우선 순위임)

 

Stateless

 

stateless

 

• Inbound에 설정이 된 규칙이 outbound에 자동으로 설정되지는 않음
  
  
• Outbound로 나간 요청에 대한 inbound 응답이 무조건 허용되지 않음
  (SG는 stateful이라 알아서 허용)
  
  
• 80번 포트로 들어온 요청에 대한 응답은 ephemeral port(20000번 이후 포트) 번호를 허용해줘야함
  (임의로 할당되기 때문에 20000번 이상 포트를 다 열어놔야함)
  
  => 할당은 운영 체제의 TCP/IP 스택에서 관리된다고함

 

Amazon VPC Security Groups and NACL

 

 

 

 

Security Group 을 통해서 여러 인스턴스들에 대해서 접근 가능한 서비스를 설정할 수 있음 

 

=> EC2 서버의 방화벽

 

Network Access Control List (NACL)을 통해서 서브넷에 접근 가능한 서비스를 특정할 수 있음

 

=> 서브넷의 방화벽

 

 

VPC의 보안 - NAT를 통한 공개 인터넷 접근

 

 

Network Address Translation (NAT) 서비스 in Amazon VPC

(private IP <-> public IP 로 변환해주는데 이 때 포트도 변경됨)

 

• private subnet에 있는 서비스에서 퍼블릭 인터넷을 접근 하게 해줌 (outbound only 임)
• 퍼블릭 인터넷에서 incoming 트래픽은 접근 불가 (Internet Gateway의의 큰 차이점 - 양방향)

 

NAT Instance와 NAT Gateway의 2가지 옵션이 있음

 

NAT Instance 와 NAT Gateway

 

 

NAT Instance 와 NAT Gateway의 차이점

 

 

VPC, NAT Instance, Internet Gateway, Route Table

 

 

 

두개의 AZ, private subnet의 인스턴스는 NAT 인스턴스를 통해서 인터넷에 접근, NAT 인스턴스는 Internet Gateway로 라우팅

 

 

VPC EndPoint를 이용한 AWS 서비스 접근

 

Private subnet에 존재하는 EC2에서 퍼블릭 S3 엔드포인트를 통하여 S3 접근

 

• NAT Gateway/Instance 필요
  
  
• 공개 인터넷 망을 통해서 접근됨

 

Private 망에서 특정 AWS 서비스 만을 사용하게 된다면 EndPoint 사용

 

• EndPoint 생성 후 RouteTable에 해당 EndPoint 가 등록됨
  
  
• NAT Gateway 삭제 가능

 

과금 측면에서

EndPoint : $0.01/hour 
NAT Gateway : $0.059/hour

이므로 특정 서비스 밖에 사용 하지 않을거라면 EndPoint를  이용해 가격을 저렴하게 택할 수 있음

 

 

VPC FlowLogs

 

VPC 내부에서 주고받는 IP 트래픽의 정보를 저장하여 검색할 수 있게 해주는 기능

 

=> FlowLogs에서 발생하는 데이터는 Amazon CloudWatch (모니터링 공간) Logs에 저장됨

 

로그가 캡쳐되는 레벨

• VPC
• 서브넷
• Network Interface (VPC의 논리적 구성 요소이며 가상 네트워크 카드를 나타냄)
  
  => EC2 인스턴스가 네트워크에 액세스할 수 있도록 도와주며 EC2 인스턴스를 생성하면 기본 ENI가 eth0에 연결되어 네트워크 연결이 가능해짐

모든 IP 트래픽이 모니터링 되지는 않음

• DNS 접속 트래픽
• Window license activation
• 169.254.169.254를 통한 instance metadata
• DHCP traffic

 

올바른 VPC 사용을 위해서 유념할 내용들

 

1. CIDR 범위의 올바른 설정

 

2. 필요한 액세스 범위에 따른 서브넷 구성 (Public / Private)

 

3. 고가용성을 위해 VPC 내에서 Multi-AZ로 구성

 

4. Security Group의 설정을 통한 선택적인 접근 허용 ( + NACL)

 

5. VPC 내의 패킷 접근 히스토리를 확인하기 위해서 VPC FlowLogs 사용 가능

 

VPC 에서의 보안 강화 방법 요약

 

Security Group을 활용

 

=> Stateful 한 서비스이며 EC2 인스턴스를 보호

 

Network ACL을 활용하여 자원 보호

 

=> Stateless 서비스이며, 인스턴스 차원이 아닌 서브넷 차원에서 관리

 

서브넷, SG, NACL 등을 활용하여 layer로 나누어서 관리

=> 인스턴스 단이나 서브넷 단에서 관리하자

+ VPC FlowLogs를 통해 VPC의 네트워크 인터페이스를 통한 IP 트래픽의 모니터링

 

 

VPC 구조 개선

 

 

오른쪽 처럼 개선할 수 있음!

 

 

Azure Virtual Network (Vnet)

 

 

Azure Vnet은 AWS VPC에 대응되는 가상 네트워크 서비스임

 

Azure Network Interface (NIC)

 

Azure NIC란?

 

• VM과 Vnet을 연결하는 기능
  
  
• 각 VM에는 하나 이상의 NIC가 있어야함
  
  
• VM 크기에 따라 연결할 수 있는 NIC수가 달라짐
  
  

NIC 추가

• VM 수명 주기 동안 NIC를 추가하거나 삭제할 수 있음
  
  
• 여러 NIC를 사용하면 VM이 다른 서브넷에 접근 가능

 

Azure Vnet Subnet

 

서브넷 간에는 보안 경계가 없음, 이러한 각 버스넷은 통신할 수 있음

(외부 통신만 막음)

 

=> 서브넷 간 보안 경계가 필요한 경우 NSG (Network Security Group) 사용하여 제한

 

Azure Vnet 간 통신

 

Route Table (네트워크 패킷이 어떤 IP 대역으로 나갈 때 패킷을 어디로 보낼지 정보)

 

• Azure Route Table은 서브넷 및 온-프레미스 네트워크 간의 트래픽을 자동으로 라우팅
  
  
• Azure는 Vnet의 Route Table에 있는 경로를 따라 Vnet에서 아웃바운드 트래픽을 라우팅
  
  
• 기본경로와 사용자 지정 경로 설정 가능
  
  

Peering (서로 다른 VPC간의 네트워크 트래픽을 연결)

 

두 개 이상의 가상 네트워크를 원활하게 연결할 수 있음

 

=> Peering된 VM간 트래픽은 Microsoft 백본 인프라를 사용하기에 대기 시간이 짧은 고대역폭 연결이 가능

 

Azure Network Security Group (NSG)

 

Azure Vnet은 NSG를 제공하며 AWS SG 및 NACL에 대응함

(OSI 3, 4계층에서 작동)

 

네트워크 보안 기본 규칙은

 

• 아웃바운드 엑세스 허용
  
  
• 인바운드 엑세스 거부
  
  
• Vnet 내 엑세스 허용

 

NSG는 상태 저장을 하기에 들어오는 포트를 열면 트래픽을 허용하기 위해 나가는 포트가 자동으로 열림
(Stateful)

 

Azure NAT Gateway

 

AWS NAT Gateway와 대응되는 서비스임

 

=> Vnet에 대한 아웃바운드 인터넷 연결을 정의

 

Google Cloud VPC Network

 

 

GCP VPC는 AWS VPC에 대응되는 가상 네트워크 서비스임

 

=> AWS와 달리 여러 Region에 하나의 VPC 가능

(여러 Region에 걸쳐 있는 서비스에 대한 고가용성)

 

Google Cloud VPC Firewall Rules

 

 

AWS SG, NACL과 대응되는 서비스로 Stateful 함 (AWS의 SG와 대응)

 

=> 어떤 방향으로든 Firewall을 통해 연결이 허용되는 경우 이 연결과 일치하는 반환 트래픽도 허용

 

Network Tag을 사용하여 특정 VM에 Firewall Rule과 Route 적용 가능
(VM 또는 VM 템플릿과 같이 리소스 태그 필드에 추가되는 문자열임)

 

GCP Cloud NAT

 

Clud NAT은 AWS NAT에 대응하는 서비스임
(Private망에서 외부망을 쓸 수 있게 해줌)

 

=> Public IP주소가 없는 특정 리소스가 외부 인터넷에 대한 아웃 바운드 연결을 만들 수 있음

Cloud NAT는 VM의 네트워크 대역폭을 줄이지 않음

 

=> Cloud NAT 자체가 네트워크 성능에 병목을 일으키거나 영향을 주지 않기에 최대 성능을 보장하면서 NAT를 통한 외부 통신이 가능