• 수정예정

이전글에서 MSA개요와 Event Storming에 대해 다뤘고,
👉MSA개요
👉Event Storming
이번글부터는 MSA 구현방법을 하나씩 다뤄보겠습니다.

헥사고날 아키텍처 (Hexagonal Architecture)

MSA의 서비스 구현은 기본적으로 헥사고날 아키텍처를 준용합니다.

헥사고날 아키텍처란? 느슨하게 결합된 MSA 서비스 구현을 목표로
Micro Service 단위로 분리된 각 서비스마다 외부와의 연동을 위한 In/Out-Bound Adapter, DB접근을 위한 ORM을 구성하고,
서비스(도메인)별 언어활용을 통한 코드 작성 및 기술적 구현을 진행하는 아키텍처

위 사진과 같이 헥사고날 아키텍처를 준용하여 서비스를 구현한다면 MSA 목표인 독립성을 달성할 수 있을 것으로 기대합니다.

아래는 SpringBoot 기반의 헥사고날 아키텍처를 표현한 사진입니다.

Event Storming to SpringBoot

👉이전글에서 언급한 Event Storming을 활용하여 MSA 서비스를 설계한다면,
보다 쉽게 헥사고날 아키텍처를 준용하여 SpringBoot기반의 서비스를 설계할 수 있습니다.

아래는 Event Storming 스티커와 SpringBoot 모듈간 매핑 관계입니다.

1. Bounded Context : SpringBoot 서버 자체
2. Domain Event : 외부 서비스로의 연동전 Java 객체
3. Command : RestController, Repository
4. Aggregate : JPA or MyBatis or SpringCloud Stream Publisher
5. Policy : SpringCloud Stream Listener

MSA 전환

레거시에서 MSA로의 전환을 시작할 때, 일반적으로 아래 내용이 검토되어야 합니다.

그리고 Strangler 패턴을 적용하여 보다 안정적인 전환이 가능합니다.

Strangler 패턴이란? 레거시 모놀리스에서 Micro Service로 구현할 일부 모듈을 점진적으로 확대 분류하여 Micro Service로 구현함으로서
MSA 전환 시, 비즈니스 영향도를 최소화하는 패턴

해당 Strangler 패턴을 적용하기 위해서는 MSA로 분리된 서비스와 기존 모노리스를 어떻게 연동할 지에 대한 방법을 고민해야 합니다.
아래는 레거시와 MSA간 API 통합 방법입니다.

1. API Gateway : 단일 진입점, URL 기반의 라우팅 수행
2. Service Registry : MSA의 단일 진입점(API Gateway)을 구성하여 API Gateway가 MSA 클러스터 내의 인스턴스를 찾아갈 수 있도록 하는 방법
   
   
   

레거시와 MSA 서비스간의 단일 진입점인 API Gateway를 구성하여 URL 기반의 라우팅이 되도록 구성한다면,
MSA로의 점진적 전환을 위한 Strangler 패턴을 적용할 수 있습니다.

예를들어, Front 모듈에서 Back 모듈로 임의의 요청을 보낼 때의 url로 레거시 서비스와 MSA 서비스를 구분할 수 있다면,
API Gateway에서의 간단한 설정을 통해 url을 통해 레거시와 MSA를 구분한 라우팅이 가능하도록 설계할 수 있습니다. 이를 통해 레거시와 MSA를 통합할 수 있죠.

API Gateway와 Service Registry의 자세한 내용은 추후 별도 글로 다뤄보도록 하겠습니다.

Reference

• 사내 강의 (Developing Cloud Native Application) - 박용주 강사님

DDD (Domain-Driven Design)

DDD란?

DDD란? 소프트웨어 개발 전체 LifeCycle에서 도메인 중심의 사고를 장려하는 소프트웨어 개발 철학

도메인은 특정 분야의 비즈니스라고 볼 수도 있는데,
비즈니스 관점으로 소프트웨어 구조를 설계해보자는 패러다임(?)이라고 생각하면 쉬울 것 같습니다.

예시로 A호텔에서 IT회사인 B테크 회사에게 호텔 예약 플랫폼 개발 사업을 발주했다고 가정해보겠습니다.
기존대로라면 B테크 회사는 대중적으로 활용되었던 폭포수 모델을 활용하여 플랫폼 개발에 나설거에요.
요구사항 수집 -> 설계 -> 개발...
여기서 B테크는 고객의 요구사항을 데이터 및 시스템 중심으로 설계하여 개발을 진행합니다.

