1. 워크 로드를 지원할 IP 주소 범위 확인
AWS에서는 CIDR 블록을 사용하여 IP 주소 범위를 정의합니다.
IPv4 서브넷용으로 /28(IP 주소 16개)~/16(IP 주소 65,536개) 사이의 블록 크기를 할당할 수 있습니다.
2. 동적 네트워크 인프라 구축 방법
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html
VPC 구성요소를 사용하여 안전한 동적 네트워크 인프라를 구축할 수 있습니다.
VPC 구성요소:
VPC | - 클라우드 네트워크 환경 - 논리적으로 격리된 가상 네트워크에서 AWS 리소스 시작 |
서브넷 | - VPC 내의 IP 주소 범위 - 지정된 서브넷으로 AWS 리소스 시작 - IP 낭비 및 소진을 방지하기 위해 큰 서브넷(/24 이상)을 사용해 워크로드를 분산하는 것을 권장 - 각 서브넷 CIDR 블록에서 처음 4개의 IP 주소와 마지막 IP 주소는 사용할 수 없음 - 10.0.0.0: 네트워크 주소 - 10.0.0.1: VPC 라우터용으로 예약 - 10.0.0.2: DNS 서버의 IP 주소(VPC 네트워크 범위의 기본 IP 주소에 2를 더한 값) - 10.0.0.3: 차후 사용을 위해 AWS에서 예약 - 10.0.0.255: 네트워크 브로드캐스트 주소 |
인터넷 게이트웨이 | - VPC 내 인스턴스와 인터넷 간 통신을 허용 - 인터넷 게이트웨이를 사용하는 목적: 1. 인터넷 라우팅 가능 트래픽용으로 라우팅 테이블에서 대상을 제공 2. NAT를 수행하여 네트워크의 IP 주소를 보호 |
라우팅 테이블 | - VPC가 네트워크 트래픽이 전달되는 위치를 결정 - 자동으로 생성되는 기본 라우팅 테이블의 로컬 경로는 수정 불가 - VPC 내의 각 서브넷은 라우팅 테이블과 연결 - 서브넷을 특정 라우팅 테이블과 명시적으로 연결하지 않는 경우, 서브넷은 암시적으로 기본 라우팅 테이블과 연결 - 서브넷은 한 번에 하나의 라우팅 테이블에만 연결 가능 - 여러 서브넷을 같은 라우팅 테이블에 연결 가능 |
탄력적 IP주소(EIP) | - 동적 클라우드 컴퓨팅을 위해 설계된 정적 퍼블릭 IPv4 주소 - 생성 개수는 5개로 제한 - 인스턴스 장애 발생 시 주소를 다른 인스턴스로 다시 매핑할 수 있도록 EIP 사용 - 그 외의 모든 노드 간 통신에는 ENS 호스트 이름 사용 |
탄력적 네트워크 인터페이스 | - VPC 내의 논리적 네트워킹 구성 요소 - 같은 가용 영역의 리소스 간에 이동 가능 - 프라이빗 IP 주소, 탄력적 IP 주소 및 MAC address가 그대로 유지됨 |
NAT 게이트웨이 | - 프라이빗 IP 주소 보호를 위해 사용 - NAT에서는 프라이빗 IP 주소가 퍼블릭 IP 주소에 매핑되므로 프라이빗 IP 주소의 인터넷 연결을 허용 - 라우터 등의 단일 디바이스를 인터넷(퍼블릭 네트워크)과 로컬 네트워크(프라이빗 네트워크) 간의 에이전트로 사용 가능 |
여러 가용영역에 VPC 배포하기:
https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/userguide/what-is-load-balancing.html
Load Balancer를 사용해서 여러 가용 영역에 VPC를 배포하면 데이터 보안을 유지하면서 트래픽을 분산하는 방식으로 고가용성이 보장됩니다.
가용 영역 하나의 작동이 중단되면 다른 가용 영역으로 장애 조치할 수 있습니다
Elastic Load Balancing에서 인바운드 트래픽을 수신한 후 두 가용영역의 프라이빗 서브넷에 있는 애플리케이션 서버로 라우팅합니다.
3. 네트워크 리소스 보호
네트워크 액세스 제어 목록(ALC)과 보안 그룹을 사용해 인바운드 및 아웃바운드 트래픽을 필터링하여 네트워크를 보호할 수 있습니다.
보안 그룹 및 네트워크 ACL 비교:
보안그룹 | 네트워크 ACL | |
구현 | 탄력적 네트워크 인터페이스에 연결 하이퍼바이저에서 구현 |
서브넷에 연결 네트워크에서 구현 |
운영 | 인스턴스 레벨에서 운영 | 서브넷 레벨에서 운영 |
지원 규칙 | 허용 규칙만 지원 | 허용 규칙 및 거부 규칙 지원 |
방화벽 | 상태 저장 방화벽 | 상태 비저장 방화벽 |
규칙 평가 | 트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가 | 트래픽 허용 여부를 절정할 때 모든 규칙을 순서대로 평가 |
적용 | 인스턴스와 연결된 경우 인스턴스에만 적용 | 연결된 서브넷에 배포된 모든 인스턴스에 적용 |
트래픽 허용 | 기본 VPC 보안그룹은 모든 트래픽을 허용 | 기본 VPC 네트워크 ACL은 모든 인바운드 및 아웃바운드 IPv4 트래픽을 허용 |
인바운드/ 아웃바운드 |
새 보안 그룹은 인바운드 규칙을 포함하지 않으며, 아웃바운드 트래픽을 허용 |
사용자 정의 네트워크 ACL은 규칙을 추가하기 전에는 모든 인바운드 및 아웃바운드 트래픽을 거부 |
상태 | 상태 저장: 규칙에 관계없이 반환 트래픽이 허용됨 | 상태 비저장: 반환 트래픽이 규칙에 따라 명시적으로 허용되어야 함 |
네트워크 ACL 규칙의 구성요소:
규칙 번호 | - 번호가 가장 낮은 항목부터 시작하여 차례로 평가 |
유형 | - Secure Shell(SSH) 등의 트래픽 유형 - 모든 트래픽이나 사용자 정의 범위를 지정 |
프로토콜 | - 표준 프로토콜 번호 지정 |
포트범위 | - 트래픽용 수신 대기 포트 또는 포트 범위 - 예: HTTP 트래픽에는 80 사용 |
소스 | - 트래픽의 소스(CIDR 범위) - 인바운드 규칙에만 적용 |
대상위치 | - 트래픽의 대상 위치(CIDR 범위) - 아웃바운드 규칙에만 적용 |
허용 또는 거부 | - 지정된 트래픽을 허용할지 아니면 거부할지를 결정 |
다중 방어 계층이 있는 인프라 설계:
1. 인터넷 게이트웨이와 라우팅 테이블로 인터넷에 노출되는 인스턴스를 제어
2. 보안 그룹과 네트워크 ACL을 정의하여 인터페이스 및 서브넷 수준에서 인프라를 추가로 보호
3. 운영체제 수준에서 방화벽으로 인스턴스를 보호
보안 그룹은 네트워크 ACL에 비해 더욱 다양하게 활용할 수 있습니다. 상태 저장 패킷 필터링을 수행할 수 있으며, 다른 보안 그룹을 참조하는 규칙을 사용할 수 있습니다.
네트워크 ACL은 특정 트래픽 하위 집합을 거부하거나 서브넷 용으로 대략적인 가드레일을 제어하는 등의 보조 제어기능으로 사용하면 효율적입니다.
네트워크 ACL과 보안 그룹을 모두 심층 방어수단으로 구현하면 이러한 컨트롤 중 한 가지를 잘못 구성하더라도 호스트가 예기치 못한 트래픽에 노출되지 않습니다.
4. AWS 서비스 연결을 프라이빗 상태로 유지하기
인터페이스 VPC 엔드포인트를 사용하면 AWS 서비스에 대한 연결을 프라이빗 상태로 유지할 수 있습니다.
그리고 게이트웨이 엔드포인트를 생성하면 인터넷 게이트웨이나 NAT 게이트웨이를 사용하지 않고도 VPC에서 Amazon S3 또는 DynamoDB로 연결할 수 있습니다.
VPC 엔드포인트:
VPC 엔드포인트를 사용하지 않으면 VPC는 인터넷 게이트웨이 및 NAT 게이트웨이 또는 퍼블릭 IP 주소가 있어야 VPC 외부에서 서버리스 서비스에 액세스할 수 있습니다.
VPC 엔드포인트는 VPC와 지원되는 AWS 서비스 간의 신뢰할 수 있는 경로를 제공합니다.
Gateway Endpoint | - 라우팅 테이블에 지정된 대상 - 고객이 지정하는 게이트웨이 - Amazon S3 및 DynamoDB로 전송되는 트래픽의 대상 - 추가요금 없음 |
Interface Endpoint | - 프라이빗 IP 주소를 사용하는 탄력적 네트워크 인터페이스 - 라우팅 테이블 변경 없이 트래픽이 새 엔드포인트로 전달 - AWS PrivateLink 기반 (인터페이스 엔드포인트를 구동하고, 트래픽이 퍼블릭 인터넷에 노출되지 않도록 해줌) |
5. VPC 간 트래픽을 프라이빗 방식으로 라우팅하는 방법
VPC 피어링을 사용하면 두 VPC를 빠르게 연결할 수 있습니다.
하지만 VPC 피어링은 크기를 조정하기가 어렵습니다.
여러 VPC 간에 트래픽을 라우팅하려는 경우에는 Transit Gateway를 사용하는 것이 좋습니다.
VPC 피어링 장단점:
장점 | 단점 |
인터넷 게이트웨이 또는 가상 프라이빗 게이트웨이 우회로 빠른 연결 |
VPC 당 사용할 수 있는 VPC 피어링 연결 수 제한 |
중복 연결으로 고가용성 연결 제공 | 전이적 피어링 관계는 지원되지 않음 (A-B, B-C 라도 A-C가 성립되지 않음) |
단일장애 지점 또는 대역폭 제한이 없음 (대역폭 병목현상 방지) |
MTU(최대 전송 단위)는 1,500바이트 |
프라이빗 IP 주소를 사용해 VPC 간 트래픽 전송 (DDoS 위협 감소) |
6. 온프레미스 네트워크를 AWS 클라우드에 연결하는 방법
사용 사례에 따라 AWS Site-to-Site VPN과 Direct Connect 중에서 비용과 성능을 최적화할 수 있는 솔루션을 선택하면 됩니다.
AWS Site-to-Site VPN:
AWS Site-to-Site VPN 연결에서는 VPN 터널 2개가 제공됩니다.
터널은 AWS 측의 가상 프라이빗 게이트웨이나 Transit Gateway와 온프레미스 측의 고객 게이트웨이를 연결합니다.
가상 프라이빗 게이트웨이는 AWS Site-to-Site VPN 연결의 AWS 측에 있는 VPN 집선기입니다.
• 한 VPN 연결의 VPN 터널이 서로 다른 가용 영역에서 종료됩니다.
고객 게이트웨이는 AWS에서 고객이 생성하는 리소스입니다.
온프레미스 네트워크의 고객 게이트웨이 디바이스를 나타냅니다.
고객 게이트웨이 장치의 기능에 따라 정적 라우팅 또는 동적 라우팅을 선택합니다.
동적 라우팅 옵션은 Border Gateway Protocol(BGP)을 사용하여 자동으로 경로를 검색합니다.
고객 게이트웨이 디바이스는 트래픽을 생성하고 IKE(Internet Key Exchange) 협상 프로세스를 시작하여 AWS Site-to-Site VPN 연결을 위한 터널을 표시해야 합니다.
고객 게이트웨이를 생성할 때 디바이스에 대한 정보를 AWS에 제공합니다.
AWS Direct Connect:
https://docs.aws.amazon.com/ko_kr/directconnect/latest/UserGuide/Welcome.html
AWS Direct Connect는 데이터 센터에서 AWS 리소스까지 광링크를 구축합니다.
케이블의 한쪽 끝은 사용자의 라우터에 연결되고 다른 쪽 끝은 Direct Connect 라우터에 연결됩니다.
이러한 방식을 교차 연결이라고 합니다.
이 연결을 구성하면 네트워크 경로에서 인터넷 서비스 공급자(ISP)를 우회하여 퍼블릭 AWS 서비스(예: Amazon S3) 또는 Amazon VPC에 직접 가상 인터페이스를 생성할 수 있습니다.
데이터 센터에서 교차 연결 생성 프로세스를 시작하려면 Letter of Authorization and Connecting Facility Assignment(LOA-CFA)가 필요합니다.
Site-to-Site VPN vs Direct Connect :
하이브리드 연결 요구를 가장 효율적으로 충족하는 제품을 선택해야 합니다.
사용 사례에 따라 Site-to-Site VPN이 나 Direct Connect 중 하나 또는 두 가지를 모두 선택할 수 있습니다.
특징:
Site-to-Site VPN | Direct Connect |
최대 연결 속도는 1.25Gbps로 제한됨 | 1Gbps 미만, 1/10/100Gbps 연결 옵션 |
Direct Connect보다 빠르게 구성 가능 | 특수 계약을 체결해야 하며 데이터 센터에 물리적 케이블을 연결해야 함 |
비활성 연결 요금은 지불할 필요가 없음 | 연결이 활성 상태인지에 관계없이 포트 시간 비용 지불 |
데이터가 전송 중에 기본적으로 암호화되지만 퍼블릭 인터넷을 통해 전송됨 |
데이터가 기본적으로 암호화되지 않지만 전용 프라이빗 연결이 사용됨 |
상황별 선택:
Site-to-Site VPN | Direct Connect |
온프레미스 네트워크와 VPC 간의 네트워크 연결을 빠르게 설정하는 방법이 필요한 경우 |
Site-to-Site VPN보다 빠른 연결 옵션이 필요한 경우 |
가용예산이 많지 않은 경우 | Direct Connect를 지원하는 공동 배치를 이미 사용 중인 경우 |
전송 데이터를 암호화해야 하는 경우 | 네트워크 성능을 예측할 수 있어야 하는 경우 |
7. 글로벌 네트워크에서 라우팅 테이블 수 줄이기
글로벌 네트워크의 여러 VPC에서 Transit Gateway 라우팅 테이블을 공유하고 관리할 수 있습니다.
해당하는 경우 새 VPC에 기존 라우팅 테이블을 연결하면 생성 및 관리해야 하는 라우팅 테이블 수를 줄일 수 있습니다.
AWS Transit Gateway:
AWS Transit Gateway는 연결된 네트워크 간에 트래픽이 라우팅 되는 방식을 제어하는 허브 역할을 합니다.
이 허브 및 스포크 모델은 다른 네트워크에 연결할 필요 없이 Transit Gateway에만 연결하면 되므로 관리를 크게 단순화하고 운영비용을 크게 줄여줍니다.
새로운 VPC를 Transit Gateway에 연결하면 연결된 다른 모든 네트워크에서 자동으로 해당 VPC를 사용할 수 있습니다.
Transit Gateway를 통한 라우팅은 3 계층에서 작동하며, 패킷은 대상 IP 주소에 따라 특정 다음 홉 연결로 전송됩니다.
Transit Gateway는 Transit Gateway 라우팅 테이블을 사용하여 연결 간에 IPv4 및 IPv6 패킷을 라우팅합니다.
연결된 VPC 및 VPN 연결에 대한 라우팅 테이블에서 라우팅을 전파하도록 테이블을 구성합니다.
Transit Gateway 라우팅 테이블에 정적 라우팅을 추가할 수 있습니다.
Transit Gateway는 VPC와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브로, 트래픽에 따라 탄력적으로 크기가 조정됩니다
Transit Gateway로 네트워크 크기 조정:
Transit Gateway는 클라우드 라우터 역할을 하므로 네트워크 아키텍처가 단순화됩니다.
네트워크 확장 시 증가하는 연결관리로 인한 복잡성이 발생하지 않습니다.
글로벌 애플리케이션을 구축하는 경우 리전간 피어링을 사용하여 Transit Gateway를 연결할 수 있습니다.
Transit Gateway Network Manager를 사용하면 중앙 콘솔에서 VPC 및 엣지 연결을 모니터링할 수 있습니다.
주요 SD-WAN 디바이스와 통합되므로, Transit Gateway Network Manager를 사용하여 글로벌 네트워크에서 문제를 식별할 수 있습니다.
VPC와 Transit Gateway 간의 트래픽은 AWS의 글로벌 프라이빗 네트워크에서 유지되며 퍼블릭 인터넷에 노출되지 않습니다.
Transit Gateway 리전간 피어링은 모든 트래픽을 암호화합니다.
단일 장애 발생 지점 또는 대역폭 병목 없이 DDoS 공격을 비롯한 일반적인 공격으로부터 보호해 줍니다.
Transit Gateway 구성 요소:
Transit Gateway의 중요한 두 가지 구성 요소는 연결과 라우팅 테이블입니다.
연결(Attachment)은 패킷의 원본이자 대상입니다.
다음 리소스 중 하나 이상이 Transit Gateway와 동일한 리전에 있을 경우 연결할 수 있습니다:
- VPC
- VPN 연결
- Direct Connect 게이트웨이
- Transit Gateway Connect
- Transit Gateway 피어링 연결
VPC 연결 + Direct Connect 게이트웨이 + transit Gateway:
VPN 연결과 Direct Connect 게이트웨이를 사용하여 온프레미스 데이터 센터를 Transit Gateway에 연결할 수 있습니다. Transit Gateway를 사용하면 AWS 클라우드 내 VPC에 연결할 수 있으며, 그러면 하이브리드 네트워크가 생성됩니다.
Transit Gateway에는 기본 라우팅 테이블이 있으며, 다른 라우팅 테이블도 선택적으로 포함할 수 있습니다.
라우팅 테이블에는 패킷의 대상 IP 주소에 따라 다음에 홉을 결정하는 동적 및 정적 경로가 포함되어 있습니다.
이러한 경로의 대상은 모든 Transit Gateway Attachment 일 수 있습니다.
기본적으로 Transit Gateway Attachment는 기본 Transit Gateway 라우팅 테이블과 연결됩니다.
각 연결(Attachment)은 정확히 하나의 라우팅 테이블과 연결(Attachment)됩니다.
각 라우팅 테이블은 0개 이상의 Attachment와 연결될 수 있습니다.
Transit Gateway 설정:
Transit Gateway는 여러 AWS 계정에서 작동합니다.
AWS Resource Access Manager를 사용하여 Transit Gateway를 다른 계정과 공유할 수 있습니다.
Transit Gateway를 다른 AWS 계정과 공유하면 계정 소유자는 자신의 VPC를 Transit Gateway에 연결할 수 있습니다.
두 계정의 사용자는 언제든지 연결을 삭제할 수 있습니다.
Transit Gateway 연결은 패킷의 원본이자 대상입니다.
다음 리소스를 Transit Gateway에 연결할 수 있습니다.
- 하나 이상의 VPC
- 하나 이상의 VPN 연결
- 하나 이상의 Direct Connect 게이트웨이
- 하나 이상의 Transit Gateway 피어링 연결
Transit Gateway 피어링 연결을 연결하는 경우 Transit Gateway는 다른 리전에 있어야 합니다.
Transit Gateway는 연결된 VPC와 VPN 연결 간의 동적 및 정적 라우팅을 지원합니다.
각 연결에 대해 경로 전파를 설정 또는 해제할 수 있습니다.
- 전체 연결(모든 VPC가 서로 통신)
- 부분 연결(일부 VPC만 서로 통신)
- VPN에는 액세스를 유지하면서 VPC간 격리(VPC끼리 서로 통신할 수 없지만 VPN 연결을 통해 엑세스는 가능)
Architecting on AWS 7.4.6 (KO): Student Guide 참고
'AWS > AWS Architecting' 카테고리의 다른 글
[AWS Architecting]데이터베이스 (0) | 2023.07.01 |
---|---|
[AWS Architecting]스토리지 (0) | 2023.07.01 |
[AWS Architecting]컴퓨팅 (0) | 2023.06.29 |
[AWS Architecting]계정 보안 (0) | 2023.06.28 |
[AWS Architecting]아키텍팅 기본 사항 (0) | 2023.06.28 |