AWS 네트워킹 서비스는 크게 5가지로 이루어져 있습니다.
| 명칭 | 설명 |
|---|---|
| VPC | AWS 클라우드에 만드는 가상의 데이터센터 |
| VPN | On-prem 데이터센터와 VPC의 IPsec VPN 연결 |
| Direct Connect | On-prem 데이터센터와 VPC의 전용선 연결 |
| ELB | 관리형 Load Balancer 서비스 |
| Route 53 | 관리형 DNS 서비스 |
VPC는 내용이 많기 때문에 이번 포스팅에서 다루고, 나머지는 다음 포스팅에서 다루겠습니다.
하나씩 차례대로 살펴보겠습니다.
1. VPC (Virtual Private Cloud)
- 사용자가 정의한 가상의 네트워크 환경 (논리적 격리)
- 사용자 별 네트워크 제어 가능
-- IP 범위 지정
-- 용도에 맞는 subnet 분리
-- Routing tables
-- 보안 : Security group, Network ACL
-- Gateway : Internet Gateway, NAT Gateway, Virtual Gateway - On-premise 데이터센터와 연결옵션 (VPN, Direct Connect)
VPC 만들기
Region, IP 대역 결정
-> 가용 영역(AZ)에 subnet 생성
-> subnet 목적에 맞게 Routing table 연결
-> Traffic 통제 (In/Out)
1. Region, 가용 영역, VPC 이해
Region : aws 데이터센터가 있는 큰 지역의 거점
AZ : 가용 영역을 위해 리전 당 두개 이상의 AZ가 있음
가용 영역은 한개 이상의 데이터센터들이 클러스터로 구성되어 있고 각 데이터 센터 간에는 초고속 네트워크로 연결되어 있습니다.
2. CIDR (Classless Inter-Domain Routing)
VPC를 만들때는 가장 먼저 ip range를 설정해야합니다. ip 주소 range를 결정할 때는 CIDR 할당 방법을 사용합니다. 기존에 사용하던 네트워크 클래스 대신 ip 주소를 보다 효율적으로 사용하기 위해서 입니다.
16비트의 CIDR를 사용한다면 16비트가 네트워크ID로 고정되고 나머지 16비트를 호스트 ID로 사용할 수 있습니다. 즉, 65K개의 ip 주소를 사용할 수 있습니다.
IP Range 결정 시 고려사항
- VPC 확장 시나리오 고려
-- 서비스 확장을 고려하여 충분히 큰 CIDR 지정
-- 향후 AWS내 동일 리전, 다른 리전의 VPC 확장
-- 향후 고객사 On-premise Network 과의 연동 - VPC 네트워크 범위는 /16~/28 까지 가능
- VPC Primary CIDR은 생성 후 변경 불가
-- Secondary CIDR은 4개까지 추가가능 - RFC 1918 (Private IP 표준) 권장
3. VPC 구성 이후 가용 영역에 subnet 생성
VPC ip range내에서 subnet 주소를 할당하면 됩니다.
subnet ip range
위의 장표와 같이 subnet을 24비트로 구성하시면, 16비트는 네트워크id, 8비트를 서브넷id, 마지막 8비트를 호스트id로 사용하여 총 256개의 ip를 사용할 수 있습니다.
subnet 생성 시 고려사항
- subnet 네트워크 범위는 마찬가지로 /16~/28 까지 가능
- subnet CIDR이 10.0.0.0/24인 경우 251개의 ip주소 사용 가능 (10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.255는 미리 예약된 ip 주소이기 때문)
- subnet CIDR는 생성 후 변경할 수 없음
- Application의 고가용성을 위해 복수개의 가용 영역에 subnet 생성 (Multi-AZ 아키텍처)
subnet 구성 예시
- 한 개의 가용영역에 두 서브넷을 만드는 경우
- 가용영역에 분리해서 구성하는 경우
- 2-tier 아키텍처를 구성하는 경우 - 가용성을 염두하여 각 가용영역에 Public, Private을 구성하는 경우
- 3-tier 웹 어플리케이션을 구성하는 경우 - 세 개의 서브넷을 각 가용 영역에 구성하는 경우
4. Routing
다음은 라우팅입니다. 동일 네트워크 안에서는 일반적으로 통신이 가능합니다. 하지만 다른 네트워크와의 통신은 라우팅을 설정하지 않는 한 불가능합니다.
VPC를 만드시면 각 서브넷에 있는 리소스가 통신이 가능하도록 Main route table에 VPC 네트워크 대역이 자동으로 설정되어있습니다.
VPC 내에 있는 모든 서브넷이 암시적으로 적용되게 되며, 하나의 VPC 내에 많은 서브넷을 만드신다 해도 VPC 내에 있는 모든 리소스들은 암시적으로 통신이 가능합니다.
Custom route table
main route table외에 custom route table을 정의할 수 있습니다. vpc 외부 리소스 (인터넷, 온프렘데이터센터) 와의 통신을 위해 routing rule을 추가할 수 있습니다.
custom route table은 할당을 원하는 서브넷에 명시적으로 연결을 하셔야 합니다.
5. 네트워크 트래픽 통제
네트워크 트래픽 통제방법에는 크게 세가지가 있습니다.
5.1) Route table
-Subnet 단위 라우팅 통제
5.2) Network ACL
-Subnet 단위
-Stateless 방화벽
-Inbound & Outbound에 모두 명시적 허용
-Rule # ordering
5.3) Security Group
-인스턴스 단위
-Stateful 방화벽
-Inbound or Outbound에 하나만 허용
앞서 알아본 Route table을 제외하고 하나씩 살펴보겠습니다.
네트워크 트래픽 통제 : Security Group
허용된 룰은 명시적으로 등록하여야합니다. 예를 들어, MyWebServer의 security group은 http와 https와 같은 web traffic을 모두 allow하도록 설정한 다음에, MyBackends는 MyWebServer에서 들어오는 traffic만 allow하도록 설정이 가능합니다.
네트워크 트래픽 통제 : Network ACL
Network ACL은 초기에는 모두 허용으로 설정되어 있습니다. 트래픽제어를 위해 Inbound, Outbound에 대해 명시적으로 정의하셔야 합니다.
VPC 확장 시나리오
운영하는 VPC에서 인터넷을 연결한다던지, 온프렘데이터센터와 연결한다던지, 운영하는 다른 VPC로 연결하는 경우를 생각해볼 수 있습니다.
첫번째로, 인터넷 확장에 대해서 살펴보겠습니다.
1.1 VPC 확장 시나리오 : Internet -> Internet gateway
vpc에 internet gateway를 연결하고 routing table을 포함시키게 되면 외부와 통신할 수 있게 됩니다.
internet gateway와 연결되는 서브넷은 퍼블릭 서브넷이 되어야합니다. vpc와 연결가능한 internet gateway는 1개이고, internet gateway는 managed service로서 확장성, 가용성, 중복성을 보장하도록 설계 되었으며 ipv4와 ipv6모두 지원합니다.
1.2 VPC 확장 시나리오 : Internet -> NAT gateway
internet gateway와 마찬가지로 NAT gateway도 managed service입니다. 인터넷이 불가능한 private subnet에 있는 인스턴스들이 패치나 업데이트, 다운로드가 필요할 때 NAT gateway를 사용할 수 있습니다.
Internet facing을 위해 NAT gateway당 하나의 Elastic ip가 필요합니다. 트래픽 통제는 Network ACL을 통해 가능합니다. VPC flow logs를 통해 traffic monitoring이 가능하고, cloudtrail을 통해 세부적인 로그 수집이 가능합니다.
1.3 VPC 확장 시나리오 : Internet -> Elastic IP
Elastic IP를 통해서 Public subnet에 있는 인스턴스들에게 고정 public ip를 할당할 수 있습니다.
ec2장애 발생 시에 다른 ec2 인스턴스로 연결이 가능하고, region당 기본 5개의 Elastic IP가 할당이 가능합니다. 하지만 이는 soft limit으로 열려있는 부분이라 case open을 하여 확장할 수 있습니다.
2.1 VPC 확장 시나리오 : On-premise -> VPN
온프렘데이터센터와 VPC를 연결하는 방법은 VPN과 Direct Connect가 있습니다.
첫번째로 VPN Gateway를 사용하시면, IPsec network protocol 기반의 vpn을 연결할 수 있습니다. vpn 터널은 기본적으로 이중화되어있고, tx통신하기 때문에 안전하게 통신이 가능합니다.
2.2 VPC 확장 시나리오 : On-premise -> AWS Direct Connect
전용회선을 연결하는 방법으로 aws와 직접 연결하는 방법이 아니라, DX location을 통해 aws와 연결하는 방식입니다. 국내에는 가산에 KINX, 평촌에 LG U+가 있습니다.
DX location과 aws는 이미 연결이 되어있기 때문에 DX location까지만 전용회선을 구성하시면 됩니다.
3. VPC 확장 시나리오 : 다른 VPC -> VPC Peering
VPC간의 연결을 지원해주는 VPC Peering에 대해서 알아보겠습니다. 완전히 격리된 vpc간에 네트워크 연결을 하는 옵션이고, 다른 account 뿐 아니라 다른 리전의 vpc도 연결이 가능합니다.
vpc간에는 ip주소가 중복될 수 없고, routing table을 통해 통제가 가능하고, 단, transit routing은 제공되지 않습니다.
한 vpc에서 다른 vpc로 peering 요청을 하면 다른 vpc가 peering 승낙을 해야합니다. 그 후에 vpc routing table에 peering된 routing table 정보를 업데이트하면 vpc에 있는 리소스들이 연결이 가능해집니다.
4.1 VPC 확장 시나리오 : aws 서비스와 연계 -> VPC Endpoints - Gateway Type
vpc 내에 있는 자원과 aws 서비스와의 연결을 위해 vpc endpoint를 사용할 수 있습니다. endpoint는 gateway type과 interface type으로 나눌 수 있습니다.
Gateway type은 인터넷을 경유하지 않고, vpc 내에 있는 ec2 인스턴스와 S3, DynamoDB 를 연결할 수 있는 옵션입니다. VPC Endpoint 생성시 routing policy가 추가되어지고, routing table, VPC Endpoint policy, S3 bucket policy 등으로 접근 제어를 할 수 있습니다.
4.2 VPC 확장 시나리오 : aws 서비스와 연계 -> VPC Endpoints - Interface Type
VPC 내의 자원과 aws내의 자원을 private하게 연결할 수 있는 interface type입니다. private link를 통해서 vpc에서 다른 vpc로 접근하는 방법입니다.
aws 서비스 혹은 aws 계정에서 호스팅 된 vpc endpoint 서비스나 aws marketplace 파트너 서비스인 vpc를 비공개로 연결할 때 사용합니다. VPC내 생성된 VPC endpoint network interface를 이용하므로 서비스 연결시 IGW, NAT Gateway, Public IP, DX가 불필요합니다.
