Architecting on AWS - 02

ENI (Elastic Network Interface)

탄력적 네트워크 인터페이스는 가상 네트워크 인터페이스이다.

동일한 가용역역 안에서 EC2 인스턴스 간에 이동할 수 있다.

새 인스턴스로 이동할 때 ENI는 다음을 유지한다.

• Private IP Address
• Elastic IP Address
• MAC Address

 

VGW(Virtual GW) & CGW(Customer GW)

VGW란 VPC마다 하나씩 존재할 수 있는 가상 프라이빗 게이트웨이이다.

VGW를 통해 다른 VPC와 통신하거나 고객의 On-premise 네트워크에 연결할 수 있다.

이 때 고객 쪽의 게이트웨이는 CGW라고 한다.

 

하나인 VGW에 여러 회선을 연결하여 사용할 수도 있으며, 연결 방식은 AWS Direct Connect와 VPN으로 나뉜다.

 

AWS Direct Connect (DX) vs. VPN

기준	DX	VPN
연결 방식	전용선	인터넷
연결 매개체	DX Location	없음
통신 속도	빠름	보통
보안성	높음	보통
비용	비교적 높음	비교적 낮음

 

DX - 중요

DX는 AWS와 협약을 맺은 회사들로부터 제공되는 전용선을 통해 통신을 하는 것이다.

VPN 방식에 비해 Network Bandwidth가 확보되고, 보안적 측면에서의 이점도 확실히 가져갈 수 있다는 장점이 있다.

현재 DX Location을 제공하는 파트너는 LG U+, 세종텔레콤, Kinix, Dream Line, Console Connect 이렇게 5개가 있다.

가격대는 DX Partner, Network Bandwidth 등에 따라 천차만별이다.

 

VPN

통상적으로 쓰이는 방식이다.

인터넷 회선을 통해 통신한다. DX 대비 속도가 떨어지고 보안이 완전하지 않을 수 있다.

보안과 속도가 중요한 케이스에선 DX를 메인, VPN을 보조회선으로 사용하기도 한다.

---

VPC Peering

2개의 VPC를 직접적으로 연결해 IGW 또는 VGW를 통하지 않고도 서로 간에 통신할 수 있게하는 기능이다.

고가용성 연결로 단일 장애 지점이 없고 대역폭 병목 현상 또한 일어나지 않으며, 트래픽은 항상 글로벌 AWS 백본에서 유지된다. 추가로 서로 다른 리전 간의 연결 또한 가능하다.

2개의 VPC를 각각 Requester와 Accepter로 잡아 Peering Connection을 생성하고, 아래와 같이 각 VPC의 라우팅 테이블에서 서로를 알도록 라우팅해주면 된다.

이를 통해 아래와 같은 인프라를 가져가는 것이 가능하다.

다만 전이적인 Peering은 불가하기에 너무 많은 Peering Connection이 필요할 경우엔 사용하기 힘들다.

n/2 * n-1

연결할 VPC 수를 위 식에 대입하면 만들어야 하는 라우팅 테이블의 수가 나오는데 이 규모가 방대해지면 효율이 크게 떨어지기 때문에 Transit Gateway를 사용해야 한다.

 

Transit Gateway - 중요

이 방식은 피어링과 달리 VPC 또는 온프레미스 네트워크 간 직접 연결하지 않고 트랜짓 게이트웨이를 통해 연결한다.

하나의 트랜짓 게이트웨이로 최대 5000개의 연결을 관리할 수 있으며, 이 트랜짓 게이트웨이의 라우팅 테이블은 연결된 모든 네트워크를 알고 있다. 

 

트랜짓 게이트웨이를 통해 아래와 같은 시나리오를 만족할 수 있다.

 

VPC Endpoint

VPC의 엔드포인트는 다른 AWS 엔드포인트 서비스에 Private하게 연결할 수 있다.

VPC Peering과 비슷하지만, 엔드포인트는 애플리케이션/서비스에 적용한다는 점이 다르다.

엔드포인트에는 두 가지 유형이 있는데, 인터페이스 엔드포인트와 게이트웨이 엔드포인트이다.

 

Interface Endpoint

ENI와 연결된다. Amazon EC2 API, Amazon SNS, AWS Systems Manager 그리고 다른 AWS 계정에서 호스팅하는 엔드포인트 서비스 등이 여기 포함된다. 

ENI는 EC2 Instance에 달려있는 것이기 때문에 많은 엔드포인트 연결을 필요로 한다면 EC2 Instance 생성 시에 미리 많은 ENI를 생성해 두어야 할 것이다.

 

Gateway Endpoint

라우팅 테이블과 연결된다. Amazon S3, Amazon DynamoDB가 여기 포함된다.

---

ELB (Elastic Load Balancing)

연결된 인스턴스들에 대해 주기적으로 Health Check를 하며, 200번 코드를 반환하는 정상 작동 중인 인스턴스에만 요청을 전송한다. 

 

ELB의 종류

• ALB (Application) : 7계층에서 동작. HTTP 및 HTTPS 트래픽의 고급 로드 밸런싱. RR(Round Robin) 알고리즘을 통한 LB.
• NLB (Network) : 4계층에서 동작. TCP, UDP, TLS 트래픽의 로드 밸런싱. Hashing 알고리즘을 통한 LB.
• CLB (Classic) : 구세대 통합형 LB. EC2 Instance 신규 등록 작업 불가. 예전부터 쓰고 있는 고객들이 있기에 Deprecated 되지 않고 있음.

 

ELB 동작 원리

위 사진과 같이 2개의 ELB가 배치되며, Internet Facing ELB와 Internal ELB로 나뉜다.

1. Internet Facing에서 Public Subnet의 Instance들에게 Load Balancing을 해주면
2. 그 Instance들로부터 Internal ELB로 전달.
3. 이후 Private Subnet으로 다시 LB된다.

---

IAM (Identity and Access Management)

말 그대로 인증과 권한에 대한 관리.

IAM의 4개의 주요 Entity는 다음과 같다.

 

User : 단일 IAM 사용자이다.

User Group : 보통 사내 부서 별로 나뉘어진 개별 그룹이다.

Role(역할) : (모자처럼 생겼으니)모자를 쓰고 있는 Duration만큼 임시 자격 증명.

Policy : AWS Service에 대한 액세스만 제어. User, User Group, Role에 권한 부여. JSON 파일 형식이다.

 

Federation User

연동 자격 증명 관리. On-premise에서 관리하다가 AWS를 잠깐 관리하기 위해 On-premise의 자격 증명을 받고 AWS에서 권한을 연동해 간단하게 관리할 수 있음.

 

Root User

결제의 주체. 모든 AWS 서비스와 리소스에 대한 전체 액세스 권한을 갖는다.

Admin 생성 및 사용, Root 접근에 대한 자격 증명 잠금을 하는 것이 안전하다.

 

IAM 사용자 생성

기본적으로는 묵시적 Access Deny이다. 가장 강하게, 최우선으로 권한을 제한하려면 명시적으로 Deny한다.

AWS Management Console 또는 CLI에 대한 액세스는 명시적으로 부여되어야 한다.

 

리소스 기반 - 연결된 AWS 리소스 : Amazon S3, Amazon S3 Glacier 등

자격 증명 기반 - 연결된 IAM 보안 주체 : User, User Group, Role