Today Keys : VPC, AWS, Endpoint, Gateway, Interface, services, cloud, 아마존, public


이번 포스팅은 지난 포스팅에 이어서 VPC Endpoint에 대해서 알아봅니다.

VPC Endpoint 중에서 Interface 타입의 Endpoint를 생성해서 어떻게 Endpoint를 이용해서

서비스를 접근 할 수 있는지를 알아 볼 수 있는 간단한 예제 포스팅입니다.

* 관련 포스팅 : VPC Endpoint 알아보기

                        Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 


이번 포스팅에서는 Interface 타입의 Endpoint인 CloudFormation을 생성해 보겠습니다.

먼저 Endpoint를 생성하기 위해서 '엔드포인트 생성' 메뉴를 선택하여 Endpoint를 만드는 메뉴로 들어갑니다.

 

EndPoint를 만들 때에는 서비스 유형에 따라서 Interface로 만들지 Gateway로 만들지 다음과 같이 나옵니다.

각 서비스 별로 유형이 정해져 있는 것이며, 서비스를 Interface 혹은 Gateway 유형을 선택하는 것은 아닙니다.

 

Endpoint 생성의 전체 메뉴는 다음과 같습니다.

서비스를 고르고, 어느 VPC에 적용할지를 선택하면 해당 VPC의 AZ 정보가 나오고

각 AZ 별로 어떤 Subnet에 생성할지 나옵니다.

그리고 'Private DNS 이름 활성화' 라는 메뉴가 기본적으로 체크되어 있습니다.

이 부분은 아래에서 다시 설명합니다.

보안 그룹은 우선 기본으로 설정합니다.

 

여기까지하면, 손쉽게 Endpoint를 만들 수 있습니다.

 

생성이후, '사용가능' 상태로는 약 1~2분정도 소요 될 수 있습니다.

정상적으로 생성되면 다음과 같이 생성된 Endpoint 정보를 확인 할 수 있습니다.

 

하단의 서브넷 탭을 보면 실제 생성 시에 선택한 AZ 별로 서브넷에 속하는 IP 주소를 갖고 있는 것을 확인 할 수 있습니다.

 

Endpoint를 생성하기 전에는 해당 VPC 내에서 CloudFormation 서비스에 대한 URL을 확인하면

AWS의 리전 내의 공인 IP 주소를 받아오는 것을 확인 할 수 있습니다.

 

하지만, Endpoint 생성 이후에 동일한 URL에 대한 질의를 하면 Endpoint가 갖고 있는 IP 주소를

도메인에 질의에 대한 결과로 받게 되는 것을 확인 할 수 있습니다.

앞에서  'Private DNS 이름 활성화' 을 뒤에서 알아보겠다고 하였는 데, Endpoint 생성 시에

'Private DNS 이름 활성화' 옵션을 활성화하면(default 값이 활성화) 서비스 별 기본 도메인 값을 VPC 내의 Private DNS에

자동으로 등록이 되어서 해당 값을 응답 받을 수 있게 됩니다.

일반 URL이 아닌 별도 URL을 사용하여 접근하고자 할 경우에는 해당 옵션에 대한 체크를 해제하고

별도 도메인으로 Endpoint IP 주소를 관리 할 수도 있습니다.

 

 

Posted by 네떡지기

Today Keys : VPC, AWS, Endpoint, Gateway, Interface, Private, links, services, cloud, 아마존, public


 

 이번 포스팅은 VPC 네트워크에서 AWS 서비스를 AWS 네트워크를 통해서 직접 접근하기 위한 Endpoint에 대해서 알아보는 포스팅입니다. Endpoint는 접근하는 서비스에 따라서 Gateway와 Interface 타입으로 나뉩니다. 이번 포스팅에서는 Endpoint에 대한 간략한 소개를 하고, 다음 포스팅에서는 Endpoint를 생성해서 접근하는 방법에 대해서 알아 볼 예정입니다.

* 관련 포스팅 : Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 Interface Endpoint 만들어보기


 VPC Endpoints

Endpoints

  ▪ VPC 네트워크 내에서 VPC 외부에 위치한 Public한 서비스를 IGW를 거치지 않고 VPC내부에서 직접 접근하도록 지원
  ▪ VPC의 내부의 인스턴스가 AWS 서비스와 통신하기 위해 공인 IP를 가지지 않아도 됨.
  ▪ Endpoint는 Gateway 타입 Interface 타입 으로 구분
  ▪ Endpoint는 VPC에서 접근하고자 하는 AWS Public 서비스 별로 개별 생성하며, Gateway타입 지원하는 서비스와
    인터페이스 타입을 지원하는 서비스가 나누어져 있음. 
       - 타입 별 지원 서비시는 아래에 참고
  ▪ VPC와 AWS 서비스 사이의 트래픽이 AWS 네트워크에서 처리하며, IAM 정책을 사용하여 액세스 제어 가능.


Gateway Endpoint 
  ▪ Endpoint가 Gateway 타입으로 지원하여 AWS 서비스 접근 시, 라우팅으로 접근
  ▪ 라우팅 테이블에서 S3나 DynamoDB의 목적지 네트워크에 대한 Target(Next Hop)으로 Gateway Endpoint를 지정
  ▪ S3와 DynamoDB 접근을 지원


Interface Endpoint
  ▪ Endpoint가 AZ 내의 Elastic Network Interface(ENI)로 생성하고, 해당 서비스에 대한 도메인 Lookup을 해당 ENI 응답
  ▪ Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager(SSM), Elastic Load Balancing(ELB) API 등을 지원
  ▪ Interface Endpoint 생성 시에는 어느 VPC의 어떤 AZ의 어떤 Subnet을 사용할지 선택
  ▪ Interface Endpoint 는 생성 시에 지정한
 각 서브넷의 IP를 각각 할당 받음.
  ▪ Interface Endpoint 를 이용해서 서비스를 호출하는 경우에는, AWS에서 기본으로 사용하는 도메인을 사용하거나, 
    별도의 서비스 도메인을 지정하여 VPC 내에서 서비스 도메인 Lookup 시에  Interface Endpoint 의  IP로 응답하여
    접근하도록 할 수 있음.
  ▪ 기존에 AWS Public 서비스를 사용하도록 어플리케이션이 만들어진 경우에 기본 도메인으로 Interface Endpoint 
   사용하게 되면  어플리케이션에서 AWS 서비스 호출 시에 별도의 변경 과정없이 Endpoint를 이용한 서비시 호출이 가능.

  

Endpoint 타입별 지원 서비스
  ▪ Gateway
    - Amazon S3
    - DynamoDB
 
  ▪ Interface
    - Amazon API Gateway
    - AWS CloudFormation
    - Amazon CloudWatch
    - Amazon CloudWatch Events
    - Amazon CloudWatch Logs
    - AWS CodeBuild
    - AWS Config
    - Amazon EC2 API
    - Elastic Load Balancing API
    - AWS Key Management Service
    - Amazon Kinesis Data Streams
    - Amazon SageMaker and Amazon SageMaker Runtime
    - Amazon SageMaker Notebook Instance
    - AWS Secrets Manager
    - AWS Security Token Service
    - AWS Service Catalog
    - Amazon SNS
    - AWS Systems Manager
    - Endpoint services hosted by other AWS accounts
    - Supported AWS Marketplace partner services

 

 

 

 

 

Posted by 네떡지기

Today Keys : Transit, Gateway, AWS, VPC, 트랜짓, peer, 네트워크, 아마존, TGW, Hub, Spoke


Last Updated : 18.12.14


이번 포스팅은 AWS re.Invent 2018에서 소개되었던, Transit Gateway에 대한 소개 포스팅에 이어서,

Transit Gateway를 직접 만들어서 테스트해보는 포스팅입니다.

※ 관련 포스팅 : Transit Gateway 소개 포스팅 보기


오늘 포스팅에서 구성하는 Transit Gateway에 대한 구성입니다.

2개의 VPC를 구성하고, 2개의 VPC 모두 하나의 AZ에 속합니다.

VPC-1에는 1개의 Subnet이 VPC-2에는 2개의 Subnet이 있으며, Transit Gateway에는 VPC-1과 VPC-2의

각 하나의 Subnet과 연결되어 있습니다.

 

 

그럼 이제 Transit Gateway를 생성하고 사용하는 과정을 알아 보겠습니다.

먼저 Transit Gateway를 만들어 보려고 합니다.

앞서 소개 포스팅에서 얘기했지만, 서울 Region에는 Transit Gateway를 만들 수 있는 메뉴가 없습니다.

18.12.06 기준 

18.12.14 기준 - 서울 Region에서도 Transit Gateways 사용 가능

 

미국으로 Region을 변경해서 보면, Transit Gateways 메뉴가 보이는 것을 확인할 수 있습니다.

