Amazon Virtual Private Cloud

khm_studylog·2023년 1월 6일
0

cloud

목록 보기
9/14

VPN(Virtual Private Network)

큰 규모의 조직이 여러 곳에 분산되어 있는 컴퓨터들을 연결하는 보안성이 높은 사설 네트워크를 만들거나, 인터넷을 활용하여 원격지 간에 네트워크를 서로 연결하고 암호화 기술을 적용하여 보다 안정적이며, 보안성 높은 통신 서비스를 제공하는 서비스

AWS는 VPC와 VPC Gateway를 통해 On-Premise의 VPN장비와 AWS 간의 VPN을 연결할 수 있으며, 이를 통해 보안성 높은 하이브리드 클라우드 환경을 구현하여, 원활한 클라우드 컴퓨팅 서비스를 지원할 수 있습니다.

VPC(Virtual Private Cloud)

Amazon VPC (클라우드 환경에서의 VPN)

AWS 클라우드에서 논리적으로 격리된 네트워크 공간을 할당하여 가상 네트워크에서 AWS 리소스를 이용할 수 있는 서비스를 제공한다.

자체 IP 주소 범위, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 선택 등 가상 네트워킹 환경을 완벽하게 제어할 수 있으며, VPC에서 IPv4와 IPv6를 모두 사용하여 리소스와 애플리케이션에 안전하고 쉽게 액세스 할 수 있다.

주요 특징

  • AWS에 사설 네트워크 구축
  • 회사의 AWS 간 VPN을 연결하거나 가상 네트워킹 구현
  • 기존 데이터센터와의 연결을 통해 하이브리드 환경 구성
  • AWS를 회사 인프라의 일부처럼 사용할 수 있으며, 내부 시스템 소프트웨어의 연동이 매우 쉬움
    (메일, 그룹웨어같은 업무 시스템, 파일 서버)
  • 세심한 네트워크 설정 가능
  • 모든 Region에서 이용 가능
  • 프리티어 가능
    (VPC 자체는 비용이 발생하지 않지만, VPN 연결 시 네트워크 송/수신에 따른 종량제 비용 발생)

VPC의 구성 요소

1. Private IP

인터넷을 통해 연결할 수 없는, VPC 내부에서만 사용할 수 있는 IP주소

Private IP는 VPC에서 시작된 인스턴스 서브넷의 범위에서 자동으로 할당되며, 동일 네트워크에서 인스턴스 간 통신에 사용할 수 있다.

2. Public IP

인터넷을 통해 연결할 수 있는 IP주소로, 인스턴스와 인터넷 간의 통신을 위해 사용할 수 있다.

EC2 생성 시 옵션으로 Public IP주소의 사용 여부를 선택할 수 있으며, 인스턴스에서 Public IP주소를 수동으로 연결하거나 해제할 수 없다.
인스턴스가 재부팅되면 새로운 새로운 Public IP주소가 할당된다.

3. Elastic IP(탄성 IP주소)

동적 컴퓨팅을 위해 고안된 고정 퍼블릭 IP주소이다.

VPC의 모든 인스턴스와 네트워크 인터페이스에 탄성 IP를 할당할 수 있으며, 다른 인스턴스에 주소를 신속하게 다시 매칭하여 인스턴스 장애 조치를 수행할 수 있다.

VPC & Subnet

VPC는 사용자 AWS 계정을 위한 전용의 가상 네트워크

VPC 내부의 네트워크에서도 서비스 목적에 따라 IP Block으로 나누어 구분할 수 있다. 이렇게 분리된 IP Block의 모음을 Subnet이라 한다.

VPC는 Region의 모든 가용 영역에 적용되며, 각 가용 영역에 하나 이상의 서브넷을 추가할 수 있다. 하지만 서브넷은 단일 가용 영역에서만 생성할 수 있으며, 여러 가용 영역으로 확장할 수 없다.

VPC와 Subnet의 사이즈

VPC를 생성할 때 VPC에서 사용하게 될 IP주소의 범위(예: 10.0.0.0/16)를 지정하게 되는데 범위를 CIDR 블록 형태로 지정해야 한다.

VPC를 생성하는 경우 10.0.0.0/24로 VPC를 생성하게 되면 256개의 IP주소를 지원하게 되며, CIDR 블록을 각각 128개의 IP주소를 지원하는 2개의 서브넷으로 나눌 수 있다.

한 서브넷은 10.0.0.0 ~ 10.0.0.127
다른 서브넷은 10.0.0.128 ~ 10.0.0.255

Public Subnet, Private Subnet