B테크는 고객의 요구사항을 데이터 및 시스템 관점으로 설계해야 하는 다소 까다로운 과정을 거치게 되고,
고객의 요구사항이 긴급하게 바뀌었을 때는 해당 과정을 다시 진행해야 하기 때문에 유연하게 대처하기 힘듭니다.

하지만 B테크가 DDD를 적용한다면?

1. 도메인(비즈니스) 지식 중심으로 해당 비즈니스 종사자와 설계를 같이 진행하기 때문에 설계과정을 보다 쉽게 진행할 수 있고,
2. 도메인 중심으로 코드 구조를 짜고 작성하기 때문에 요구사항이 변경되어도 유연하게 대처할 수 있습니다.
   
   

DDD 적용 규칙

위에서 언급한 DDD의 장점을 누리기 위해서는 비즈니스 종사자와 개발자가 코드 기반으로 원할한 소통이 보장되어야 합니다.
이를 위해 아래의 규칙이 준수되어야 하죠.

1. 유비쿼터스 언어 사용

: 비즈니스 종사자와 개발자가 모두 이해할 수 있는 네이밍을 활용해야 합니다. (ex. create_reservation -> make_reservation)

2. 다른 도메인간 언어 통일을 강요하지 않습니다.

: 다른 도메인간 언어 통일이 되었을 때, 오히려 혼란을 야기할 수 있습니다.

3. 코드 구조를 추상화하여 비즈니스 종사자가 쉽게 이해할 수 있도록 합니다.

• AS-IS

    public void createReservation(User user, Seat seat, LocalDateTime startTime, LocalDateTime endTime){
      Reservation reservation = new Reservation();
      reservation.setUserId(user.id);
      reservation.setSeatId(seat.id);
      reservation.setStartTime(startTime);
      reservtiion.setEndTime(endTime);
      this.reservationRepository.save(reservation);
     }

  
  
  

• TO-BE

    public void makeReservation(User user, Seat seat, LocalDateTime startTime, LocalDateTime endTime){
        this.reservationCommandService
            .makeReservation(user, seat, startTime, endTime);
    }

  
  
  

DDD in MSA

MSA개요는 👉MSA개요 글 참고

위와 같은 DDD 적용 규칙은 모놀리스 아키텍처보다 MSA에서 더 쉽게 적용될 수 있습니다.
모놀리스에서는 다른 도메인간 언어 통일이 필요하다는 등의 이유가 있기 때문이에요.

그렇기 때문에 DDD는 MSA에서 많이 활용되고 있는 방법론입니다.

DDD를 MSA에 적용한다고 했을 때,

1. 서비스를 얼마나 쪼갤지?
2. 쪼갠 도메인간 어떻게 연동할 것인지?
   에 대해 추가적으로 검토되어야 합니다.
   
   

서비스를 분해하는 방법

서비스를 얼마나 분해할 지에 대해서는 아래 기준을 고려하여 결정합니다.

1. 서비스 복잡도 : 서비스를 쪼갤수록 야기되는 서비스 구현 및 운영 복잡도
2. 비즈니스 차별성 : 서비스를 쪼갰을 때, 취할 수 있는 비즈니스 및 비용 관점의 이점

도메인간 연동하는 방법

도메인을 어떻게 연동할 지에 대해서는

1. 도메인간 연관성이 얼마나 높은지?
2. 도메인의 중요도가 어떻게 되는지?
   에 따라 달라집니다.
   
   

연관성 및 중요도가 높을 수록 아래 우선순위대로 연동방식을 고려해야 합니다.

1. shared DB : 도메인간 DB를 공유
2. req-res 구조의 동기식 연동 방식 : 타도메인의 연동에 대한 응답을 기다림
3. pub-sub 구조의 비동기식 연동 방식 : 타도메인의 연동에 대한 응답을 기다리지 않음
   
   

Event Storming

Event Storming 이란?

Event Storming이란? 시스템에서 발생하는 이벤트 중심으로 분석 및 설계하는 기법으로 MSA 기반의 도메인에 대한 빠른 이해를 도모

