초보자를 위한 AWS 네트워크

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2023-10-04
2023-10-04
1120

![AWS Network](https://docs.google.com/drawings/d/e/2PACX-1vTzi0CAaDdD_K4b6kTIJP07ri8fOn0bYgvzjkbBduFR0VHTaRKKwQYues5O9Oq5CI0TPi6S_j0CrjSA/pub?w=1164&h=475)
## AWS VPC
**AWS VPC(Virtual Private Cloud)** 는 AWS에서 제공하는 **가상 네트워크 서비스**다. 사용자는 VPC를 이용해서 자신만의 가상 서비스를 만들고 여기에 인터넷 서비스를 전개 할 수 있다. **소프트웨어 방식으로데이터센터를 만드는 서비스**라고 생각하자.

## AWS VPC의 구성요소 
### VPC
![VPC](https://docs.google.com/drawings/d/e/2PACX-1vTrfrhP_YlZ9Pr1Gu5mgheaa0Q2qhayScITDbHvlVORi6ELmMP_ejKRyO9l409-pKdKXxJ9nt5orbVb/pub?w=417&h=233)
VPC는 가상 네트워크로 하나의 커다란 네트워클 제공한다. 사용자가 생성할 수 있는 네트워크 블록은 아래와 같다.

| RFC 1918 range                | CIDR 예제      |
| ----------------------------- | -------------- |
| 10.0.0.0 ~ 10.255.255.255     | 10.0.0.0/16    |
| 172.16.0.0 ~ 172.31.255.255   | 172.31.0.0/16  |
| 192.168.0.0 ~ 192.168.255.255 | 192.168.0.0/20 |

### Subnet
사용자가 VPC를 만들면 커다른 네트워크가 생성된다. 예를 들어 10.0.0.0/16 네트워크는 약 65536(2^16) 개의 IP를 할당할 수 있는 네트워크다. 이 커다란 네트워크는 다시 **subnet** 이라는 더 작은 네트워크로 나눠서 사용한다. 커다란 빌딩을 하나의 구역이 아닌 여러 구역으로 나눠서 사용하는 것과 같은 이치이다.

![subnet](https://docs.google.com/drawings/d/e/2PACX-1vSgR5pzjOLQzNBY4_cHhJ3emKc-_pC7UOa512B6chggv385ZPetMP9mglwaIHauEXd_0EpXP5ImZTFl/pub?w=643&h=474)
사용자가 VPC를 만들면 **RFC 1918 range** 에 따라서 VPC 네트워크를 설정한다. 위 예제에서는 10.0.0.0/16 네트워크를 설정했다. 이것을 24 비트 네트워크로 나서 사용하고 있다. 10.0.0.0/24 와 10.0.1.0/24는 WAS(Web Application Server)를 위한 subnet, 10.0.2.0/24, 10.0.3.0/24 는 MySQL 데이터베이스를 위한 subnet으로 설계를 했다.

/24 크기로 subnet 크기를 설정했으므로 10.0.0.0/24 ~ 10.0.255.0/24 까지 256 개의 subnet을 사용 할 수 있을 것이다. 그리고 각 subnet은 255개의 IP 주소를 사용 할 수 있다.

| Subnet    | CIDR        | Range                 |
| --------- | ----------- | --------------------- |
| subnet-01 | 10.0.0.0/24 | 10.0.0.0 ~ 10.0.0.255 |
| subnet-02 | 10.0.1.0/24 | 10.0.1.0 ~ 10.0.1.255 |
| subnet-03 | 10.0.2.0/24 | 10.0.2.0 ~ 10.0.2.255 |
| subnet-04 | 10.0.3.0/24 | 10.0.3.0 ~ 10.0.3.255 |

### Availability Zone
**Availability zone(이하 AZ)** 는 AWS 리전을 구성하는 **데이터 센터**다.

![Availability Zone](https://docs.google.com/drawings/d/e/2PACX-1vSL-euuJhE7baFy-WdKbbMXNyEW5EdyXEPitQhOP3v38xDldjpinQxOzRNn230G1qtaq7kH4uivpbkD/pub?w=812&h=602)
각 Region은 2개 이상의 AZ로 구성된다. 예를 들어서 서울 리전은 4개의 AZ로 구성된다. **하나의 Subnet은 하나의 AZ에 전개** 할 수 있다. 이렇게 구성하면 하나의 AZ에 문제가 생기더라도 다른 AZ를 이용할 수 있기 때문에 애플리케이션 가용성을 높일 수 있다.

![Availability Zone](https://docs.google.com/drawings/d/e/2PACX-1vQCsIRbR0jtbLTEyApwgdaTrvRiWhW1u9I4h06RtuBodSWUadN8xJWKMeX3cjuMUjnoNngBiqklsbh0/pub?w=640&h=574)

위 그림은 Seoul Region에서의 VPC, Availability Zone의 관계를 보여준다.
1. Seoul은 4개의 가용영역(ap-northeast-2a ~ ap-northeast-2d)으로 구성된다.
2. 사용자는 VPC를 2개 이상의 가용 영역으로 구성할 수 있다.
3. 각 가용영역에서 subnet을 배치한다.

### Internet Gateway
AWS VPC는 사설 네트워크(Private network)를 사용하기 때문에, 인터넷에서는 접근 할 수가 없다. 인터넷에 접근하기 위해서는 사설 네트워크과 인터넷을 연결하는 **Internet Gateway**라고 하는 관문이 필요하다.

![Internet Gateway](https://docs.google.com/drawings/d/e/2PACX-1vRqQQ4E21M1GLOIdvL4oWEoIuMgx5fqRAL38MPmwP5ZM6YG2uUDn27hyI6RFQ_AeRYqMuUm1nlxGkIb/pub?w=848&h=602)

VPC 안에 있는 EC2 Instance(인스턴스-가상서버)는 Private IP를 가진다. EC2 Instance에 접근하기 위해서는 Public IP가 할당이 되어야 하는데, Internet Gateway에 Public IP가 할당이 된다. 예를 들어 EC2 Instance에 10.1.0.220 이 할당되고 1.2.3.4를 EC2 Instance에 할당했다면 아래와 같이 인터넷에서 접근할 수 있게 된다.

![Internet gateway를 이용한 접근](https://docs.google.com/drawings/d/e/2PACX-1vRB2oQtEcuAN5NCq0zByeJvp_3DUWejw9vinliT2Ngr_jjhoKZxLRhNtY1ywCVxB9zn-1DC_se46SCB/pub?w=759&h=288)

### Public Subnet and Private subnet
Subnet은 **Private subnet**과 **Public subnset** 타입이 있다. 
* Private subnet: 말 그대로 인터넷에서 접근할 수 있는 Private한 네트워크다.
* Public subnet: 인터넷에서 접근할 수 있는 네트워크다. 사용자는 Private subnet에 직접 접근 할 수 없으며 Public subnet을 경유해서 접근해야 한다.
![Private Subnet and Public subnet](https://docs.google.com/drawings/d/e/2PACX-1vQqE9MXzo9yoQlheFlGRij-qbtnQ5zWEAQYFmwsab6ekaHoiTPEJ2eEiRjfMj6byG56p7c-Tzf4pCs6/pub?w=926&h=703)

이렇게 subnet을 Private와 Public으로 나누는 이유는 "보안성을 높이기 위함"이다. WAS나 데이터베이스를 Private subnet에 두면, 사용자가 직접 접근 할 수 없기 때문에 보안성을 높일 수 있다. 그리고 Public subnet에는 **로드밸런서**를 두거나 혹은 보안 솔류션을 두는 식으로 인터넷 사용자가 이들 시스템을 경유하게 함으로써, Private subnet을 보호할 수 있다.

Public subnet과 Private subnet의 유일한 차이점은 "Internet Gateway의 트래픽 경로가 있는지" 이다. Internet Gateway와의 트래픽 경로가 설정되어 있다면 Public subnet 그렇지 않다면 Private subnet이다. 이러한 트래픽 경로는 **Routing table**로 설정할 수 있다.

### Routing Table
VPC는 여러 네트워크가 참여하는 것을 알 수 있다.
1. 인터넷: 공용 네트워크로 인터넷을 통해서 VPC에서 제공하는 서비스를 사용하거나, VPC에 있는 가상서버 등에 접속할 수 있다.
2. Public Subnet: 로드밸런서나 배스천서버(bastion server), VPN 서버, 보안 서버 등이 위치하는 subnet, NAT(Network Address Translation)
3. Private Subnet: WAS와 같은 애플리케이션이 설치된 EC2 가상서버나 데이터베이스 등이 위치하는 subnet 
또한 Internet gateway, NAT, VPN 등 각 네트워크 구간을 연결하기 위한 다양한 서버들이 있다. 이들 간에 트래픽 경로를 설정해야 하는데 **Routing Table**을 이용해서 트래픽 경로를 설정할 수 있다.

![Routing table](https://docs.google.com/drawings/d/e/2PACX-1vTJPSNjuN9K5mnOmvM4usZ3K9VvySIDTEos9OE3OITloRGh6xeR-W3ecDZHlH2e-v3jrpueOvRo3UoE/pub?w=1031&h=567)

위 그림은 2개의 routing table을 보여주고 있다. 첫번째 라우팅 테이블은 0.0.0.0/0 -> IGW(Internet Gateway)규칙을 가지고 있다. VPC 내부로(10.0.0.0/16) 향하는 트래픽을 제외한 모든 트래픽은 Internet Gateway로 향하게 설정했다. 따라서 이 Subnet-01, Subnet-02에 있는 서버들은 인터넷과 통신이 가능하다. 이 두 개의 subnet은 **Public Subnet**이다.

반면 subnet-03, subnet-04는 IGW로의 룰이 없기 때문에 인터넷과 통신할 수 없다. 이 두 개의 subnet은 Private Subnet 이다.

### Public IP
EC2 인스턴스를 비롯한 AWS 리소스들은 인터넷에서 접근하기위한 Public IP를 가진다. 이 Public IP는 AWS의 IP Pool에서 관리를 한다. 예를 들어 사용자는 EC2 인스턴스를 실행할 때, EC2에 Public IP를 할당할지를 결정할 수 있다.

AWS에서 관리하기 때문에 여러 이유로 IP가 바뀔 수 있다.
### EIP
EIP(Elastic IP)는 인터넷에서 접근가능한 IP 주소를 사용자에게 제공하는 서비스다. 위의 Public IP와 다른 점은 아래와 같다.
* **Public IP**는 AWS에서 관리를 한다.
* **EIP**는 사용자가 관리한다.

또한 아래와 같은 특징을 가진다.
* Public IP의 경우 IP 주소를 고정할 수 없다. 사용자가 EC2 인스턴스를 실행할 때 Public IP를 할당 받아서 사용하는 중에, EC2 인스턴스가 Stop/Start 로 새로 실행되면, Public IP가 변경된다. 
* EIP는 사용자가 AWS에 요청하여 할당 받아서 사용하며, 사용자가 EIP 사용을 해제(release)하지 않는 한 해당 IP 주소를 계속 사용 할 수 있다.

따라서 고정된 IP가 필요할 경우에는 EIP를 요청/할당 받아서 사용해야 한다.

### Security Group & NACL
**Security Group**은 VPC에서 제공하는 방화벽 서비스로, 허용한 트래픽외에 다른 트래픽들을 막아서 네트워크 보안성을 높일 수 있다.

**Security Group**
아래 그림은 Security group을 설명하고 있다.
![Security Group](https://docs.google.com/drawings/d/e/2PACX-1vRWuUAZoaZtCSaONqsqulICYdmjWSIhVWTddt1YsGddor3uFK5huK0p7WnozRf365p2JC2YGCGvqEzs/pub?w=1146&h=538)
기본정책은 **ALL DENY** 이고 사용자가 **허용(ALLOW)** 한 트래픽만 허용하는 **White List** 기반으로 정책을 적용한다.

위의 그림을 보자 EC2의 경우에는 HTTP와 SSH 트래픽을 허용하고 있다. 이 외에 모든 트래픽은 막힌다. 또한 SSH의 경우 출발지 IP가 1.2.3.4와 일치해야지만 허용하고 있다.

MySQL 서버의 경우 3306 포트에 대해서, 출발지가 VPC 내부인 트래픽만 허용하고 있다.

**NACL**
Security group은 기본적으로 호스트레벨에서 작동하는 방화벽이다. **NACL(Network ACLs)** 은 Subnet 단위에서 트래픽을 제어하기 위한 기능이다.

![AWS NLB](https://docs.google.com/drawings/d/e/2PACX-1vRyzXvwPy72VFJiROiJVKOMNDFRKbBor0v_MYyB_u0iEmSgEF1kscfxoRaHpSNjT3fpgNcGN2W5DWLq/pub?w=731&h=353)
NACL을 이용하면 subnet 단위로 인바운드 및 아웃바운드 IPv4(혹은 IPv6) 트래픽을 허용 할지를 결정할 수 있다. 기본적으로 인바운드와 아웃바운드는 **ALL ALLOW** 정책이 적용된다. 사용자는 특정 트래픽을 허용하거나 거부할 수 있다.

아래는 IPv4를 지원하는 VPC에 대한 기본 네트워크의 **인바운드** ACL 예제다.

| 규칙 # | Type | 프로토콜 | 포트범위 | 소스      | 허용 / 거부 |
| ------ | ---- | -------- | -------- | --------- | ----------- |
| 100    | IPv4 | 모두     | 모두     | 0.0.0.0/0 | 허용        |
| *      | IPv4 | 모두     | 모두     | 0.0.0.0/0 | DENY        |

NACL 규칙은 위에서 부터 차례대로 적용된다. 위의 예제에서 규칙 100은 모든 트래픽을 허용하기 때문에 이 규칙이 우선적으로 적용된다. 만약 규칙 100을 지운다면 DENY 정책이 적용되어서 모든 트래픽이 거부된다.

**Security group과 NACL 의 차이**

| NACL                                                                             | Security group                                                                               |
| -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Subnet 단위로 적용된다.                                                          | 인스턴스에 명시적으로 할당된다. 서브넷에 할당되지 않는다.                                    |
| NACL은 서브넷을 보호하는 방화벽으로 이해할 수 있다.                              | Security group은 인스턴스를 보호하기 위한 방화벽으로 이해할 수 있다.                         |
| 상태 비저장이다. 즉 Inbound에 적용된 규칙은 Outbound에 자동으로 적용되지 않는다. | 상태 저장 정책이다. 즉 Inbound 규칙에 적용되는 변경사항은 Outbount 규칙에 자동으로 적용된다. |
| NACL은 우선순위에 따라 규칙이 적용된다.                                          | Security group는 모든 규칙이 인스턴스에 적용된다.                                            |

**상태 비저장**(stateless)와 **상태 저장(stateful)** 에 대한 이해를 돕기 위해서 간단한 예를 들었다.
* 상태저장 : 웹서버가 80 번 포트에 대한 0.0.0.0/0 허용 정책이 있다고 가정해보자. IP가 100.100.100.5인 Client가 웹 브라우저를 이용해서 35438 포트로 웹 서버의 80번 포트로 연결했다고 가정해 보자. 그러면 Security group은 100.100.100.5:35438 로 향하는 outbound 트래픽을 자동으로 허용 한다. 트래픽을 추적해서 "상태를 알고 있기 때문에" 가능하다.
* 상태비저장: Inbound와 outbound 가 독립적으로 작동한다. 예를 들어서 Inbound 80번을 허용했다면, 응답 트래픽도 따로 허용을 해줘야 한다. 일반적으로 80번을 사용하는 웹 브라우저의 경우 49152~66535 범위의 포트를 사용하기 때문에, 해당 범위의 outbound 포트를 허용해줘야 한다. 실제 NACL 설정을 Security Group 처럼 하다가 통신이 안되는 경우도 종종 발생한다.

## VPC Peering & Transit Gateway
VPC Peering 와 Transit Gateway는 AWS VPC를 연결하기 위해서 사용한다. 예를 들어서 Security-VPC, Data-VPC, Service-VPC 를 만들었는데, 이들을 각각 연결해야 할 경우 VPC Peering 혹은 Transit Gateway를 이용해서 VPC를 연결해야 한다.

#### VPC Peering
![Peering](https://docs.google.com/drawings/d/e/2PACX-1vT3l7rqKwvhgWid67uxFW51ILyc26SeOJtmlJUSde62ex1Yfq6zDkQwowtBEqNXXzLJLSjU3VsdUnqj/pub?w=725&h=430)
VPC Peering을 사용하면 Public Network(인터넷)을 경유하지 않고, 다른 VPC와 연결할 수 있다. 이를 통해서 보안을 강화할 수 있으며, 데이터가 인터넷에 노출될 위험을 줄일 수 있다.

VPC Peering은 "Transitive Peering(전이적 피어링)"을 지원하지 않는다.
![전이적 Peering](https://docs.aws.amazon.com/ko_kr/vpc/latest/peering/images/transitive-peering-diagram.png)
VPC A, B, C가 있고 B와 A, A와 C가 각각 VPC Peering으로 연결되어 있다고 가정해보자. VPC B에서 VPC A를 거쳐서 VPC와 통신 할 수 없다. VPC B와 VPC C간 VPC Peering 설정을 해야 통신 할 수 있다.

![VPC Peering](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdYZHL7%2FbtrIGzzh2k8%2FVKEWjaSPFrB8AC99fSXSy1%2Fimg.png)

따라서 연결할 VPC가 늘어나면 VPC Peering 설정이 매우 복잡해 질 수 있다. 몇 개 VPC만을 선별적으로 연결할 때 주로 사용한다.

VPC Peering에 대한 자세한 문서는 [AWS VPC Peering](https://www.joinc.co.kr/w/man/12/aws/peering)문서를 참고하자.

#### Transit Gateway
VPC Peering 과 마찬가지로 VPC를 연결하는 일을 한다. VPC Peering 과의 가장 큰 차이는 **Hub and Spoke Architecture**를 가지고 있다는 점이다.

![Transit Gateway](https://docs.google.com/drawings/d/e/2PACX-1vQgPilRpFuK9idJPuFQffKbpH4GTnRM2WKdIBcnFeEQZCb2w_4EydgTl5UtYJB5SmmhGoVinkJQA5sC/pub?w=880&h=436)

이 아키텍처에서는 VPC가 서로 직접 연결하는 대신에 Transit Gateway만 연결하면 되기 때문에, 네트워크 연결을 효과적으로 관리할 수 있다. 또한 전이적 라우팅을 지원한다. 즉 A <-> B <-> C VPC가 서로 연결되어 있다면, A는 B를 경유해서 C와 통신할 수 있다.

네트워크를 효율적으로 관리할 수 있지만 추가적인 비용이 들기 때문에 네트워크 복잡도를 고려해서 사용여부를 결정해야 한다.

## Bastion Server
VPC는 Public subnet과 Private subnet으로 구성된다. 서버나 데이터베이스 등은 Private subnet에 배치하기 때문에 외부에서 직접적으로 접근 할 수 없다. 하지만 개발자나 관리자가 서버나 데이터베이스에 접근해야 할 경우도 있다. 이 경우에 사용할 수 있는 방법 중 하나가 **Bastion Server**를 이용하는 것이다.

Bastion Server를 Public subnet에 두고, 개발자가 Bastion server을 **경유**해서 Private subnet에 있는 서버와 데이터베이스에 접근하는 방식이다. 구성은 간단하지만, 사용자는 두 번 로그인 과정을 거쳐야 해서 운영이 번거로운 단점이 있다.

![Bastion Server](https://docs.google.com/drawings/d/e/2PACX-1vT5sV8NgYLZNQxmLyqb-zcyuO29dW13zHWll48p-IUjD0-vtVGMMxOR7_q_YvPtpfJx4TUw505XP9jU/pub?w=572&h=538)

## NAT Gateway
Server 는 Private subnet에 설치되기 때문에 인터넷에서 직접 접근 할 수 없으며 반대로, 인터넷으로 나갈 수도 없다. 하지만 API 호출 등을 위해서 인터넷에 접속해야 하는 경우가 있다. 이때는 NAT Gateway를 사용하면 된다.  
![NAT Gateway](https://docs.google.com/drawings/d/e/2PACX-1vRM6QniNi6V7WnzxASdl4utfqwn5hlKs9-VuU9uJjN34ayoSsyF1FqNkRqjtf1MVvvuneuvcDAxOI63/pub?w=861&h=506)

Public subnet에 NAT Gateway를 배치하고, Private Subnet의 Routing table을 변경하면 된다. 이터넷으로 향하는 트래픽(0.0.0.0/0)을 NAT Gateway로 향하도록 설정하면 된다.

## VPN
![VPN](https://docs.google.com/drawings/d/e/2PACX-1vTqST9SFP82dX0pSnzupON7NDR1ayCnYIWGvyOy9fk4QlRW-hkHLmHlbxj0paoFul8vwzayXgYdW_1p/pub?w=1184&h=504)
AWS VPN 솔류션은 온프레미스 네트워크, 원격 사무실, AWS 글로벌 네트워크 사이에 보안 연결을 만들어주는 네트워크 서비스다. 크게 Site-to-Site VPN과 Site-to-Host VPN이 있다.

**Site-to-Site VPN** 의 경우 온프레미스 장비와 VPC 간에 보안 연결을 만든다. 네트워크와 와 네트워크를 하나로 묶는 개념으로 위의 그림은 Site-To-Site VPN을 묘사하고 있다. 위 그림을 보면 10.0.0.0/16(AWS VPC) 네트워크와 192.168.0.0/16(온프레미스) 네트워크를 묶은 걸 확인 할 수 있다. 이 두 개 네트워크 통신은 인터넷 구간을 경유하게 되는데, 안전한 통신을 위해서 IPSec 프로토콜을 이용해서 암호화 통신 구간을 만든다.

이렇게 VPN으로 두 개 네트워크가 연결되면, 통합된 네트워크 처럼 자유롭게 데이터 통신이 가능하다.

## 정리
여기에서는 AWS VPC의 주요 구성 요소들을 간단히 살펴봤다.
1. VPC
2. Subnet
	1. Public Subnet
	2. Private Subnet
3. Availability Zone
4. Internet Gateway
5. Routing Table
6. Public IP & EIP
7. Security Group & NACL
8. VPC Peering & Transit Gateway
9. Bastion Server
10. NAT Gateway
11. VPN
위의 내용들을 모두 이해한다면, 자신만의(혹은 회사의) AWS VPC 네트워크를 구축할 수 있다. 여기에서는 전체 구성 요소들을 개략적으로 살펴봤는데, 다음 문서들을 통해서 각 구성 요소들을 자세히 살펴보게 될 것이다.

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories