AWS - 이론) Networking(네트워킹) 서비스

네트워킹 서비스

VPC

- 논리적으로 독룁된 가상의 네트워크

- 서로다른 VPC안의 EC2는 서로 통신이 불가능하다 논리적으로 독립된 네트워크 환경이기 때문이다

-> 별도의 설정이후에는 통신이 가능하다

VPC 범위 

/16 ~ /28 까지만 지정가능

VPC 기능

- IP 범위

- 라우팅

- 네트워크 게이트웨이

- 보안설정

VPC서브넷    

- 제공된 VPC대역을 논리적인 서브넷으로 나누어 사용 가능하게 해줌

1) 퍼블릿 서브넷

- 인터넷으로 접근가능한 리소스에 사용됨

- ex) 웹서버

2) 프라이빗 서브넷

- 인터넷으로 접근이 불가능하게할 리소스에 사용됨

- ex) database

- NAT를 이용하여 퍼블릭 인터넷 엑세스를 지원

- 퍼블릿 서브넷보다 프라이빗 서브넷에 더 많은 인스턴스가 할당 된다

웹어플리 케이션 인스턴스는 사용자가 접근하기 위해 퍼블릭 서브넷에 두어야 할것만 같지만

프라이빗 서브넷에 두고 ELB를 통해 사용자가 접근하도록 할 수도 있다. 

- 각 로드밸런서에 Public DNS이름이 제공되므로 웹어플리케이션을 프라이빗 서브넷에 배치 가능하다

VPC NAT GateWay 

- 프라이빗 서브넷이 외부와의 연결이 필요로 할때 사용

- 위의 그림을 보면 프라이빗 서브넷의 앱서버들이 웹서버들이 설치된 퍼블릿 서브넷을 이용하여 외부의 인터넷을 

  사용하기 위해 VPC NAT GateWay를 사용하는 것을 볼 수 있다.

VPC 보안 , 트래픽 제어

1) ACL

Default

- 모든 아웃바운드 및 인바운드 트래픽 거부

- Inbound Port를 열어주어야 Outbound Port가 허용이 된다

- 서브넷단위로 가상의 방화벽을 만들어 트래픽을 제어

- 기본적으로 모든 송수신을 허용

- 상태비저장이기 때문에 모든 인바운드 아웃바운드 트래픽을 추적한다

2) Security Group(보안그룹)

Default

- 모든 인바운드 트래픽 차단 , 모든 아웃바운드 트래픽 허용 

- 같은 SecurityGroup을 사용하는 Instance간 통신 허용

- 하나이상의 인스턴스에대한 인바운드 , 아웃바운드에대한 가상의 방화벽을 제공하는 것

- 기본적으로 인바운드는 모두 거부되어있고 아웃바운드는 모두 허용이 되어있다.

- 상태기반이기 때문에 인바운드 요청이 허용되는 경우 자동으로 아웃바운드가 허용된다.

- 인스턴스의 IP는 인스턴스를 재시작하면 IP가 바뀌게 되는데 이때 보안그룹의 이름으로 하여 접근이 가능하다

- 보안그룹을 티어별로 나누어 설정하면 보안이 강화되지만 그만큼 성능은 하향된다

3) 키 페어

- 

*AWS 보안 과정

1. 엣지로케이션의(물리적인프라) Shield, WAF에서 1차적으로 보안

2. ACL에서 (3계층) 2차적으로 보안

3. 보안그룹에서 (4-7계층) 3차적으로 보안

VPN 연결

1) AWS 하드웨어 VPN

2) AWS Direct Connect 

- VPN을 이용하여 연결하면 네트워크 대역을 사용하기 때문에 네트워크 성능이 낮아질 수 있다

  이때 직접 VPC와 자사의 데이터센터를 연결을 제공하는 서비스 이다

- 서울 리전에는 가산, 평촌

VPC 패턴

1. 규모가 작은 경우 사용 가능

     - 하나의 계정이 모든 VPC에 접근이 가능하기 때문에 보안에 취약할 수 있음

2. 계정 패턴

- 과금의 주체는 계정별로 나뉘어 있어 과금에 대한 취합이 필요하다 (AWS Organization 서비스를 이용하면 편하다)

AWS Organization