전통적 방식에서 진행하던 UML 및 ERD 설계 대신에 비즈니스 종사자와 함께 진행하는 과정으로 보면 됩니다.

Event Storming 방법

준비

• 참석자

1. PO(업무전문가, 비즈니스 종사자)
2. Front-End 개발자
3. Back-End 개발자
4. 퍼실리테이터 (Event Storming 전문가, Optional)
   
   
   

• 준비 도구

1. 벽이 넓은 공간 (Ex. 넓은 화이트보드 등)
2. 여러 색의 포스트잇
3. 검은색 보드마카
4. 파란색 테이프

진행

• 포스트잇 유형
  

  

  
  
  
  

• 방법 : 아래 언급된 순서에 맞게 포스트잇을 겹쳐 붙이는 방식, 연동의 경우는 선으로 연결, 분리된 도메인은 Bounded Context로서 분리 표시
  

  

  
  
  
  

• 순서

1. Event 발굴 : 비즈니스에서 발생할 수 있는 Event를 발굴
   • 오렌지색 포스트잇 활용
   • 동사의 과거형으로 네이밍 (유비쿼터스 언어, Ex. Account Created)
2. Command 도출 : 이벤트를 초래하는 페르소나(사용자or시스템)의 동작을 도출
   • 파란색 포스트잇 활용
   • 동사원형으로 네이밍 (유비쿼터스 언어, Ex. Create Account)
   • 초래되는 이벤트의 왼쪽에 겹쳐 붙임
   • 데이터에 변화를 일으킬 수 있는 동작 위주로 도출 (CRUD중 CUD case)
3. Actor 도출 : 특정 Command를 수행하는 주체를 결정
   • 노란색 포스트잇 활용
   • 명사로 네이밍 (유비쿼터스 언어, Ex. Customer)
   • 수행하는 Command의 왼쪽에 겹쳐 붙임
4. Policy 도출 : 특정 이벤트가 발생했을 때, 연쇄적으로 발생하는 동작을 도출
   • 분홍색 포스트잇 활용
   • Command와 동일하게 동사원형으로 네이밍 (유비쿼터스 언어, Ex. Send Email)
   • Command와 동일하게 초래되는 이벤트의 왼쪽에 겹쳐 붙임
   • 데이터에 변화를 일으킬 수 있는 동작 위주로 도출 (CRUD중 CUD case)
5. Aggregate 도출 : 같은 Entity를 사용하는 연관 도메인 이벤트들의 집합 도출
   • 노란색 포스트잇 활용
   • 명사로 네이밍 (유비쿼터스 언어, Ex. Account Mgmt)
   • Command와 Event 사이에 겹쳐 붙임 (Command와 Event가 겹쳐 붙어있는 경우, 분리하여 사이에 붙임)
   • 하나의 트랜잭션으로 동작이 필요할 경우, 하나의 Aggregate로 묶음
6. Bounded Context 도출 : 효율적으로 업무 용어를 사용할 수 있는 도메인별 범위로 분리
   • 분리방식 결정 (Domain별 or Transaction별 or Tech Stack별 등)
   • Bounded Context로 Micro Service를 구성한다면 효율적 커뮤니케이션이 가능함
7. Context Mapping : Aggregate간 연동방향 및 방식 결정
   • Event와 Command의 연결 : req-res 연동 방식
   • Event와 Policy의 연결 : pub-sub 연동 방식
     
     
     

• 기타

1. 특정 포스트잇에 대한 질문이 있는 경우, 보라색 포스트잇에 작성하여 문의의 포스트잇에 삐뚤게 붙임 -> 문의를 해결한 경우, 반듯이 고쳐 붙임
   
   
   

• 결과
  

  

  
  
  
  

Next

다음 글은 MSA 구현에 대해 살펴보겠습니다.

Reference

• 사내 강의 (Microservice Modeling) - 박용주 강사님
• DDD란 무엇인가 - 데이터 중심 개발과 도메인 중심 개발 : https://appleg1226.tistory.com/40

CIDR (Classless Inter-Domain Routing)

• CIDR (Classless Inter-Domain Routing) : ip주소를 할당하는 방법 (ex. 122.149.196.85/32, 0.0.0.0/0 등)
  
  
  

