이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate
CIDR, IP
CIDR
- Classless Inter-Domain Routing, 클래스 없는 도메인 간 라우팅
- 단순한 IP 범위를 정의하는데 도움을 줌 (ex. 192.168.0.0/26 => 162.168.0.0 ~ 192.168.0.63)
CIDR 구성
Base IP : 범위 시작이나 범위 내부의 IP
Subnet Mask : IP에서 변경가능한 비트의 개수를 정의 (두가지 표현법 /8 <-> 255.0.0.0
Subnet Mask
- /32는 2^0으로 한개의 IP만 나타냄... /31은 2^1개 IP 즉, 2개 IP 나타냄
- /16은 2^16으로 65,536개의 IP를 나타냄
공용/사설 IP
- IANA에서 IPv4 블록을 공용/사설로 확립해둠
Private IP
- 10.0.0.0/8 : 대형 네트워크에서 사용
- 172.16.0.0/12 : AWS 기본 VPC 범위
- 192.168.0.0/16 : 홈 네트워크
나머지 IP는 공용 주소
VPC
기본 VPC
- 계정을 시작하면 AWS에 VPC가 하나 생김
- 기본 VPC는 기본적으로 인터넷에 연결되어 있어서, 내부 EC2 인스턴스를 생성하면 공용 IPv4 주소를 얻게됨
- 기본 VPC에는 서브넷이 3개 있고 각자 다른 AZ에 위치하고 있음
- 기본 VPC에는 모든 트래픽이 인터넷 Gateway로 들어오게 라우팅 테이블이 설정되어 있음
VPC 개요
- Virtaul Private Cloud
- 기본적으로 한 리전에 5개까지 VPC를 생성할 수 있음.. 늘릴 수 있음
- VPC마다 할당된 CIDR는 5개
- 각 CIDR의 최소 크기는 /28(최소 IP 16개), 최대 크기는 /16(최대 IP 65,536개)
- VPC는 사설 네트워크이므로 사설 IP 주소만 쓸 수 있음
- 단, VPC CIDR가 다른 네트워크(협력사 등)의 주소와 겹치지 않도록 주의
- Tenancy : VPC 내에서 EC2 인스턴스가 실행되는 방법 정의(전용, 공유(기본) 하드웨어)
서브넷
- VPC 내부에 있는 IPv4 주소의 부분 범위
- AWS가 서브넷마다 IP주소 5개(처음 4개, 마지막 1개)를 예약함...할당이나 사용못함
- 10.0.0.0 : 네트워크 주소
- 10.0.0.1 : VPC 라우터용
- 10.0.0.2 : Amazon 제공 DNS에 매핑
- 10.0.0.3 : 지금은 사용 X, 나중을 위한 예약
- 10.0.0.255 : VPC에서 브로드캐스트를 지원하지 않기 때문에, 브로드캐스트 IP는 막혀있음
`- AWS에서 29개 IP 주소가 필요할 때 subnet 사이즈로 /27은 선택 못함.. 32 - 5 < 29
인터넷 Gateway & 라우팅 테이블
- VPC 내 리소스를 인터넷에 연결
- 수평으로 확장되고 가용성과 중복성이 높음
- VPC와는 별개로 생성해야함
- VPC는 IGW 하나에만 연결.. 반대의 경우도 동일
- IGW 자체는 인터넷 연결을 허용하지 않아서, 라우팅 테이블을 수정해야함
Bastion 호스트
- 배스천 호스트는 EC2 인스턴스로 퍼블릭 서브넷에 위치하고, 프라이빗 서브넷에 있는 EC2 인스턴스에 액세스할 수 있게 해줌.. 프라이빗 인스턴스에 ssh로 액세스
- 배스천 호스트의 SG는 반드시 인터넷 액세스를 허용해야하는데, 보안상 기업의 퍼블릭 CIDR나 사용자의 인터넷 액세스만 허용하는 등 제한하는게 좋음
NAT 인스턴스
- NAT, Network Address Translation (구형이지만 시험에 나옴)
- Private 서브넷에 있는 EC2인스턴스가 인터넷에 연결되도록함
- NAT 인스턴스는 public subnet에서 실행되고, 공용/사설 서브넷을 연결함
- EC2 세팅에서 Source/Destination Check을 비활성화해야함... 네트워크 패킷의 출발지 IP가 NAT로 재작성되기 때문..
- 고정된 탄력적 IP가 연결되어야함
- 가용성이 높지않고, 초기화 설정으로 복원할 수 없고, EC2 인스턴스 대역폭에 의존적임... NAT Gateway로 대체
NAT Gateway
- AWS 관리형 NAT 인스턴스로 높은 대역폭 가짐
- 사용량 및 대역폭에 따라 청구
- NATGW는 특정 AZ에서 실행되고 탄력적 IP를 사용
- EC2 인스턴스와 같은 서브넷에서 사용할 수 없음.. 다른 서브넷에서 액세스할 때 도움됨
- 라우팅 Private Subnet -> NATGW -> IGW
- 대역폭은 5GBps고 45GBps까지 자동으로 늘어남
- 보안그룹을 관리할 필요 없음
- 고가용성 : 단일 AZ에서 복원 가능하고, 다중 NATGW를 여러 AZ에 배포 가능
NAT 인스턴스와 비교
- 가용성 : 여러 AZ에 만들어두면 가용성이 높음.. NAT 인스턴스는 장애조치 스크립트로 관리해야함
- 대역폭 : 45Gbps... NAT 인스턴스는 인스턴스 타입에 의존
- 비용 : 사용시간+데이터 전송량... NAT 인스턴스는 인스턴스 사용량과 EC2 밖으로나가는 네트워크 비용
- NATGW는 보안그룹 설정 필요 없음
- NAT 인스턴스는 필요한 경우 Bastion 호스트로도 가능
NACL & SG
NACL이란
- 요청이 서브넷 내부로 들어오기 전 NACL에서 요청이 허용되지 않으면 내부로 들어올 수 없음
- 서브넷 레벨의 방화벽과 비슷, 서브넷마다 하나의 NACL, 새로운 서브넷에는 기본 NACL이 할당
- NACL 규칙에는 우선순위 숫자가 1~32766까지 있음.. 탑다운으로 먼저 걸리는 룰부터 평가됨
- 규칙 숫자를 100씩 증가시키는걸 권장(가운데 들어갈 수도 있으니까)
- 사례: 서브넷 수준에서 특정한 IP주소 차단
- NACL은 무상태, SG는 상태 유지
들어오는 요청의 경우
- SG의 경우 인바운드로 허용되어서 들어갔으면, 아웃바운드(Stateful)는 무조건 허용되어 전부 나올 수 있음
- NACL의 경우 아웃바운드룰(Stateless)에 걸리면 요청이 통과하지 못함
나가는 요청의 경우
- SG의 경우 아웃바운드 룰에서 허용되어서 나갔으면, 인바운드는 무조건 허용되어 들어올 수 있음
- NACL의 경우 인바운드룰에서 평가됨
`기본 NACL
- 연결된 서브넷을 가지고, 인바운드 아웃바운드 모든 요청을 허용하는 특수성을 가짐
- 기본 NACL을 수정하지 않는 것을 추천.. 기본 NACL이 서브넷과 연결되어 있다면 다 허용을 의미
NACL 유의점
임시 포트
- 클라이언트가 서버로 부터 응답을 받을 때는, 자체적으로 특정한 임시 포트를 열게됨
- 클라이언트-서버간 연결이 되어있을 때만 유지
- OS에 따라 범위가 다름(Win10 : 49152~65535, Linux : 32768~60999)
- NACL 설정시 임시포트를 고려해서 In/Out바운드의 허용 포트를 구성해야함
다중 NACL/서브넷 구성시
- 각 NACL의 조합이 NACL 내에서 허용되어야함... 서브넷 마다 고유의 CIDR를 사용하기 때문
- NACL에 서브넷을 추가하면, NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야함
SG vs NACL
- SG는 인스턴스 수준에서 작동, NACL은 서브넷 수준(하위 인스턴스 모두에 적용)작동
- SG는 허용 규칙 제공, NACL은 허용/거부 규칙 제공
- SG는 상태 유지(규칙과 무관하게 트래픽 허용), NACL은 무상태(인바운드, 아웃바운드 규칙이 매번 평가.. 그래서 임시포트 고려해야함)
- SG는 모든 규칙이 평가, NACL은 우선순위 높은 규칙이 먼저 평가
VPC Peering
- VPC를 생성하고 서로 다른 지역, 서로 다른 계정 접속 시, 동일한 지역에 있는 것처럼 연결하기를 원할 때
- VPC 간에는 CIDR 충돌이 일어나면 안됨
- VPC 피어링은 두 VPC간에 설정할 수 있으며 전이되지 않음... 서로 통신하려는 각 VPC에는 VPC 피어링이 활성화 되어 있어야함
- VPC a,b,c가 있을 때, a-b, b-c간 피어링 설정을 하더라도 a-c 연결하려면 따로 a-c 피어링 설정을 해야함
- 다른 VPC의 EC2끼리 통신하려면, 각 VPC의 서브넷들의 모든 라우팅을 업데이트 해야함
- 같은 리전의 다른 계정 내 VPC끼리 피어링 설정을 할 때, VPC의 보안그룹을 참조하는 것도 가능함... 출발지를 CIDR나 IP로 할필요없이 SG로 하면되기 때문에 강력함
VPC 엔드포인트
- 퍼블릭 인터넷을 거치지 않고, DynamoDB 등 인스턴스에 액세스하는 방법
- VPC 엔드포인트는 VPC 내에 배포됨... NAT Gateway를 통하면 네트워크 비용발생하는데, 이렇게하면 다이렉트로 연결하는것이라 괜찮음
- 중복과 수평 확장 가능
- IGW, NATGW 없이 AWS 서비스에 액세스 가능.. 네트워크 인프라 간단해짐
- 문제 발생시 VPC에서 DNS 설정 해석이나 라우팅 테이블 확인하면됨
유형
인터페이스 엔드포인트(PrivateLink 활용)
- ENI를 프로비저닝, ENI는 VPC의 프라이빗 IP 주소이자 AWS의 엔트리 포인트임...
- ENI가 있으나 SG를 연결해야함
- AWS 모든 서비스를 지원
- 시간 단위 + 데이터 GB 단위로 요금 청구
게이트웨이 엔드포인트
- 게이트웨이를 프로비저닝, 게이트웨이는 반드시 라우팅 테이블의 대상이 되어야함
- 라우팅 테이블의 대상이 될 뿐, SG는 사용안함
- 대상으로는 S3, DynamoDB 두 가지뿐(시험에서 이걸로 예시 나오면 게이트웨이 선택)
- 장점 : 무료, 라우팅 테이블 액세스일 뿐이기에 자동으로 확장됨
- 단, 온프레미스에서 접속해야할 때나, 다른 VPC/리전에서 접속할 때는 인터페이스 엔드포인트가 유리함
VPC Flow Logs
- 인터페이스로 들어오는 IP 트래픽에서 정보를 포착 가능
- VPC, Subnet, ENI 수준에서 포착 가능
- 연결 문제 모니터링 및 해결에 유용함... 네트워크 패킷의 메타데이터
- 로그를 S3, CloudWatch Logs, KDF에 전송 가능
- 문법 : 버전, 인터페이스ID, 소스/대상주소, 소스/대상 포트, 프로토콜, 패킷, 바이트 수, 시작/끝, 액션, 상태
- 로그를 쿼리하려면 S3와 Athena 혹은 스트리밍 시 CW Insight 활용
ACTION 판단(들어오는 요청)
- Inbound REJECT -> NACL or SG에서 걸림
- Inbound ACCEPT+Outbound REJECT -> NACL에서 걸림
아키텍처 사례
- 1. CW Log를 거쳐 CW Contributor Insights와 연결해서 상위 10개 IP 추출 가능
- 2. CW Log를 거쳐 매트릭 필터로 특정 프로토콜을 검색해서 CW Alarm을 트리거 후 SNS로 알림
- 3. S3 버킷에 저장 후 Athena로 SQL문으로 분석 후 QuickSight로 시각화
Site-to-Site VPN, VGW, CGW
Site-to-Site VPN
- 고객사 온프레미스 서버에 VPC 네트워크를 연결하는 경우
- 퍼블릭 인터넷을 거치지만 VPN이라서 암호화되어있음
가상 사설 게이트웨이(VGW)
- VPN연결에서 AWS 측에 있는 VPN concentrator(접선기)
- VGW는 생성되면 VPC에 연결됨
- ASN 설정 가능
Customer Gateway(CGW)
- 고객 게이트웨이 : 갖춰야할 SW 혹은 물리적 장치
`구성 방법
- 고객 게이트웨이 공용 IP나, 고객 NAT 측 공용 IP를 이용해서 VGW와 연결
- 서브넷의 VPC에서 라우트 전파를 활성화해야 실제로 작동
- 온프레미스에서 AWS로 EC2 상태를 진단할 때, SG 인바운드 ICMP 프로토콜 활성화 확인
VPN CloudHub
- VGW가 갖춰져있고, 고객사마다 CGW가 있는 상황
- CloudHub는 여러 VPN연결을 통해 모든 사이트 간 안전한 소통 보장
- hub&spoke 모델 : VPN만을 활용해 서로 다른 지역 사이, 기본 및 보조 네트워크 연결성에 사용
- 하나의 VGW에 여러 고객사 CGW를 site-to-site VPN 연결하면 고객사끼리도 VPN연결로 소통 가능
- 라우팅 테이블엔 동적 라우팅 활성화
- 사례 : 온프레미스 사이트들을 연결하기 위해 공용 인터넷을 사용하는 백업 연결을 생성하여, 제공 업체에 문제가 발생한 경우 장애 조치로 사용
Direct Connect(DX)
- VPC로 전용 프라이빗 연결을 제공
- 전용 연결 생성하고, AWS Direct Connect 로케이션을 사용
- VPC에는 가상 프라이빗 게이트웨이를 설정해야함
- 퍼블릭 S3와 프라이빗 EC2 사이도 동일하게 연결가능
- IPv4, IPv6 지원
- 암호화 연결은 없지만 연결 자체가 프라이빗이기에 보안 유지 가능
- 더 보안성 높이고 싶다면 VPN과 함께 써서 IPsec으로 암호화된 프라이빗 연결 가능
사례
- 대역폭이 증가할 때, 큰 데이터 세트를 처리할 때 속도 향상, 비용절감... 퍼블릭 인터넷을 거치지 않기 때문
- 퍼블릭 인터넷에 문제가 발생해도, Direct Connect를 사용하면 연결 상태 유지 가능.. 실시간 데이터 피드를 사용하는 애플리케이션에 유용
- 하이브리드 환경 제공... 온프레미스+클라우드
아키텍처
VPC 내 프라이빗 서브넷 내 EC2와 연결
1. VPC 내 프라이빗 서브넷에서 VGW를 설정
2. 프라이빗 VIF(virtual interface)를 통해서 AWS Dircet Connect Location 內 DX Endpoint와 연결
3. DX Location 내 DX Endpoint와 고객 라우터와 연결
4. 고객 온프레미스에서 라우터와 방화벽 설정하고 DX Location과 프라이빗 VIF로 연결
S3/Glacier과 연결
1. 퍼블릭 리소스기 때문에 퍼블릭 VIF로 DX Endpoint와 연결
2. 위 (3), (4)와 동일하고, 퍼블릭 VIF로 연결되는것만 다름
Direct Connect Gateway
- 다른 리전에 있는 하나 이상의 VPC와 연결시 사용
- 온프레미스와 게이트웨이를 연결하고, 게이트웨이에서 각 리전 內 VPC로 연결
DX 유형
전용 연결
- 초당 1, 10, 100Gbps 용량 선택
- 물리적 전용 이더넷 포트 할당
호스트 연결
- 50Mbps, 500Mbps, ~ 10Gbps 용량 선택
- 필요하면 용량을 추가하거나 제거할 수 있는 온디멘드
- 선택한 로케이션에서 1,2,5,10 Gbps 이용 가능
- 전용, 호스트 연결 둘 다 새 연결을 만들려면 리드 타임이 한달 이상 걸릴 수도 있음
`- 시험에서 일주일밖에 시간이 없다면 DX는 못고름
`복원력
- 핵심 워크로드의 복원력 높이기 위해서 여러 DX를 설치하는게 좋음
- 여러 DX Location에 중복으로 연결해서 복원력을 높임
`최대로 복원력 높이기 : 각 DX 로케이션에 독립적인 연결을 두 개씩 수립할 수 있음
`아키텍처
- DX를 Primary Connection으로 두고, Site-to-Site VPN을 백업 연결로 둘 수 있음
- DX를 여러개 두면 좋지만 비용이 많이 들기 때문
Transit Gateway
- VPC가 많아지면 VPN peering도 늘어나고, 관리하기 어려운 토폴로지 구조가됨
- VPC 수천개, Site-to-Site VPN, DX, 온프레미스 DC, hub-spoke 간 스타형 연결 사이에 '환승 피어링'이 생기는 것
- 각 VPC를 피어링할 필요 없이, 환승 게이트웨이로 전이적으로 연결됨
- 각 VPC는 서로 연결되는데, 환승 게이트웨이에 DX 게이트웨이를 연결하면 DXG가 각기 다른 VPC에 연결
- CGW에서 site-to-site VPN으로 환승 게이트웨이와 연결해도 동일하게 모든 VPC에 액세스 가능
- 리전 리소스
- 리전간 TGW를 피어링할 수도 있음
- TGW의 라우팅 테이블로 어느 VPC가 누구와 통신할지 트래픽 경로 제어 가능
- AWS에서 유일하게 IP 멀티캐스트를 지원하는 서비스
`사례1
- Site-to-Site VPN 연결을 많이해서 AWS로의 대역폭을 늘리는 경우
- ECMP(Equal-cost multi-path)를 사용
- 여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략
- 1GB마다 요금 청구
가상 프라이빗 게이트웨이 사용시
- VPC마다 터널(연결) 하나가 생기고, 연결당 1.25Gbps 최대 처리량 제공
- VPC 연결은 2개의 터널을 제공함
환승 게이트웨이 사용시
- Site-to-Site VPN 하나가 여러 VPC에 생성되고, ECMP 덕에 2.5Gbps 처리량을 가짐
- Site-to-Site VPN을 여러개 추가할 수도 있어서, 연결할 때마다 2.5 * N으로 늘어남
사례2
- DX연결을 여러 계정에서 공유할 때 사용
- TGW를 서로 다른 계정 VPC 두개에 모두 생성하고, DXGW와 VIF로 연결
VPC 트래픽 미러링
- VPC에서 네트워크 트래픽을 수집하고 검사하되, 방해되지 않는 방식으로 실행
- 관리 중인 보안 어플라이언스로 트래픽을 라우팅
- 출발지 ENIs를 설정하고, 목적지 ENI나 NLB를 설정함
- 필터를 걸 수도 있음, 여러개 ENI들과도 연결 가능
- 사례 : 콘텐츠 검사, 위협 모니터링, 트러블슈팅 등
IPv6
- IPv4가 빠르게 고갈되어 사용
- AWS의 모든 IPv6 주소는 공개되고 인터넷 라우팅이 가능해짐... 프라이빗 영역이 없음
- 형식 : x.x.x.x.x.x.x.x 로 x는 16진수 0000~ffff
VPC에서 IPv6
- VPC에서 IPv6를 듀얼 스택 모드로 활성화 가능... 단, IPv4를 비활성화 할 수 는 없음
- 이런 VPC에서 EC2 인스턴스 생성시 사설 내부 IPv4와 공용 IPv6을 확보
- IGW를 통해 IPv4, IPv6을 통해 인터넷과 통신 가능
`트러블슈팅
- ex) IPv6 지원 VPC가 있는데, 서브넷에서 EC2 인스턴스를 생성할 수 없는 경우?
ㄴ 서브넷에 사용 가능한 IPv4가 없기 때문... 서브넷에 IPv4 CIDR를 생성하면 해결됨
Egress-only Internet Gateway
- 송신 전용 인터넷 게이트웨이는 IPv6 트래픽에만 사용됨
- NATGW와 비슷하지만 IPv6 전용
- 인스턴스에서 IPv6상 VPC 아웃바운드 연결을 허용하고, 인터넷이 인스턴스로 IPv6 연결을 시작하지 못하게 막음
- 라우팅 테이블 업데이트해야함
- Private Subnet 內 인스턴스에서 바로 Egress-only IGW타고 인터넷에 액세스해도, 역으론 액세스할 수 없어서 프라이빗 유지
Public EC2의 경우
- IPv4, IPv6 모두 IGW통해서 연결
Private EC2의 경우
- IPv4는 NATGW-IGW 통해서 연결
- IPv6은 Egress-only IGW연결
VPC 요약
CIDR : IP 범위
VPC : 가상 프라이빗 클라우드, IPv4,6 CIDR 리스트 정의
Subnet : AZ에 묶이고, CIDR 정의
IGW : VPC 수준에서, IPv4,6 인터넷 액세스 제공
Route Table : 네트워크가 VPC 내에서 흐르도록하는 키... 라우트 경로를 수정, IGW로의 경로들, VPC 피어링 연결, VPC 엔드포인트 등을 포함
Bastion Host : SSH에 들어갈 수 있던 퍼블릭 EC2 인스턴스.. 다른 프라이빗 서브넷 內 EC2 인스턴스들과 SSH 연결 가능
NAT Instance : 퍼블릭 서브넷에 배포된 EC2 인스턴스로, 프라이빗 서브넷의 EC2 인스턴스에게 인터넷 접근 근 제공, 소스/대상 확인 비활성화
NAT Gateway : 요청 타겟이 IPv4일 때 사용.. 프라이빗 EC2에서 확장성있는 인터넷 접근 제공
NACL : 서브넷 수준에서 인바운드 아웃바운드 정의하는 방화벽 규칙...임시 포트 고려
SG : Stateful 상태, EC2 인스턴스 수준에서 동작
VPC Peering : 두 개의 VPC 서로 연결.. CIDR 겹치지 않아야함.. 비전이적
VPC Endpoint : 프라이빗 액세스 제공, VPC 내 어떠한 AWS 서비스도 가능
GW Endpoint : S3, DynamoDB에 특화
VPC Flow Logs : VPC 내 모든 패킷에 관련된 로그레벨의 메타데이터... VPC, Subnet, ENI 수준에서 생성
Site-to-Site VPN : VPC를 DC로 연결, 공공 인터넷을 이용함.. AWS에 가상 프라이빗 게이트웨이 생성 & DC에 고객 게이트웨이 생성 후 VPN 연결
AWS VPN CloudHub : 여러개의 VPN 연결시, hub-spoke VPN 모델을 만들어 사이트들 연결
Direct Connect : VPC를 DC로 연결, 연결히 완전히 프라이빗 상태.. 설립간 1달 이상 걸림, DC를 DX Location으로 연결해야 작동, 보안적으로 더 안전, 안정적 연결
Direct Connect Gateway : 다른 리전에 있는 여러 VPC들을 DX 연결
AWS Private Link / VPC Endpoint
- 고객 VPC에서 직접 생성한 VPC 내에서 서비스로 비공개적으로 연결
- VPC 피어링이나, 공공 인터넷이나, NATGW, 라우팅 테이블 요구 X
- 주로 NLB나 ENI와 사용
- VPC 내의 서비스를 노출시키지 않고, 수천 개의 고객 VPC에 노출 가능
Transit Gateway : VPC, VPN, DX를 위한 전송 피어링 연결
Traffic Mirroring : 네트워크 트래픽을 ENI에서 복사하여 분석
Egress-only IGW : IPv6, NATGW와 비슷
AWS 네트워킹 비용
기본적인 네트워킹 비용
1. EC2 인스턴스로 들어오는 트래픽은 무료
2. 같은 AZ 내 EC2 간의 트래픽(사설 IP통신)은 무료
3. 다른 두 AZ에 있는 EC2 간 통신
- 공공 인터넷을 사용시 0.02$/GB... 트래픽이 나갔다 들어와야함
- 사설 IP 사용시 0.01$/GB.. 지연시간도 줄고, 비용도 줄기에 가능하면 사설IP 써야함
4. 다른 리전에 있는 EC2 간 통신 : 0.02$/GB
비용 아끼는 법
송신 트래픽(아웃바운드, AWS에서 밖으로 나감)
수신 트래픽(인바운드, 밖에서 AWS로 들어옴) : 보통 무료임
- 최대한 인터넷 트래픽을 AWS 안에 둬야함
ex) DB에서 100MB를 가져와 온프레미스에서 쿼리해서 50kb로 줄이는 상황을, AWS EC2에서 쿼리해서 50kb치만 네트워크 비용으로 쓰는거
- DC를 써서 동일 리전안에 DC Location을 두고 통신하는 방법
S3 데이터 전송 비용
- 수신 트래픽 무료
- 다운로드(송신)시 0.09$/GB... 전송 가속화 시 0.04~8$ 추가 비용 발생
- S3에서 CloudFront까지 비용 무료
- CloudFront에서 인터넷으로 전송시 0.085$/GB... 요청을 보낼때마다 7배 저렴해짐
- 리전간 복제 수행시 0.02$/GB
프라이빗 서브넷 내 EC2에서 S3 버킷 접근 시
- EC2 - NATGW - IGW - 인터넷 - S3 접근시... NATGW( 0.045$/h + 0.045$/GB )
- VPC Endpoint 사용시 S3 버킷에 비공개로 데이터를 액세스... 동일리전에서 GW Endpoint(0.01$/GB)
Network FW
- NACL, VPC SG, WAF, Shield & Shield Advanced, FW Manager 등 존재
- 전체 VPC를 보호할 수 있는 수준 높은 방법? Network Firewall 이용
특징
- VPC 수준에서 보호 3~7계층까지 보호
- 모든 방향에서 들어오는 트래픽 확인
- VPC 간 트래픽
- 인터넷 아웃/인바운드
- DX, Site-to-Site VPN 연결
- 내부적으로 GWLB 사용.. 타사 어플라이언스가 아닌 AWS 자체 어플라이언스로 트래픽 관리하는 것
- 중앙 집중식으로 여러 계정과 VPC에 적용 가능
- VPC 수준에서 수천 개의 규칙 지원
- 수 만 IP/Port 별 필터링 가능
- 프로토콜 별 필터링 가능
- 도메인 별 필터링 가능
- 정규표현식 사용 가능
- 트래픽 허용, 차단, 알림 설정 가능
- 활성 플로우 검사로 침입 방지 능력 갖출 수 있음
- 규칙 일치는 S3, CW Logs, KDF로 전송 후 분석 가능
