AWS에 연결
Amazon 가상 프라이빗 클라우드(Amazon VPC)
AWS 서비스를 사용하는 수백만 명의 고객을 상상해 보세요. 또한 이러한 고객이 Amazon EC2 인스턴스와 같이 생성한 수백만 개의 리소스를 상상해 보세요. 이러한 모든 리소스에 경계가 없다면 네트워크 트래픽이 리소스 간에 제한 없이 이동할 수 있을 것입니다.
AWS 리소스에 경계를 설정하는 데 사용할 수 있는 네트워킹 서비스는Amazon 가상 프라이빗 클라우드(Amazon VPC)입니다.
Amazon VPC를 사용하면 AWS 클라우드의 격리된 섹션을 프로비저닝할 수 있습니다. 이 격리된 섹션에서는 정의한 가상 네트워크에서 리소스를 시작할 수 있습니다. 가상 프라이빗 클라우드(VPC) 내에서 리소스를 서브넷으로 구성할 수 있습니다.서브넷은 Amazon EC2 인스턴스와 같은 리소스를 포함할 수 있는 VPC의 섹션입니다.
인터넷 게이트웨이
인터넷의 공용 트래픽이 VPC에 액세스할 수 있도록 하려면인터넷 게이트웨이를 VPC에 연결합니다.
인터넷 게이트웨이는 VPC와 인터넷 간의 연결입니다. 인터넷 게이트웨이는 고객이 커피숍에 들어올 때 사용하는 출입구와 비슷하다고 생각하면 됩니다. 인터넷 게이트웨이가 없으면 아무도 VPC 내의 리소스에 액세스할 수 없습니다.
프라이빗 리소스만 포함된 VPC가 있다면 어떨까요?
가상 사설 게이트웨이
다음은 가상 사설 게이트웨이의 작동 방식에 대한 예시입니다. 인터넷을 집과 커피숍 사이의 도로라고 생각하면 됩니다. 여러분을 보호하기 위해 경호원과 함께 이 도로를 여행하고 있다고 가정해 봅시다. 여전히 다른 고객과 같은 도로를 이용하지만 추가 보호 계층이 있습니다.
보디가드는 주변의 다른 모든 요청으로부터 인터넷 트래픽을 암호화(또는 보호)하는 가상 사설망(VPN) 연결과 같습니다.
가상 사설 게이트웨이는 보호된 인터넷 트래픽이 VPC로 들어갈 수 있도록 하는 구성 요소입니다. 커피숍에 대한 연결이 추가적으로 보호되더라도 다른 고객과 같은 도로를 사용하기 때문에 트래픽 정체가 발생할 수 있습니다.
가상 사설 게이트웨이를 사용하면 VPC와 온프레미스 데이터 센터 또는 기업 내부 네트워크와 같은 사설 네트워크 간에 가상 사설망(VPN) 연결을 설정할 수 있습니다. 가상 사설 게이트웨이는 트래픽이 승인된 네트워크에서 오는 경우에만 VPC로 트래픽을 허용합니다.
AWS 다이렉트 커넥트
AWS 다이렉트 커넥트는 데이터 센터와 VPC 간에 전용 프라이빗 연결을 설정할 수 있는 서비스입니다.
건물과 커피숍을 직접 연결하는 복도가 있는 아파트 건물이 있다고 가정해 보겠습니다. 아파트 거주자만 이 복도를 통과할 수 있습니다.
이 전용 복도는 AWS 다이렉트 커넥트와 동일한 유형의 전용 연결을 제공합니다. 주민들은 다른 고객과 공유하는 공용 도로를 이용할 필요 없이 커피숍에 들어갈 수 있습니다.
AWS 다이렉트 커넥트가 제공하는 전용 연결은 네트워크 비용을 절감하고 네트워크를 통해 이동할 수 있는 대역폭의 양을 늘리는 데 도움이 됩니다.
서브넷 및 네트워크 액세스 제어 목록
VPC 내에서 서브넷의 역할에 대해 자세히 알아보려면 다음 커피숍의 예를 검토하세요.
먼저 고객이 계산원에게 주문을 전달합니다. 그러면 계산원이 바리스타에게 주문을 전달합니다. 이 프로세스를 통해 더 많은 고객이 들어와도 줄을 원활하게 운영할 수 있습니다.
일부 고객이 계산대 줄을 건너뛰고 바리스타에게 직접 주문을 하려고 한다고 가정해 보겠습니다. 이로 인해 트래픽 흐름이 중단되고 고객이 커피숍의 제한된 부분만 이용할 수 있게 됩니다.
이 문제를 해결하기 위해 커피숍 주인은 계산원과 바리스타를 별도의 워크스테이션에 배치하여 카운터 공간을 나눕니다. 계산원의 워크스테이션은 공개적으로 고객을 맞이하도록 설계되었습니다. 바리스타의 영역은 개인 공간입니다. 바리스타는 여전히 계산원으로부터 주문을 받을 수 있지만 고객으로부터 직접 주문을 받을 수는 없습니다.
이는 AWS 네트워킹 서비스를 사용하여 리소스를 분리하고 네트워크 트래픽의 흐름을 정확하게 결정하는 방법과 유사합니다.
커피숍에서는 카운터 영역을 VPC로 생각할 수 있습니다. 카운터 영역은 계산원의 워크스테이션과 바리스타의 워크스테이션을 위한 두 개의 별도 영역으로 나뉩니다. VPC에서서브넷은 리소스를 함께 그룹화하는 데 사용되는 별도의 영역입니다.
서브넷
서브넷은 보안 또는 운영상의 필요에 따라 리소스를 그룹화할 수 있는 VPC의 섹션입니다. 서브넷은 공용 또는 비공개일 수 있습니다.
공용 서브넷에는 온라인 스토어 웹사이트와 같이 일반인이 액세스할 수 있어야 하는 리소스가 포함됩니다.
비공개 서브넷에는 고객의 개인 정보 및 주문 내역이 포함된 데이터베이스와 같이 비공개 네트워크를 통해서만 액세스해야 하는 리소스가 포함됩니다.
VPC에서 서브넷은 서로 통신할 수 있습니다. 예를 들어 공용 서브넷에 있는 Amazon EC2 인스턴스가 사설 서브넷에 있는 데이터베이스와 통신하는 애플리케이션이 있을 수 있습니다.
VPC의 네트워크 트래픽
고객이 AWS 클라우드에서 호스팅되는 애플리케이션에서 데이터를 요청하면 이 요청은 패킷으로 전송됩니다.패킷은 인터넷이나 네트워크를 통해 전송되는 데이터의 단위입니다.
패킷은 인터넷 게이트웨이를 통해 VPC로 들어갑니다. 패킷이 서브넷으로 들어가거나 서브넷에서 나가기 전에 패킷은 권한을 확인합니다. 이러한 권한은 패킷을 보낸 사람과 패킷이 서브넷의 리소스와 통신하려는 방법을 나타냅니다.
서브넷에 대한 패킷 권한을 확인하는 VPC 구성 요소는네트워크 액세스 제어 목록(ACL)입니다.
네트워크 액세스 제어 목록(ACL)
네트워크 액세스 제어 목록(ACL)은 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽입니다.
예를 들어 커피숍 밖으로 나와 공항에 있다고 상상해 보세요. 공항에서는 여행자들이 다른 나라로 입국하려고 합니다. 여행자를 패킷으로, 여권 심사관을 네트워크 ACL로 생각할 수 있습니다. 여권 심사관은 여행자가 입국할 때와 출국할 때 모두 여행자의 자격 증명을 확인합니다. 여행자가 승인된 목록에 있는 경우 통과할 수 있습니다. 그러나 승인된 목록에 없거나 명시적으로 금지된 여행자 목록에 있는 경우, 해당 여행자는 입국할 수 없습니다.
각 AWS 계정에는 기본 네트워크 ACL이 포함되어 있습니다. VPC를 구성할 때 계정의 기본 네트워크 ACL을 사용하거나 사용자 지정 네트워크 ACL을 만들 수 있습니다.
기본적으로 계정의 기본 네트워크 ACL은 모든 인바운드 및 아웃바운드 트래픽을 허용하지만 자체 규칙을 추가하여 수정할 수 있습니다. 사용자 지정 네트워크 ACL의 경우 허용할 트래픽을 지정하는 규칙을 추가하기 전까지는 모든 인바운드 및 아웃바운드 트래픽이 거부됩니다. 또한 모든 네트워크 ACL에는 명시적 거부 규칙이 있습니다. 이 규칙은 패킷이 목록의 다른 규칙과 일치하지 않는 경우 패킷이 거부되도록 합니다.
상태 비저장 패킷 필터링
네트워크 ACL은상태 비저장 패킷 필터링을 수행합니다. 아무것도 기억하지 않고 서브넷 경계를 통과하는 패킷을 인바운드와 아웃바운드 양방향으로 확인합니다.
다른 나라로 입국하려는 여행자의 이전 예를 떠올려 보세요. 이는 Amazon EC2 인스턴스에서 인터넷으로 요청을 보내는 것과 유사합니다.
해당 요청에 대한 패킷 응답이 서브넷으로 돌아올 때 네트워크 ACL은 이전 요청을 기억하지 못합니다. 네트워크 ACL은 패킷 응답을 규칙 목록과 대조하여 허용 또는 거부 여부를 결정합니다.
패킷이 서브넷에 들어온 후에는 Amazon EC2 인스턴스와 같은 서브넷 내의 리소스에 대한 권한을 평가해야 합니다.
Amazon EC2 인스턴스에 대한 패킷 권한을 확인하는 VPC 구성 요소는보안 그룹입니다.
보안 그룹
보안 그룹은 Amazon EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽입니다.
기본적으로 보안 그룹은 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽을 허용합니다. 사용자 지정 규칙을 추가하여 허용하거나 거부할 트래픽을 구성할 수 있습니다.
이 예제에서는 로비에서 손님을 맞이하는 도어 어텐던트가 있는 아파트 건물에 있다고 가정합니다. 손님을 패킷으로, 도어 어텐던트를 보안 그룹으로 생각할 수 있습니다. 손님이 도착하면 도어 어텐던트는 명단을 확인하여 건물에 들어갈 수 있는지 확인합니다. 그러나 도어 어텐던트는 게스트가 건물에서 나갈 때 목록을 다시 확인하지 않습니다
서브넷 내에 여러 Amazon EC2 인스턴스가 있는 경우, 동일한 보안 그룹에 연결하거나 각 인스턴스에 대해 다른 보안 그룹을 사용할 수 있습니다.
스테이트풀 패킷 필터링
보안 그룹은상태 저장 패킷 필터링을 수행합니다. 보안 그룹은 들어오는 패킷에 대해 이전에 내린 결정을 기억합니다.
Amazon EC2 인스턴스에서 인터넷으로 요청을 보내는 동일한 예를 생각해 보겠습니다.
해당 요청에 대한 패킷 응답이 인스턴스로 돌아오면 보안 그룹은 이전 요청을 기억합니다. 보안 그룹은 인바운드 보안 그룹 규칙에 관계없이 응답을 계속 진행하도록 허용합니다.
네트워크 ACL과 보안 그룹을 모두 사용하면 VPC의 트래픽에 대한 사용자 지정 규칙을 구성할 수 있습니다. AWS 보안 및 네트워킹에 대해 계속 알아가면서 네트워크 ACL과 보안 그룹의 차이점을 이해해야 합니다
글로벌 네트워킹
도메인 이름 시스템(DNS)
애니컴퍼니에 AWS 클라우드에서 호스팅되는 웹사이트가 있다고 가정해 보겠습니다. 고객이 브라우저에 웹 주소를 입력하면 웹사이트에 액세스할 수 있습니다. 이는도메인 이름 시스템(DNS) 확인으로 인해 발생합니다. DNS 확인에는 DNS 서버가 웹 서버와 통신하는 것이 포함됩니다.
DNS는 인터넷의 전화번호부라고 생각하면 됩니다. DNS 확인은 도메인 이름을 IP 주소로 변환하는 프로세스입니다.
예를 들어 애니컴퍼니의 웹사이트를 방문한다고 가정해 보겠습니다.
- 브라우저에 도메인 이름을 입력하면 이 요청이 DNS 서버로 전송됩니다.
- DNS 서버는 웹 서버에 애니컴퍼니 웹사이트에 해당하는 IP 주소를 요청합니다.
- 웹 서버는 애니컴퍼니 웹사이트의 IP 주소인 192.0.2.0을 제공함으로써 응답합니다.
Amazon Route 53
Amazon Route 53은 DNS 웹 서비스입니다. 이 서비스는 개발자와 기업이 최종 사용자를 AWS에서 호스팅되는 인터넷 애플리케이션으로 라우팅할 수 있는 안정적인 방법을 제공합니다.
Amazon Route 53은 사용자 요청을 AWS에서 실행되는 인프라(예: Amazon EC2 인스턴스 및 로드 밸런서)에 연결합니다. 사용자를 AWS 외부의 인프라로 라우팅할 수도 있습니다.
Route 53의 또 다른 기능은 도메인 이름에 대한 DNS 레코드를 관리하는 기능입니다. Route 53에서 직접 새 도메인 네임을 등록할 수 있습니다. 다른 도메인 등록기관에서 관리하는 기존 도메인 네임에 대한 DNS 레코드를 이전할 수도 있습니다. 이를 통해 단일 위치에서 모든 도메인 네임을 관리할 수 있습니다.
이전 모듈에서는 콘텐츠 전송 서비스인 Amazon CloudFront에 대해 배웠습니다. 다음 예에서는 고객에게 콘텐츠를 전달하기 위해 Route 53과 Amazon CloudFront가 함께 작동하는 방법을 설명합니다.
예제: Amazon Route 53과 Amazon CloudFront가 콘텐츠를 전달하는 방법
AnyCompany의 애플리케이션이 여러 Amazon EC2 인스턴스에서 실행되고 있다고 가정합니다. 이러한 인스턴스는 애플리케이션 로드 밸런서에 연결되는 자동 확장 그룹에 있습니다.
- 고객이 AnyCompany의 웹사이트로 이동하여 애플리케이션에서 데이터를 요청합니다.
- Amazon Route 53은 DNS 확인을 사용하여 AnyCompany.com의 해당 IP 주소인 192.0.2.0을 식별합니다. 이 정보는 고객에게 다시 전송됩니다.
- 고객의 요청은 Amazon CloudFront를 통해 가장 가까운 엣지 위치로 전송됩니다.
- Amazon CloudFront는 애플리케이션 로드 밸런서에 연결하여 들어오는 패킷을 Amazon EC2 인스턴스로 보냅니다.
리소스
'CS > 시험 공부' 카테고리의 다른 글
AWS CLF-02 #6 상세 정리 (3) | 2025.08.12 |
---|---|
AWS CLF-02 #5 상세 정리 (3) | 2025.08.11 |
AWS CLF-02 #3 상세 정리 (0) | 2025.08.11 |
AWS CLF-02 #2 상세 정리 (3) | 2025.08.10 |
AWS CLF-02 #1 상세 정리 (3) | 2025.08.10 |