• 구성요소

1. Base IP

2. Subnet Mask
   
   
   

3. Private IP : IANA (The Internet Assigned Numbers Authority)에서 생성한 IP 주소

   • AWS VPC Private IP : 172.16.0.0 ~ 172.31.255.255 (172.16.0.0/12)
   • Home networks : 192.168.0.0 ~ 192.168.255.255 (192.168.0.0/16)
     
     
     

Default VPC

• 특징

1. AWS 계정은 Default VPC가 1개씩 있음
2. EC2 인스턴스를 생성할 때, 서브넷을 지정하지 않으면 기본 VPC에 생성됨
3. 처음부터 인터넷에 연결되어 있음 -> 해당 VPC에 생성되는 EC2는 public IP, public/private DNS를 할당받게 됨
   
   
   

VPC

• 특징

1. 단일 region에 여러 VPC 생성 가능 (region당 최대 5개)
2. VPC마다 CIDR 5개 할당
3. 각 CIDR의 최소크기는 /28, 최대크기는 /16
4. VPC내부에서는 private IP만 허용
5. VPC에 CIDR설정 시, 다른 VPC네트워크나 기업 네트워크와 겹치지않도록 주의해야 함
   
   
   

Subnets

• Subnets : VPC 내부에 있는 IP주소 범위의 일부
  
  
  

• 특징

1. Subnet마다 AWS가 IP주소 5개를 미리 지정함 (처음 4개, 마지막 1개) -> 해당IP는 사용도 안되고 인스턴스에 할당도 안됨
   • 첫번째 : Network Address
   • 두번째 : VPC Router용
   • 세번째 : Amazon 제공 DNS에 매핑
   • 네번째 : 예비
   • 마지막 : 브로드캐스트용 (실제로 사용은 불가)
2. public Subnet크기는 작을수록 좋음
   
   
   

Internet Gateway

• Internet Gateway : Subnet에 인터넷을 연결하기 위한 EC2 또는 Lambda
  
  
  

• 특징

1. 수평 확장 가능
2. 가용성 및 중복성이 좋음
3. VPC와 별도 생성 필요
4. 하나의 VPC는 하나의 Internet Gateway만 연결 가능
5. Internet Gateway에 Internet을 허용하기 위해 별도 설정 필요 -> EC2인스턴스에 public IP 자동할당해도 Internet Gateway가 없으면 인터넷 연결 불가
6. Subnet내부의 인스턴스와 Internet Gateway를 연결하기 위해 라우팅 테이블 설정 필요 -> EC2 인스턴스와 라우터 연결 후, 해당 라우터를 Internet Gateway에 연결
   • 라우팅 테이블 생성 후, 서브넷에 할당
   • 라우팅 테이블에서 인터넷상 모든 IP를 Internet Gateway에 연결

Bastion Hosts

• Bastion Hosts : Bastion Host라는 보안 그룹으로 설정된 public subnet에 있는 EC2 인스턴스 -> 동일 VPC 내부의 private subnet의 EC2에 접근하기 위함

• 특징

1. Bastion Host 보안 그룹은 반드시 인터넷 엑세스를 허용해야 함
2. private Subnet 내부의 보안 그룹은 Bastion Host의 트래픽을 허용해야 함
   
   
   

NAT Instance (구형)

• NAT : Network Address Transition
• NAT Instance : private Subnet상의 EC2 인스턴스가 인터넷에 연결될 수 있도록 허용

• 특징

1. public Subnet에서 실행되어야 함
2. Source/Destination Check 비활성화 필요 -> NAT 인스턴스에서 네트워크 패킷을 재작성해야하기 때문
3. Elastic IP 할당 필요 -> VPC 외부로 트래픽이 전달될 때, Source IP가 할당된 Elastic IP가 됨 -> NAT 인스턴스의 네트워크 패킷 재작성
4. 라우팅 테이블을 수정하여 public/private Subnet 상의 EC2 트래픽이 NAT 인스턴스로 전송되도록 함 -> Destination이 어디일 때, Target으로 NAT Instance 설정
5. 현재는 NAT Gateway 서비스 권장 -> 가용성이 좋지 않기 때문
6. 보안그룹 및 규칙 관리 필요
7. EC2 인스턴스로 생성할 때, NAT 전용 AMI가 있음
   
   
   