저는 오하이오 Region에서 Transit Gateways를 만들어서 테스트를 진행합니다.

 

현재  생성한 Transit Gateway가 없기 때문에 해당 메뉴에서 [Create Transit Gateway ] 를 선택합니다.

 

다음과 같이 간단한 Name Tag와 옵션들을 선택하고, 바로 생성 가능합니다.

 

생성이 완료되면 다음과 같이 완료 메시지를 확인 할 수 있습니다.

 

완료 메시지 이후에 정상적으로 만들어지기 까지는 수 분이 소요됩니다.

초기에는 다음과 같이 pending 상태가 됩니다.

 

잠시 이후에 State가 available 상태로 되면서 Transit Gateway를 사용 할 수 있습니다.

 

 

Transit Gateway를 생성한 이후에는 연동하고자 하는 정보를 Attatch 해주어야 합니다.

Transit Gateway Attachment 메뉴를 선택해서 들어가면 다음과 같이 Transit Gateway ID에서

방금 전에 생성한 Transit Gateway를 선택 할 수 있습니다.

 

Transit Gateway를 선택하고, 어떤 type으로 attach할 것인지 정하게 되는 데

현재는 VPC와 VPN만 지원하고 있습니다.

Direct Connect 연결은 2019년 초에 지원된다고 합니다.

여기서 유의해서 볼 것은 VPC 연결 시에 특정 VPC 내에서 연결 할 서브넷을 지정할 수 있는 데,

VPC를 만들어 놓은 Region의 AZ 별로 Subnet을 선택 할 수 있습니다.

하나의 AZ에서 Subnet은 드랍박스 형태로 메뉴가 되어 있어서 1개 밖에 선택이 안됩니다. (1개만 가능)

정상적으로 VPC의 Subnet을 Attach하고 나면 다음과 같이 Attach된 내용이 보입니다.

 

동일하게 VPC-2의 서브넷에서도 동일한 과정을 진행하며, Transit Gateway 생성 및 연결이 됩니다.

하지만, 이 상태에서 10.1.1.0/24 Subnet과 10.2.1.0/24의 Subnet이 통신되지는 않습니다.

각각의 Subnet의 라우팅을 추가로 잡아야 합니다.

10.1.1.0/24이 속한 라우팅 테이블에 대해서는 Target(Next hop)을 앞서 만든 Transit Gateway를 선택합니다.

라우팅 테이블 추가 메뉴를 보면 Target 항목에 Transit Gateway를 선택 할 수 있습니다.

양 쪽 서브넷에서 라우팅을 모두 잡고 나면, 이제 정상적으로 두 VPC의 서브넷 간의 통신이 가능합니다.

다만, 라우팅을 10.1.1.0/24이 속한 라우팅 테이블에서 목적지 네트워크를 VPC-2의 CIDR로 설정한 10.2.0.0/16으로

하고 Target을 Transit Gateway로 잡더라도 Subnet 2의 10.2.2.0/24 으로는 통신이 되지 않습니다.

앞선 포스팅과 이번 포스팅 앞에서도 얘기했듯이 1개의 VPC의 1개의 AZ에서는 1개의 서브넷만 연동이 됩니다.

따라서 전체적인 설계를 할 때 이 점을 유의해서 설계해야 할 것입니다.

Posted by 네떡지기

Today Keys : Transit, Gateway, AWS, VPC, 트랜짓, peer, 네트워크, 아마존, TGW, Hub, Spoke

 


Last Updated : 18.12.14 

    - 서울 Region에서 사용 가능.


이번 포스팅은 AWS re.Invent 2018에서 소개되었던, Transit Gateway에 대한 간단한 포스팅입니다.

기존에 제공하지 않던 VPC 간의 Transit을 가능하도록 제공하는 기능입니다.

Transit를 허용하여 기존에 디자인 하던 방식을 좀 더 관리하기 편하도록 제공할 것입니다.

실제 Transit Gateway를 구성해서 테스트해보는 포스팅은 다음 포스팅을 확인하시면 됩니다.

※ 관련 포스팅 : VPC Transit Gateway 테스트 포스팅-1

 


 

AWS Transit Gateway (TGW)

