AWS | 네트워킹 및 콘텐츠 전송

 

 

 

컴퓨터 네트워크 : 서로 연결되어 리소스를 공유하는 2개 이상의 클라이언트 시스템

네트워크는 서브넷으로 논리적으로 분할 가능

 

 

 

32비트 IP 주소 : IPv4

128비트 IP 주소 : IPv6

 

 

 

✅ CIDR : 클래스 없는 도메인 간 라우팅

 

CIDR 주소 표현되는 방법

 

• IP 주소(네트워크의 첫번 째 주소)
• 슬래시 문자
• 마지막으로 네트워크 식별자에 대해 고정 또는 할당해야 하는 라우팅 접두사의 비트 수를 알려주는 숫자

 

고정되지 않는 비트는 변경 가능

CIDR은 서로 연속적인 IP 주소 그룹을 표현하는 방식

 

 

 

위 예제에서 CIDR주소 : 192.0.2.0/24

마지막 숫자 : 24 -> 처음 24비트를 고정해야함, 마지막 8비트는 유연

192.0.2.0~192.0.2.255 범위의 28개 IP 주소를 네트워크에 사용 가능

네 번째 10진수는 0에서 255 사이의 숫자로 변경 가능

 

두 가지 특별한 경우

 

1. 모든 비트가 고정된 고정 IP주소는 단일 IP 주소를 나타냄

방화벽 규칙을 설정하고 특정 호스트에 대한 액세스 권한을 부여하려는 경우 유용

 

2. 모든 비트가 유연한 인터넷은 0.0.0.0/0

 

 

 

✅ OSI 모델

네트워크를 통해 데이터가 이동하는 방식을 설명하는 개념적 모델

 

 

✅ amazon VPC

• aws 클라우드에서 논리적으로 격리된 공간을 프로비저닝하여 가상 네트워크에서 aws 리소스를 시작할 수 있도록 지원하는 서비스
• 자체 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 리소스를 완벽히 제어할 수 있는 기능 제공
• 네트워크 구성을 손쉽게 사용자 지정 가능

 

 

✅ VPC 및 서브넷

VPC

• 다른 vpc와 논리적으로 격리
• 사용자의 aws 계정 전용
• 단일 aws 리전에 속하며 여러 가용 영역에 걸쳐 구현 가능

 

서브넷

• vpc를 생성한 후 하나 이상의 서브넷으로 분할 가능
• vpc를 분할하는 IP 주소의 범위
• 단일 가용 영역에 속함
• 여러 가용 영역에 서브넷을 생성하여 고가용성 실현 가능
• 퍼블릭 또는 프라이빗으로 분류(퍼블릿 서브넷은 인터넷에 직접 액세스 가능하지만 프라이빗 서브넷은 인터넷에 직접 액세스 불가)

 

 

✅ IP 주소 지정

 

• vpc 생성 시 IPv4 CIDR블록에 VPC 할당
• vpc를 생성한 후 주소 범위를 변경 불가
• 가장 큰 IPv4 CIDR 블록 크기는 /16
• 가장 작은 IPv4 CIDR 블록 크기는 /28
• IPv6 도 지원
• 서브넷의 CIDR 블록은 중첩 불가

 

 

✅ 예약된 IP 주소

 

서브넷 생성 시 서브넷엔 자체 CIDR 블록 필요

지정한 각 CIDR 블록에 대해 AWS는 해당 블록 내 5개의 IP 주소를 예약해야함. 해당 주소는 사용 불가

 

 

다음 용도로 IP 주소 예약

• 네트워크 주소
• VPC 로컬 라우터(내부 통신)
• DNS 확인
• 향후 사용
• 네트워크 브로드캐스트 주소

 

=> IPv4 CIDR 블록이 10.0.0.0/24 인 서브넷 생성 가정 ( 총 IP 주소 256개 )

서브넷에는 256개의 IP 주소가 있지만 5개가 예약되어 있으므로 251개만 사용 가능

 

 

 

✅ 퍼블릭 IP 주소 유형

 

 

vpc 생성 시 해당 vpc의 모든 인스턴스에 자동으로 private IP 주소 할당

서브넷의 자동 할당 퍼블릭 IP 주소 속성을 수정해 인스턴스를 생성할 때 할당할 퍼블릭 IP 주소 요청 가능

 

 

탄력적 IP 주소 : 동적 클라우드 컴퓨팅을 위해 설계된 정적 퍼블릭 IPv4주소