NAT Gateway

• NAT Gateway : AWS 관리형 NAT Instance
  
  
  

• 특징

1. 고가용성
2. 관리할 필요 없음
3. 특정 AZ에 생성되고 Elastic IP를 할당받음
4. EC2 인스턴스와 같은 Subnet에서 사용할 수 없음 -> 다른 Subnet에서 접근할 때 도움됨
   • 일반적인 case : Private Subnet -> NAT Gateway -> Internet Gateway
5. 대역폭은 초당 5Gbps, 최대 45Gbps까지 확장 가능
6. 보안그룹 관리 필요 x
7. private Subnet의 Route Table을 수정하여 트래픽이 NAT Gateway로 갈 수 있게끔 설정

• NAT Gateway의 고가용성

1. 단일 AZ에서 복원 가능 -> AZ가 중단되었을 경우를 대비하여 Multi-AZ 배치 가능
2. Multi-AZ일 때, AZ간 서로 연결할 필요 없음

• NAT Gateway vs NAT Instance

Security Groups and NACL (Network ACL)

• NACL : Subnet 보안 Level, Subnet을 오가는 트래픽을 제어하는 방화벽이라 보면될 듯
  
  
  

• Incoming Request : 요청이 Subnet으로 들어가기 전에 NACL로 이동 (요청이 허용되지 않으면 Subnet으로 못들어감) -> NACL을 통과하면 Security Group 인바운드 규칙 검증

• Outbound Request : Security Group 아웃바운드 규칙 검증 -> Security Group을 통과하면 NACL 아웃바운드 규칙 검증

• 특징

1. NACL은 무상태 Security Group은 상태유지 -> Inbound 규칙이 허용되면 Outbound 규칙은 자동으로 허용됨 (상태유지) -> NACL Outbound 규칙은 검증 필요 (무상태)
2. Subnet마다 1개의 NACL 할당 -> 새로운 Subnet 생성 시, Default NACL 할당
3. NACL의 우선순위는 index가 낮을수록 높음
4. Subnet 수준에서 특정 IP를 제한하는 데 적합함
5. 우선순위가 높은 Rule중 맞는 Rule이 있다면, 후순위의 Rule은 검증하지 않음
6. 마지막 우선순위 Rule은 모든 요청을 제한하는 Rule
   
   
   

• Default NACL

1. 인바운드와 아웃바운드에 대한 모든 요청을 허용
2. 수정하지 않는 것을 권장
   
   
   

• 임시포트

1. 클라이언트는 규정된 포트로 접근 (ex. HTTP : 80)
2. 서버가 클라이언트에 응답을 주려면 포트가 있어야하는데, 클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때 자체적으로 특정 포트를 열게됨 -> 임시포트, 연결되는 동안만 열려있음
3. 운영체제에 따라 임시포트의 범위는 달라짐 (ex. Windows 10 : 49152 ~ 65535)

• NACL with 임시포트
  : client측에서 server의 응답을 받기 위해 client측 Subnet Inbound Rule에 임시포트 범위를 허용하고, server측 Subnet Outbound Rule에 임시포트 범위를 허용해야 함

• Security Group vs NACL

VPC Peering

• VPC Peering : 다양한 region/계정에서 생성되는 VPC를 AWS 네트워크를 통해 연결하고 싶을 때 활용 -> 연결되는 VPC가 모두 같은 네트워크에 있을 수 있도록 함
  
  
  

• 특징

1. VPC Peering이 필요하다면 CIDR이 겹치지않도록 설정해야 함
2. VPC Peering은 무조건 직접 연결되어 있어야 함
3. VPC Peering 이후 Subnet마다 Route Table을 업데이트 해야 Subnet 내부의 EC2 인스턴스간 통신이 가능해짐
4. 다른 계정간에도 통신 가능
5. Security Group 참조 가능

VPC Endpoints

• VPC Endpoints : AWS 네트워크를 통해 VPC에서 AWS 서비스를 이용할 수 있도록 해주는 서비스

• 특징

1. public internet이 아닌 AWS 네트워크를 통해 AWS 서비스 접근 가능 (AWS PrivateLink)
2. 거쳐가는 노드가 적기 때문에 internet보다는 비용 효율적
3. 에러 발생 시, VPC DNS 설정이나 Route Table 확인하면 됨
   
   
   