Transit Gateway
  ▪ VPC 간의 Transit이 가능하도록 해주는 게이트웨이 서비스
      - 기존에 제공하지 않던 VPC 간의 Trasit이 가능하도록 제공
  ▪ Hub & Spoke 방식으로 Transit Gateway가 다른 VPC들의 Hub가 되어VPC 간을 통신 연계 가능
  ▪ Hub & Spoke 방식으로 연결되기 때문에 각 VPC는 직접 연결하지 않고 Transit Gateway만 연결하여 관리 및 확장 용이
  ▪ Resource Manager를 통해서 Transit Gateway를 타 계정에 공유해서 타 계정의 VPC와도 연동이 가능.
      - Resource Manager를 통해서 관리가 가능한 Resource 유형 중의 하나로 Transit Gateway를 사용
  ▪ On-premise에서 Transit Gateway로의 접근은 현재 VPN 방식만 지원하며, Direct Connect 기능은 2019년초 제공 예정
  ▪ 현재 서울 Region에서는 Transit Gateway 사용 가능.

 

 < VPN을 이용하여 On-Premise와 VPC 간을 Transit Gateway로 구성한 예 >


Transit Gateway 특징
  ▪ VPN ECMP 지원
  ▪ 연결당 최대 50Gbps 트래픽 처리 가능
  ▪ 각 게이트웨마다 최대 5000개의 VPC 연결 
  ▪ 1개의 VPC에서는 1개의 AZ에 1개의 Subnet만 Transit Gateway에 연결 가능 
      - 동일 AZ 내에서 추가 Subnet을 Transit Gateway에 Attatch 시도 시에 오류발생

 

  < 동일 VPC의 동일 AZ에 Subnet 추가 연동 시에 에러 >

   

 

 < VPC, AZ, Subnet을 고려한 Transit Gateway 연동 예 >

 

 

Posted by 네떡지기

Today Key :  AWS, VPC, Cloud, Network, Peering, region, 접속, 피어링


 이번 포스팅은 VPC 간의 연동을 해주는 VPC Peering에 대한 정리입니다.

 실제 VPC Peering을 연동하는 예제는 포스팅용으로 이미지를 정리해야해서.. 다음 포스팅에서 다뤄집니다. ^^

 혹시 수정이 필요한 내용이나, 보완해야 될 내용이 있으면 덧글로 남겨주세요! 



VPC Peering 

 · VPC 간의 인터넷을 통하지 않고 직접 통신 할 수 있도록 연결하는 기술

 · AWS 내에서 정의하는 정의하는 가상의 네트워크인 VPC는 논리적으로 독립적인 네트워크 망을 선언한 것이기 때문에

   기본적으로 VPC 간에는 서로 통신이 불가하여 VPC 간에 서로 영향을 미치지 않음.

 · VPC 간에 서로 통신을 하기 위해서는 VPC 내에서 인터넷을 통해서 다른 VPC로의 통신을 하는 구조였음.

 · 2014년에 VPC Peering 이라는 기술을 통해서 같은 리전 간의 VPC 네트워크를 서로 연결 할 수 있게 됨.

 · 2017년에 멀리 Region 간의 VPC Peering을 지원하도록 함.

 · 서울 Region에서의 VPC Peering은 2018년 중반부터 지원

 

 

VPC Peering 구성

 · 동일 Region 간의 Peering 예

 

 

  · 멀리 Region 간의 Peering 예

 

 

   · 공유 서비스를 이용하는 VPC Peering 예

 

 

VPC Peering 구성 관련

 · VPC Peering으로 연결 시에 VPC 간의 네트워크 대역이 겹치지 않도록 설계해야 함.

  · VPC Peering을 이용하면 Peering 된 VPC 네트워크은 AWS 백본을 통해서 통신하여 Pulbic 인터넷 망을 통과하지

   않기 때문에   보안적으로 보다 우수함.

   또한 내부 백본 네트워크를 통하기 때문에 이중화나 네트워크 병목에 대한 이슈도 없음.

 · VPC Peering은 단일 계정으로도 가능하며, 서로 다른 계정 간의 VPC Peering 구성도 가능

 

 VPC Peering 제한

· 멀티 Region 간의 VPC Peering 시에는 security group 참조 지원 안 함.

· 멀티 Region 간의 VPC Peering 시에는 DNS resolution 지원 안 함.

· IPv6와 Jumbo 프레임 지원 안 함.

·  VPC Peering을 통해서 외부 혹은 다른 VPC에서 VPC를 통해서 또 다른 VPC로 접근하는 Transit 기능은 지원하지 않음.

 

 

 

 

Posted by 네떡지기

티스토리 툴바