탄력적 IP 주소를 사용하면 주소를 VPC의 다른 인스턴스에 신속하게 다시 매핑해 인스턴스 장애 마스킹 가능

 

탄력적 IP 주소를 네트워크 인터페이스와 연결하면 인스턴스에 직접 연결하는 것보다 이점이 있음

 

=> 네트워크 인터페이스의 모든 속성을 한 인스턴스에서 다른 인스턴스로 한 번에 옮길 수 있기에

 

 

 

✅ 탄력적 네트워크 인터페이스 => 가상 네트워크 인터페이스

 

 

 

• 인스턴스에 연결
• 인스턴스에서 분리하고 다른 인스턴스에 연결하고 네트워크 트래픽 리디렉션 시 사용
• 새 인스턴스에 다시 연결할 때 속성이 그대로 적용
• vpc의 각 인스턴스마다 기본 네트워크 인터페이스가 있어 vpc의 IPv4주소 범위에 속하는 프라이빗 IPv4 주소가 이 인터페이스에 할당

 

 

 

✅ 라우팅 테이블 및 경로

• 라우팅 테이블에는 서브넷에서 네트워크 트래픽을 보내도록 구성할 수 있는 세트 포함
• 기본적으로 모든 라우팅 테이블엔 VPC 내부 통신을 위한 로컬 경로 포함되어 있음
• 각 서브넷은 라우팅 테이블(최대 1개)와 연결

 

 

 

 

 

✅ 인터넷 게이트웨이

 

 

• 확장 가능, 이중화 지원하는 고가용성 vpc 구성요소
• vpc의 인스턴스-인터넷 간 통신이 가능한 이유

 

 

인터넷 게이트웨이를 사용하는 2가지 목적

 

1. 인터넷 라우팅 트래픽에 대한 vpc 라우팅 테이블의 대상 제공

2. 퍼블릭 IPv4주소가 할당된 인스턴스에 대해 네트워크 주소 변환 수행

 

 

 

서브넷을 퍼블릭으로 구현하려면, VPC 에 인터넷 게이트웨이를 연결하고 라우팅 테이블에 경로 추가

➡ 인터넷 게이트웨이 통해 인터넷(0.0.0.0/0)으로 비로컬 트래픽 전송

 

 

 

 

✅ NAT 게이트웨이

 

 

NAT를 사용하면 프라이빗 서브넷의 인스턴스를 인터넷 또는 기타 aws 서비스에 연결하는 한편, 인터넷에서 해당 인스턴스와의 연결을 시작하지 못하게할 수 있음

 

 

NAT 게이트웨이 생성 시

• NAT 게이트웨이가 속할 퍼블릭 서브넷 지정해야함
• 탄력적 IP 주소 지정
• 인터넷 바운드 트래픽이 NAT 게이트웨이를 가리키도록 하나 이상의 프라이빗 서브넷과 연결된 라우팅 테이블을 업데이트 해야함
• 프라이빗 서브넷의 인스턴스가 인터넷과 통신 가능
• NAT 게이트웨이 대신 VPC 퍼블릭 서브넷에 NAT 인스턴스 사용 가능
• NAT 게이트웨이 => 더 나은 가용성과 향상된 대역폭을 제공하면서 관리 작업은 간소화하는 관리형 NAT 서비스

 

 

 

✅ VPC 공유

• vpc 공유를 통해 AWS organizations 동일한 조직 내 다른 AWS 계정과 서브넷 공유 가능
• vpc 공유 사용 시 여러 aws 계정에서 ec2, rds db, redshift 클러스터 및 lambda 함수와 같은 어플리케이션 리소스를 중앙 관리형 공유 vpc로 생성 가능
• vpc 소유하는 계정 : aws organizations 동일 조직에 속한 다른 계정과 한 개 또는 여러 개의 서브넷을 공유

 

vpc 공유의 이점

• 업무 분리 - 중앙에서 제어되는 vpc 구조, 라우팅, IP 주소 할당
• 소유권 - 어플리케이션 소유자가 리소스, 계정 및 보안 그룹을 계속 소유
• 보안 그룹 - VPC 공유 참여자가 서로의 보안 그룹 ID 참조 가능
• 효율성 - 서브넷 집적도 향상, VPN 및 aws direct connect 효율적 사용
• 하드 제한 사항 없음 - 하드 제한 사항 피할 수 있음
• 비용 최적화 - NAT 게이트웨이, VPC 인터페이스 엔드 포인트 및 가용 영역 내 트래픽의 재사용을 통해 비용 최적화

 