• Types of Endpoints

1. Interface Endpoints (PrivateLink)
   • ENI 프로비저닝
   • ENI : VPC의 Private IP Address, AWS의 Entry Point -> Security Group 설정 필요
   • ENI 비용 청구는 시간 단위의 데이터 처리량에 따라 달라짐
2. Gateway Endpoints
   • Gateway 프로비저닝
   • Gateway는 Route Table의 대상 (IP or Security Group or Gateway)
   • Amazon S3와 DynamoDB에 활용 가능 -> 해당 서비스에서 Interface Endpoint가 권장되는 경우는 온프레미스 or 다른 VPC에 접근해야할 경우
   • 요금은 무료
   • Auto Scale 가능 -> Route Table만 수정하면 됨

VPC Flow Logs

• VPC Flow Logs : Interface로 들어오는 IP 트래픽에서 정보를 확인할 수 있음 (VPC/Subnet/ENI level)
  
  
  

• 특징

1. S3, CloudWatch Logs, Kinesis Data Firehose에 전송 가능
2. AWS 서비스로의 트래픽으로부터 정보를 캡처 (ELB, RDS, ElastiCache, Redshift, NATGW 등)
3. VPC Flow Logs에 쿼리하는 방법 : Athena + S3, CloudWatch Logs Insights (스트리밍 분석)
   
   
   

• VPC Flow logs Syntax

• VPC Flow logs를 이용하여 Security Group과 NACL issues 해결하는 방법

1. ACTION 필드 확인
   • Inbound REJECT : 외부로부터 EC2 인스턴스로 들어오는 트래픽이 제한됨 -> NACL or SG이 거부
   • Inbound ACCEPT, Outbound REJECT : NACL issue -> SG는 상태유지
     
     
     

• VPC Flow logs Architecture

Site-to-Site VPN

• Site-to-Site VPN : AWS 외부 온프레미스 Data Center와 VPC를 private으로 연결하기 위한 VPN

• 특징

1. public internet을 거치지만, VPN연결이므로 암호화되어 있음
2. 필요한 것
   • Virtual Private Gateway (VPG) : VPN역할을 하는 Gateway로 VPC에 연결됨
     • 해당 Subnet Route Table의 Route Propogation 활성화 필요
   • Customer Gateway (CGW) : VPN에 연결하기 위한 고객측 Gateway -> AWS에서 생성
     • IP주소 확인 (VPG와 연결할 용도) -> private으로 유지하고 싶다면 NAT 장치를 활용하게 됨 (NAT 장치의 IP가 public용도로 활용됨)
       
       
       

• AWS VPN CloudHub

1. 여러 VPN연결을 통해 안전한 통신을 보장
2. 저비용의 Hub&Spoke 모델
3. 고객 네트워크 간에도 VPN을 통해 통신 가능
4. 모든 트래픽은 public internet을 경유
5. 방법 : VGW에 여러 VPN연결을 생성한 후에 동적 Routing을 활성화하고 Route Table을 설정하면 됨

Direct Connect (DX)

• Direct Connect (DX) : 사설 Data Center에서 VPC로의 전용 private connect 제공

• 특징

1. 방법 : VPC에 Virtual Private Gateway (VPG) 생성 -> Direct Connect (DX) 생성 -> 외부 온프레미스에서 DX를 통해 private AWS Resource 접근 가능
2. public internet을 거치지 않음
3. 큰 데이터를 처리할 때 속도가 빠름
4. 비용 절약 가능
5. IPv4, IPv6 모두 지원
6. private resource에 접근할 때에는 Private Virtual Interface 사용
7. public resource에 접근할 때에는 Public Virtual Interface 사용
8. 암호화 기능이 없지만, private 전송은 보장됨 -> 암호화가 필요할 경우, DX + VPN 결합 방법이 있음
   
   
   

• Direct Connect Gateway
  : 다른 region에 있는 하나 이상의 VPC와 연결해야할 때 활용

• Connection Types : 연결을 새로 만들 때, 최소 한달이상 걸림

1. Dedicated Connection
   • 1Gbps ~ 100Gbps 용량
   • 물리적 전용 이더넷 포트 할당