인터넷망을 통해 서비스를 수행하는 웹서버는 퍼블릭 서브넷에 생성하며, 인터넷에 직접적으로 연결할 필요가 없고 보안성을 필요로 하는 DB서버는 프라이빗 서브넷에 생성한다.

Routing Table

각 서브넷은 서브넷 외부로 나가는 Outbound 트래픽에 대해 허용된 경로를 지정하는 라우팅 테이블이 연결되어 있어야 한다.

생성된 서브넷은 자동으로 VPC의 기본 라우팅 테이블과 연결되며, 테이블의 내용을 변경할 수 있다.

이러한 라우팅 테이블은 VPC의 서브넷 내에서 생성된 네트워크 패킷이 목적지 주소로 이동하기 위해 어떤 경로로 이동되어야 하는지를 알려준다.

그래서 서브넷 간의 통신이나 VPC 간의 원활한 통신을 위해 라우팅 테이블을 이용한다.

VPC의 주요 서비스

보안 그룹(security group)과 네트워크 액세스 제어 목록(Network ACL)

VPC는 네트워크 통신과 트래픽에 대해 IP와 Port를 기준으로 통신을 허용하거나 차단하기 위한 기능을 제공한다.

이러한 서비스를 보안 그룹과 네트워크 ACL이라 한다.

보안 그룹네트워크 ACL
서비스 범위인스턴스 레벨에 적용서브넷 레벨에 적용
적용 정책Allow 규칙만 적용Allow, Deny 규칙 적용
구동 방식규칙에 상관없이 반환 트래픽 허용반환 트래픽이 별도로 허용되어야 함
룰 검토/적용해당 객체 내 모든 룰 검토해당 객체 내 룰을 번호 순으로 처리
적용 방법인스턴스에 보안 그룹 추가 필요연결된 서브넷에 모든 인스턴스 자동 적용됨

VPC Peering 연결

피어링 연결은 비공개적으로 두 VPC 간에 트래픽을 라우팅할 수 있게 하기 위한 서로 다른 VPC 간의 네트워크 연결을 제공한다. VPC Peering을 통해 동일한 네트워크에 속한 것과 같이 서로 다른 VPC의 인스턴스 간에 통신이 가능하다.

NAT 게이트웨이

외부 네트워크에 알려진 것과 다른 IP주소를 사용하는 내부 네트워크에서 내부 IP주소를 외부 IP주소로 변환하는 작업을 수행하는 서비스

NAT 게이트웨이는 Private Subnet 내에 있는 인스턴스를 인터넷 또는 다른 AWS 서비스에 연결하고, 외부망 또는 인터넷에서 해당 인스턴스에 연결하지 못하도록 구성하는 데 사용한다.

외부에 공개될 필요가 없거나, 보안상 중요한 서비스이지만 패나 보안 업데이트, 소프트웨어 업데이트를 인터넷을 통해 받아야 하는 경우 NAT 게이트웨이나 NAT 인스턴스를 사용하게 된다.

NAT 게이트웨이 구성 조건

  1. NAT 게이트웨이 생성을 위한 퍼블릭 서브넷을 지정
  2. NAT 게이트웨이와 연결할 탄력적 IP 주소 필요
  3. NAT 게이트웨이를 만든 후 인터넷 트래픽이 NAT 게이트웨이로 통신이 가능하도록 프라이빗 서브넷과 연결된 라우팅 테이블 업데이트

VPC Endpoint

Amazon S3는 인터넷망에 연결된 서비스로 인터넷 기반의 IP주소와 연결 정보를 가지고 있다. 이러한 공용 리소스에 대해 퍼블릿 서브넷에 위치한 인스턴스는 인터넷을 통해 문제 없이 연결 가능하다.

하지만 프라이빗 서브넷에 위치한 인스턴스는 인터넷과 연결되어 있는 S3와 같은 공용 리소스를 연결할 수 없다. 이러한 경우 S3에 연결하기 위해서는 NAT 게이트웨이나 NAT 인스턴스가 필요하다.

VPC Endpoint를 이용하면 빠르고 손쉽게 S3, DynamoDB에 연결할 수 있다.

VPN 연결

Amazon VPC에서 서비스되는 인스턴스는 온프레미스에 있는 서버나 IDC 내의 시스템과 통신할 수 없다. 인터넷을 통해 강제로 통신하도록 구성할 수 있으나, 보안을 필요로 하는 중요 데이터를 송수신하기에는 보안적으로 매우 취약하다.