VPC 공유 사용 시 계정과 네트워크 분리 가능

=> 중앙에서 관리하는 VPC 개수 더 적어짐. 규모 더 커짐

 

 

✅ VPC 피어링 연결 : 두 VPC 사이에서 비공개적으로 트래픽을 라우팅할 수 있게 하는 두 VPC 사이이 네트워킹 연결

 

 

같은 네트워크에 있는 것처럼 양쪽 VPC이 인스턴스에서 통신 가능

피어링 연결 설정 시 VPC 피어링 리소스를 통해 서로 통신가능하도록 테이블에 규칙 생성

 

제한 사항

• IP주소 범위는 중첩 불가
• 동일한 두 VPC간 하나의 피어링 리소스만 설정 가능
• 전이적 피어링은 지원 불가

 

 

✅ AWS 사이트 간 VPN

 

 

VPC로 시작하는 인스턴스는 원격 네트워크와 통신 불가

 

 

VPC를 원격 네트워크에 연결하기 위해

1. 새 가상 게이트웨이 디바이스(VPN)를 생성해 VPC에 연결

2. VPN 디바이스 또는 고객 게이트웨이의 구성을 정의. 고객 게이트웨이는 디바이스가 아니라 VPN 디바이스에 대한 정보를 AWS에 제공하는 AWS 리소스

3. 회사 데이터 센터에 바인딩 된 트래픽이 VPN 게이트웨이를 가리키도록 사용자 지정 라우팅 테이블을 만듦. 보안 그룹 규칙도 업데이트 해야 함

4. aws 사이트 간 VPN 연결을 구성해 두 시스템을 연결

5. 연결을 통해 트래픽을 전달하도록 라우팅 구성

 

 

✅ aws direct connect

 

데이터 센터가 AWS 리전에서 멀리 떨어져 있는 경우 성능 부정적 영향

 

➡ AWS direct Connect 사용 시 네트워크와 DX 로케이션 중 하나 간 전용 프라이빗 네트워크 연결을 설정할 수 있음

 

네트워크 비용 줄임, 대역폭 처리량 높임. 인터넷 기반 연결보다 더 일관된 네트워크 환경 제공

 

 

 

✅ VPC 엔드 포인트 : VPC를 AWS PrivateLink에서 제공하는 지원되는 AWS 서비스 및 VPC 엔드포인트 서비스에 비공개로 연결할 수 있는 가상 디바이스

 

 

두 가지 유형

 

1. 인터페이스 VPC 엔드포인트는 AWS PrivateLink로 구동되는 서비스에 연결되도록 지원

2. 게이트웨이 엔드포인트 : 게이트웨이 엔드포인트를 사용하면 추가 요금이 발생하지 않음. 데이터 전송 및 리소스 사용량에 대한 표준 요금이 그대로 적용

 

 

✅ AWS Transit Gateway

 

VPC 피어링을 사용하여 VPC 페어를 연결할 수 있지만, 지점 간 연결 정책을 중앙에서 관리하는 기능 없이 여러 VPC 전반의 지점 간 연결을 관리하는 것은 운영 비용이 많이 듦

온프레미스 연결의 경우 VPN을 개별 VPC에 연결해야함 -> 구축하려면 시간이 오래 걸림. VPC 수백 개로 늘어나면 관리하기 힘듦

 

AWS Transit Gateway 통해 네트워킹 모델을 간소화하여 문제 해결 가능

중앙 gateway와 네트워크 전반의 각 VP, 온프레미스 데이터 센터 또는 원격 사무실 간의 단일 연결만 생성하여 관리할 수 있음

Transit gateway는 허브 역할

각 네트워크에서 다른 네트워크에 연결할 필요 없이 AWS Transit Gateway에 연결하면 관리 크게 간소화하고 운영 비용 크게 줄여줌

새로운 VPC를 AWS Transit Gateway에 연결하면 AWS Transit Gateway에 연결된 다른 모든 네트워크에서 자동으로 사용 가능

 

 

 

 

정리

 

 

 

 

VPC 보안

 

✅ 보안 그룹

 

 

 

✅ 가상 방화벽 역할