- 마스터 계정을 만들고 차일드 계정을 만들어 종속시킨뒤 

  하나의 마스터 계정에서 비용청구를 할 수 있다.

VPC 엔드 포인트

Amazon S3, DynamoDB는 VPC엔드 포인트를 제공하기 때문에 퍼블릭 인터넷을 통과하지 않고 직접 연결되도록 할 수 있다.

=> 네트워크 지연이 줄어들 수 있다.

VPC 인터넷 활성화 과정

1. 인터넷 게이트웨이 VPC에 연결

2. 서브넷의 라우팅 테이블이 인터넷 게이트웨이를 가리키게 한다

3. 서브넷의 인스턴스가 퍼블릿 IP주소 또는 EIP(탄력적 IP) 주소를 갖도록 한다

4. ACL 및 보안그룹에 관련 트래픽이 인스턴스에서 송수신 되도록 허용 해야한다.

Private Subnet VPC NAT설정

1) 퍼블릿 서브넷의 NAT로 설정된 EC2 인스턴스

- 비관리형 서비스로 설정을 모두 사용자가 직접한다

2) NAT 게이트웨이

- 포트포워딩이 불가능하다

- 관리형 서비스로 AWS에서 관리를 제공한다 따라서 사용자는 이용만 하면 된다.

VPC 로깅

- 특정 패킷에 대해 보안설정을 한 후 해당패킷이 잘 허용 또는 거부 되었는지 확인을 할 수 있다.

VPC 흐름 로그(VPC Flow Log)

1) 연결문제 해결

2) ACL 테스트 

3) 트래픽 모니터링 

4) 보안 인시던트 탐지 및 조사

VPC간의 연결

1) 고객 게이트웨이(CGW)

- 적절하지 못한 해결방법

- 퍼블릭 IP를 통해 

2) VPC 피어링(VPC Peering)

- 1:1 간의 설정만 가능 , 1:N, N:1 불가능

- 상호간의 동의가 필요

- 인터넷을 거치지 않고 직접적인 연결

- 자동확장을 통해 단일 장애점을 제거

- 전이 피어링이 되지 않으므로 직접 1:1 연결설정을 해야한다 아래 그림에서 A,B가 피어링 A,C가 피어링 되어있을 때

  B가 A를 통해 C에게 연결이 가능할 것 같지만 B,C간의 피어링을 따로 해주어야 통신이 가능하다

온프레미스 네트워크와 AWS를 연결

1) VPN 

- 인터넷을 이용하여 연결된다

2) Direct Connect

- 온프레미스와 AWS를 직접 연결한다

- AWS관리자에게 문의해야한다.

- 네트워크 전송비용 절감

- 성능 향상

- 보안

기본 VPC

1) Default VPC

- 각 리전에 존재하는 AWS에서 기본으로 제공하는 VPC

- CIDR 172.31.0.0/16

- 기본 서브넷, IGW, 라우팅테이블, 보안그룹, ACL 제공

2) Default Subnet

- 기본적으로 퍼블릿 서브넷 => IGW를 제거하거나 , IGW로  향하는 경로르 제거하면 프라이빗 서브넷으로 사용 가능

- CIDR 172.31.0.0/20

EIP    

- 고정 public ip 기능이다

- EC2의 Stop start 시 IP주소 또한 바뀌게 되어있는데 EIP를 사용하면 고정된 IP를 사용할 수 있다.

Route 53

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-weighted

- DNS 서비스

- 가중치 기반 라운드로빈 => 레코드 셋에 가중치빈도를 할당하여 설정해주어야 한다

- 상태 확인 및 DNS 장애 조치 => 주사이트에 장애 발생시 백업사이트(지금 장애가 발생함을 알리는 화면)으로 자동 장애조치

- 같은 도메인에 대하여 여러개의 별칭이 등록되어 있는경우 자동으로 요청자에게 가까운 곳으로 리디렉션 된다

Route 53 아키텍쳐

1) 레코드 셋 설정

- Elastic_Load_Balancer

라우팅 정책 = 장애조치

레코드 유형 = 기본

- Amazon S3 웹사이트

라우팅 정책 = 장애조치

레코드 유형 = 예비

=> 기본적으로 ELB로 트래픽을 보내다가 ELB에 문제가 생긴경우

      장애조치 사이트가 있는 S3로 리디렉션 시킨다