AWS VPC 내 인스턴스와 IDC 내 시스템 간 데이터 통신을 위해 VPC에 가상의 프라이빗 게이트웨이를 연결하고 사용자 지정 라우팅 테이블을 생성하며, 보안 그룹의 규칙을 업데이트하고, AWS 관리형 VPN 연결을 생성하여 VPC에서 원격의 네트워크에 접속 가능하도록 하이브리드 클라우드 환경을 구성할 수 있다. VPN 연결은 VPC와 자체 네트워크 사이의 연결을 의미한다.


실습 1. VPC 마법사를 통해 퍼블릭 서브넷과 프라이빗 서브넷 만들기

NAT 게이트웨이에 사용할 탄력적 IP 주소를 제공 받는다.

VPC 생성

아래와 같이 tutorial-vpc 가 정상적으로 생성되었음을 확인 가능하다.

실습 2. 리전 간 VPC Peering으로 글로벌 통합 네트워크 환경 구축하기

London 리전에서 VPC 마법사를 시작한다. > single public sunbet이 있는 VPC를 생성한다.

vpc 항목에서 정상적으로 생성되어 available 한 status를 확인할 수 있다.

이제 피어링 연결을 해보자(다른 리전간의 피어링 생성을 하여, 동일한 네트워크에 속한 것과 같이 서로 다른 VPC간의 인스턴스 끼리 통신을 하게끔 하는 액션을 해볼 것이다)

우선, 다시 서울리전으로 돌아가서 VPC section으로 넘어가서,
피어링 연결 생성을 아래의 옵션들과 같이 동일하게 구성해서 진행하자.


vpc 연결이 정상적으로 생성되고, 이후 피어링 연결 승인을 위해 런던 리전으로 이동한다.
요청 수락을 한다.

런던 리전의 라우팅 테이블 페이지에 들어가서, 바로 전에 생성된 라우팅 테이블을 다음의 옵션과 같이 편집한다.
(10.0.0.0/16 이라는 서울의 vpc 대역을 입력해준다.)

이번에는 반대로, 서울 리전의 라우팅 테이블 페이지에 들어가서, 바로 전에 생성된 라우팅테이블을 다음의 옵션과 같이 편집해준다. (런던 리전의 vpc 대역인 20.0.0.0/16 을 입력하고, peering connection 을 선택)

런던 리전 EC2 생성, 서울 리전 EC2 생성 후 맥 터미널 2개 켜서 접속한다.
EC2 인스턴스 생성 시 키페어는 각각 다른 것으로 생성해야 하고 VPC 선택할 때는 디폴트 말고 생성했던 vpc 선택해야 한다. 서브넷 선택할 때에도 public 으로 선택하고, 퍼블릭 IP 자동 할당 항목은 비활성화가 아닌 활성화로 선택해 주었다.

서울 리전 EC2 인스턴스 접속

$ ssh -i "KeyName1.pem" ec2-user@ec2-13-209-12-40.ap-northeast-2.compute.amazonaws.com
The authenticity of host 'ec2-13-209-12-40.ap-northeast-2.compute.amazonaws.com (13.209.12.40)' can't be established.
ED25519 key fingerprint is SHA256:03cDP4PbhWNbLXDbZm57d7B6myW9LhYUkAc6cNOOQKc.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ec2-13-209-12-40.ap-northeast-2.compute.amazonaws.com' (ED25519) to the list of known hosts.

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-10-0-0-155 ~]$ 

런던 리전 EC2 인스턴스 접속

$ ssh -i "KeyName2.pem" ec2-user@ec2-52-56-192-222.eu-west-2.compute.amazonaws.com
The authenticity of host 'ec2-52-56-192-222.eu-west-2.compute.amazonaws.com (52.56.192.222)' can't be established.
ED25519 key fingerprint is SHA256:SIL4TSL3fGWQaVQPr/YmBbTBxFqCskwiKEueyJC7y/M.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ec2-52-56-192-222.eu-west-2.compute.amazonaws.com' (ED25519) to the list of known hosts.

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-20-0-0-199 ~]$ 

현재는 둘 사이에 ping을 날려보면 서로 응답이 오지 않습니다.

해결 방법
서울 리전 인스턴스, 런던 리전 인스턴스 양쪽의 EC2 > 보안 그룹에서 ICMP 인바운드 규칙을 아래와 같이 추가해줍니다.

서울 인바운드 규칙
런던 인바운드 규칙

결과 화면

서울 리전의 인스턴스에 접속 후 런던 리전에 생성된 인스턴스의 Private IP로 Ping 명령어를 실행하여, 정상적으로 통신이 가능함을 확인하였다.

런던 리전의 인스턴스에 접속 후 서울 리전에 생성된 인스턴스의 Private IP로 Ping 명령어를 실행하여, 정상적으로 통신이 가능함을 확인하였다.


참고 : 참고한 블로그

0개의 댓글