2. Hosted Connection
   • 50Mbps ~ 10Gbps 용량
   • 필요 시, 용량을 증설하거나 감축시킬 수 있음
     
     
     

• Resilincy (복원력)
  : Multiple DX 설치 (Multiple Connection Location and Multiple Connection)

• VPC + DX의 backup
  : VPC, DX 둘 중 하나가 문제가 생기면 서로 전환하면서 장애복구 가능

Transit Gateway

• Transit Gateway : 여러 VPC를 연결하기 위한 Gateway -> VPC간 peering 때문에 야기되는 복잡한 AWS 네트워크 토폴로지를 보완 (mesh -> 중앙집중형?)
  
  
  

• 특징

1. region간 활용 가능
2. 계정간 활용 필요할 시에는 Resource Access Manager 설정
3. Transit Gateway의 Route Table을 통해 Routing 설정 가능
4. AWS 유일 IP Multicast 지원

• Use case1 : ECMP 활용하여 Site-to-Site VPN 대역폭 늘리기
  => ECMP (Equal-cost multi-path, 여러 최적 경로를 통해 패킷을 전달하는 Routing 전략) : Site-to-Site VPN을 활용할 때 VPC에 있는 두 개의 터널중 하나만 사용하지만, Transit Gateway를 경유하는 경우에는 두 개의 터널을 동시에 사용함 (Transit Gateway의 전이특성 때문) -> Transit Gateway를 이용하면 다수의 VPN을 만들 수 있고, 두 번째 VPN을 만드는 경우에는 4개의 터널이 생김 -> 연결 처리량 증가

• Use case2 : 계정간 Direct Connect (DX) 공유 (Transit Gateway의 계정 공유 특성 활용)

Traffic Mirroring

• Traffic Mirroring : VPC에서 네트워크 트래픽을 수집하고 검사하되 방해되지 않는 방식으로 실행하는 기능

• 특징

1. 관리중인 Security Appliance대로 트래픽을 라우팅 (Traffic Mirroring Routing 설정) -> 수집하려는 트래픽이 있는 Source측 ENI 정보를 정의하고, 어디로 트래픽을 보낼지 Target ENI or NLB 정의해야 함 -> Target에는 트래픽을 분석하는 Software가 있음
   
   
   

VPC용 IPv6

• IPv6 특징

1. private 전용 ip가 따로 있진 않음
   
   
   

• 특징

1. private IPv4 주소, public IPv6 주소를 만들어 동시에 사용 가능
   
   
   

Egress-only Internet Gateway (송신 전용)

• Egress-only Internet Gateway : IPv6 아웃바운드 연결을 허용하고 동시에 인터넷이 인스턴스로 IPv6 연결이 불가하도록 제한함

• 특징

1. IPv6 트래픽에만 사용 가능
2. 라우팅 테이블 업데이트 필요
   
   
   

• IPv6 라우팅

AWS 네트워크 비용

1. public internet 보단 private AWS 인프라가 네트워크 비용이 절감됨
2. 동일 가용영역 내에서는 네트워크 비용 무료

3. AWS에서 public으로 보내는 트래픽은 비용발생
4. public에서 AWS로 들어오는 트래픽은 무료

5. Transfer acceleration 기능은 추가비용 발생
6. S3 -> CloudFront 비용은 무료
7. CloudFront에서 인터넷으로 보내는 비용(GB당 0.085달러)이 S3에서 인터넷으로 보내는 비용(GB당 0.09달러)보다 저렴

8. NAT Gateway vs Gateway VPC Endpoint

AWS Network Firewall

• AWS에서 제공하는 네트워크 보호 방법

1. NACL
2. VPC Security Group
3. AWS WAF (취약점 공격 보호)
4. AWS Sheild (DDoS 공격 보호)
5. AWS Firewall Manager
   
   
   

• AWS Network Firewall : VPC의 Inbound/Outbound 트래픽을 모두 감시함

• 특징

1. 내부적으로 AWS Gateway Load Balancer 사용
2. 네트워크 3계층부터 7계층까지 모두 보호
3. 여러 계정과 여러 VPC에 모두 적용
4. 수천개의 규칙을 생성할 수 있음
5. IP/Port/Protocol/도메인별 필터링 가능
6. 패턴매칭 방식으로 필터링 가능