• 인스턴스에 대한 인바운드, 아웃바운드 트래픽 제어
• 서브넷 수준이 아니라 인스턴스 수준에서 작동
• vpc에 있는 서브넷의 각 인스턴스를 서로 다른 보안 그룹 세트에 할당 가능

 

 

 

 

✅ 사용자 지정 보안 그룹

 

 

 

✅ 네트워크 ACL

 

 

 

✅ 선택적 보안 계층

하나 이상의 서브넷에서 송수신 되는 트래픽을 제어하기 위한 방화벽 역할

VPC에 있는 각 서브넷을 네트워크 ACL과 연결해야함

서브넷을 네트워크와 ACL과 명시적으로 연결하지 않는 경우, 서브넷은 기본 네트워크 ACL과 연결

한 네트워크 ACL을 여러 서브넷과 연결 가능

한 서브넷은 한 번에 한 네트워크 ACL에만 연결 가능

 

 

 

 

 

 

✅ 보안 그룹과 네트워크 ACL 비교

 

 

 

 

Amazon Route 53

 

✅ Amazon Route 53

• 가용성과 확장성이 우수한 DNS 웹 서비스
• 사용자 요청을 AWS와 AWS 외부에서 구동되는 인프라에 연결
• 리소스의 상태를 확인하는데 사용
• 트래픽 흐름 나타냄
• 도메인 이름 등록할 수 있도록 지원

 

 

✅ Amazon Route 53 DNS 확인

Route 53에 도메인 확인 -> IP 주소 받음 -> 사용자에게 반환

 

 

 

✅ amazon route 53 사용 사례 -> 다중 리전 배포

 

사용자가 자동으로 가장 가까운 elastic load balancing 로드 밸런서로 연결

 

장점

• 리전에 대한 지연 시간 기반 라우팅
• 가용 영역에 대한 로드 밸런싱 라우팅

 

 

 

✅ Amazon Route 53 DNS 장애 조치

 

가용성 개선 방안

자체 어플리케이션 백업 및 장애 조치 시나리오 구성

aws에 고가용성 다중 리전 아키텍처 활성화

상태 확인 생성하여 웹 어플리케이션, 서버, 리소스 상태와 성능 모니터링. 생성한 각 상태 확인은 지정된 리소스의 상태, 다른 상태 확인의 상태 및 amazon cloudwatch 경보의 상태 중 하나 모니터링 가능

 

 

 

 

✅ 멀티 티어 웹 어플리케이션 dns 장애 조치

 

 

 

route 53은 트래픽을 로드 밸런서로 전달한 뒤 ec2 인스턴스 플릿으로 트래픽 분산

 

 

고가용성 보장 위해 route 53으로 다음 작업 수행 가능

1. CNAME www에 대한 DNS 레코드 두 개와 더불어 장애 조치 라우팅의 라우팅 정책 생성

첫 번째 레코드는 웹 어플리케이션의 로드 밸런서를 가리키는 기본 라우팅 정책

두 번째 레코드는 정적 amazon s3 웹 사이트를 가리키는 보조 라우팅 정책

 

2. route 53 상태 확인을 통해 기본 라우팅 정책이 실행 중인지 확인

기본 레코드가 사용되 ㄴ경우 모든 트래픽이 웹 어플리케이션 스택으로 기본 설정

정적 백업 사이트로의 장애 조치는 웹 서버가 다운 또는 중단되거나 데이터베이스 인스턴스가 다운되면 트리거

 

 

 

 

 

Amazon CloudFront

 

 

 

✅ CDN

• 전 세계에 분산된 캐싱 서버 시스템
• 자주 요청되는 파일(정적 콘텐츠)의 사본 캐싱
• 가까운 캐시 엣지 또는 PoP에서 요청된 콘텐츠의 로컬 사본 전송
• 동적 콘텐츠 전송 가속화
• 어플리케이션 성능 및 확장성 개선

 

 

 

✅ Amazon CloudFront

• 빠르고 안전한 글로벌 CDN 서비스
• 엣지 로케이션 및 리전 엣지 캐시의 글로벌 네트워크
• 종량 과금제
• 셀프 서비스 모델

 

 

✅ amazon CloudFront 인프라

장점

• 빠른 속도와 글로벌한 규모
• 엣지 보안
• 고도로 프로그래밍 가능
• AWS와 완벽하게 통합
• 비용 효율성 - 최소 약정 없음. 사용한만큼만 요금 부과

 

요금 -> 다음 4개 영역의 실제 사용량 기준으로 부과