'Cloud Computing/AWS'에 해당되는 글 3건

  1. 2020.11.16 [AWS] Direct Connect
  2. 2020.03.19 [Redshift] Amazon Redshift Cluster 설정 시 주의할 3가지
  3. 2020.01.23 Amazon VPC(Virtual Private Cloud)생성하기

[AWS] Direct Connect

Cloud Computing/AWS 2020. 11. 16. 17:30

What is AWS Direct Connect?

AWS Direct Connect는 고객의 On-premise에서 AWS로 전용 네트워크 연결을 쉽게 구축할 수 있는 클라우드 서비스 솔루션입니다. AWS Direct Connect를 사용하면 AWS와 데이터 센터, 사무실 또는 코로케이션 환경 간에 사설 연결을 설정할 수 있으며, 이를 통해 대부분 네트워크 비용을 줄이고 대역폭 처리량을 높이며 인터넷 기반보다 일관된 네트워크 환경을 제공할 수 있습니다.
AWS Direct Connect를 사용하면 네트워크와 AWS Direct Connect 위치 중 하나 사이에 전용 네트워크 연결을 설정할 수 있습니다. 업계 표준 802.1q VLAN을 사용하여 이 전용 연결을 여러 가상 인터페이스로 분할할 수 있습니다.
이를 통해 퍼블릭 환경과 프라이빗 환경 간의 네트워크 분리를 유지하면서 퍼블릭 IP 주소 공간을 사용하는 Amazon Simple Storage Service (Amazon S3)의 저장된 객체와 같은 퍼블릭 리소스와 VPC ( Virtual Private Cloud )에서 프라이빗 IP공간을 사용하는 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스와 같은 프라이빗 리소스에 동일한 연결을 할 수 있습니다.
변화하는 요구를 충족시키기 위해 언제든지 가상 인터페이스를 재구성할 수 있습니다.



New Connectivity Model

NSX-T는 “Tier-0” 논리적 라우터 개념을 고객 연결 VPC와 같은 외부 네트워크, VPN 터널을 통한 다른 고객 VPC, 다른 쪽의 직접 연결 또는 인터넷을 통한 사내 네트워크와 같은 SDDC 컴퓨팅과 관리 네트워크 사이의 단일 연결 지점으로 사용합니다.
Tier-0 라우터는 또한 이전 NSX-V 모델에서 두 개의 별도 VM 대신 Tier-0 라우터에서 별도의 프로세스로 실행되므로 CGW와 MGW 간의 연결을 단순화합니다.

그림1 - AWS Direct Connect를 사용하여 VMware SDDC에 연결

AWS와 VMware의 공동 엔지니어링 작업을 통해 NSX-T에 대한 완벽한 Direct Connect 지원이 추가되었습니다. 이 기능을 사용하면 DX 공개 VIF 또는 인터넷을 통한 IPSec 터널 없이 SDDC와 연결된 경우 호스팅 된 Direct Connect Private VIF를 통한 고객의 온-프레미스 시설에 대한 SDC 논리 네트워크 및 관리 트래픽에 대한 기본 알림을 사용할 수 있습니다. 이 모델은 NSX-T와 NSX-V 기본 클러스터의 vMotion과 같은 사용 사례에 대한 연결 요구 사항을 크게 단순화합니다.

이 새로운 기능을 통해 고객은 호스팅 된 단일 프라이빗 VIF를 사용하여 SDDC에 연결할 수 있습니다. 이 프라이빗 호스팅 VIF를 사용하면 고객이 오버레이 네트워크의 워크로드 가상 머신과 호스트 관리 및 어플라이언스 네트워크와 통신할 수 있습니다.

Hosted Private VIF를 사용하면 계정 번호만 지정하여 다른 계정에서 VIF를 생성할 수 있습니다. 대상 계정은 계정에서 이 VIF를 수락해야 합니다.

이 경우 고객은 자신의 계정에서 Hosted Private VIF를 생성하고 VIF의 VMware Cloud on AWS 계정 번호를 입력할 수 있습니다. 이 계정 번호는 그림 2 와 같이 VMware Connect on AWS 콘솔의 Direct Connect> VMC AWS 계정에서 얻을 수 있습니다.

 

그림2 - VMware Direct on AWS Direct Connect 콘솔

Hosted VIF가 생성되면 고객은 VMware Cloud on AWS 콘솔에서 이를 수락할 수 있습니다. VMware SDDC는 이 VIF를 사용하여 모든 논리 네트워크를 광고하며 고객은 온 프레미스 네트워크를 SDDC에도 광고할 수 있습니다. 이를 통해 Direct Connect에서 1G 또는 10G 대역폭 연결을 활용하면서 고객을 위한 전체 연결 옵션을 단순화할 수 있습니다.

 

그림 3과 같이 콘솔의 알려진 BGP 경로 섹션에서 VMware Cloud SDDC에서 프레미스로 알려진 경로와 프레미스에서 받은 경로를 볼 수 있습니다. VMware Cloud SDDC에서 온-프레미스로 보급할 수 있는 최대 논리 네트워크 경로는 16개이며 평가 시 VMware에서 늘릴 수 있습니다.

그림3 -  AWS Direct Connect에서 보급 및 학습된 BGP 경로

이 기능은 현재 모든 VMware Cloud on AWS 리전에서 사용할 수 있습니다. 요금은 Direct Connect 연결의 계정 소유자가 시간당 연결 요금을 지불하고 VIF를 호스팅하는 계정이 데이터 송신 요금을 지불하는 AWS 요금 모델과 유사합니다.
이 경우 고객은 포트 요금을 지불하고 VMware는 송신 데이터 요금을 지불한 다음 고객에게 청구합니다. Direct Connect Gateway는 아직 VMware Cloud on AWS에서 지원되지 않습니다.



Conclusion

NSX-T 네트워킹으로 지원되는 새로운 VMware Cloud on AWS SDDC는 단일 Virtual Private Interface를 통해 인프라 (언더 레이) 및 오버레이 네트워크에 대한 완벽한 라우팅 지원을 제공합니다. 이 모델은 암호화가 필요하지 않은 경우 VPN 터널 없이 BGP 라우팅을 사용하여 SDDC와 온-프레미스 환경 간의 라우팅 요구 사항을 단순화합니다.
AWS Direct Connect는 1Gbps 및 10Gbps의 연결 속도를 제공합니다. AWS Direct Connect를 지원하는 APN 파트너는 50Mbps, 100Mbps, 200Mbps, 300Mbps, 400Mbps 및 500Mbps의 속도를 주문할 수 있습니다.
데이터 센터 확장, 재해 복구 또는 하이브리드 환경 구축을 위해 설계하는 고객은 AWS Direct Connect를 사용하여 VMware Cloud on AWS SDDC에 프라이빗 연결을 하실 수 있습니다.

 

 

원문 : aws.amazon.com/ko/blogs/apn/simplifying-network-connectivity-with-vmware-cloud-on-aws-and-aws-direct-connect/

Trackbacks 0 : Comments 0

Write a comment


[Redshift] Amazon Redshift Cluster 설정 시 주의할 3가지

Cloud Computing/AWS 2020. 3. 19. 16:58

1. Master user사용

2. 싱글 스키마

3. 기본 WLM Queue사용 

 

1. Master user사용

Redshift Cluster를 처음 생성할 때 반드시 Master user를 지정해야하지만,

이 user를 계속 사용하기 보다는 업무별로 사용자를 구분하여 관리하는것이 좋다. 예) ETL, BI, AD-HOC

이유는 사용자 별로 WLM설정 시 대기열을 지정함으로써 효율적인 Queue관리가 가능하기 때문이다.

 

2. 싱글 스키마

Redshift Cluster를 생성하면 자동으로 PUBLIC스키마가 생성된다.

기본으로 모든 사용자가 이 스키마에 대한 사용권한을 가지고 있으므로 사용을 피하고,

user group 및 user별로 스키마를 구성하여야 한다.

 

3. 기본 WLM Queue사용 

Redshift Cluster를 생성하면 기본으로 아래의 Queue가 생성된다.

  - default

  - superuser

queue에 대한 상세한 설명은 나중에 따로 하기로 하고 우선 간단하게 얘기해 보자면,

default queue는 5개의 쿼리를 동시에 실행할 수 있도록 5개의 슬롯이 할당되고, superuser queue는 하나의 슬롯이 할당된다.(콘솔에는 보이지 않음) superuser queue는 시스템 장애 등 정말 위급한 상황에 관리자만 사용가능한 queue이므로, 절대 일반적인 상황에서 사용하지 말아야한다. 아무생각없이 이 queue를 사용하다 정말 위급한 상황이 생길때 손을 쓰지 못하는 경우가 발생할 수 있다.

쿼리가 실행할 queue를 찾지 못할때 default queue를사용하게되는데 이 queue는 이를위해 그냥 두고,

업무별로 user group 및 user를 관리하는것 처럼 queue도 이를 바탕으로 컨커런시와 메모리를 설정하여 효율적인 구성이 가능하다.

 

 

Amazon Redshift Cluseter구성 시 주의해야할 3가지를 살펴보았다.

이 글을 읽고 너무 당연하다고 생각할 수 있으나, 생각보다 이 3가지를 모두 지키지 않는 사용자가 많다는게 현실이다.

Trackbacks 0 : Comments 0

Write a comment


Amazon VPC(Virtual Private Cloud)생성하기

Cloud Computing/AWS 2020. 1. 23. 18:00

VPC는 Virtual Private Cloud의 약어로 아마존 클라우드 내에서 Private IP를 사용하는, 일종의 가상 Private network를 만들게 해주는 서비스이다. 아마존 웹사이트에서는 아래와 같이 설명한다.

 

Amazon Virtual Private Cloud(Amazon VPC)에서는 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.

 

VPC 핵심 개념은 다음과 같다.

  • VPC는 사용자의 AWS계정 전용 가상 네트워크이다.
  • 서브넷(Subnet)은 VPC의 IP주소 범위이다.(=네트웍크 주소공간을 분할 = IP Group)
  • 라우팅테이블(Routing table)에는 네트워크 트래픽을 전달할 위치를 결정하는데 사용하는 라우팅이라는 규칙 집합이 포함되어 있다.
  • 인터넷 게이트웨이(Internet gateway)는 수평 확장되고 가용성이 높은 중복 VPC구성 요소로, VPC의 인스턴스와 인터넷과 통신할 수 있게 해주므로 네트워크 트래픽에 가용성 위험이나 대역폭 제약 조건이 발생하지 않는다.
  • VPC 엔드포인트(End point)를 통해 인터넷 게이트웨이, NAT디바이스, VPN연결 또는 AWS Direct Connect연결을 필요로 하지 않고 Private link 구동 지원AWS서비스 및 VPC 엔드포인트 서비스에 비공개로 연결할 수 있습니다. VPC인스턴스는 서비스 리소스와 통신하는데 퍼블릭 IP주소가 필요하지 않다. VPC와 기타 서비스 간 트래픽은 Amazon 네트워크를 벗어나지 않는다.

VPC

VPC는 아마존 콘솔에서 생성하고, VPC범위는, 하나의 VPC는 하나의 region내에서만 생성이 가능하다. 즉 VPC를 두 개 이상의 region에 걸쳐 사용이 불가능하다. 단 하나의 VPC는 여러개의 Amazon Availibilty Zone(이하 AZ)을 가질 수 있다. 또한 하나의 VPC가 가질 수 있는 IP주소의 range는 2^16=65535로 제한된다.

CIDR표현으로 10.0.0.0/16(10.0.0.0 ~ 10.0.255.255) 범위가 된다. CIDR에 대한 개념과 계산법은 아래 사이트에서 계산할 수 있다.

http://www.subnet-calculator.com/cidr.php

 

Subnet

VPC를 생성했으면 각각의 Subnet을 생성해야한다. Subnet의 범위를 다시 한번 살펴보면,

VPC는 앞서 설명한 것 처럼, 하나의 region내에서 여러개의 AZ에 걸쳐서 생성이 가능하다. VPC안에서는 여러개의 subnet을 생성할 수 있는데, 하나의 subnet은 VPC안에서 하나의 AZ에만 생성이 가능하다.

 

 

 

Route Table

각 Subnet에는 default로 subnet과 밖을 연결해주는 router가 생성되고, 이 router는 route table을 가지고 있다.

대상 IP Address에 routing경로를 정의하는 것으로 subnet에서 밖으로 나가는 outbound traffic에 대한 routing경로를 정의한다. 이 route table은 AWS콘솔에서 설정이 가능하고, routing경로는 target의 타입에 따라서 크게 3가지로 구분할 수 있다.

  • Local: VPC내의 다른 subnet으로 traffic을 routing한다.
  • Internet gateway: Internet gateway를 통해서 외부 인터넷으로 traffic을 routing한다.
  • Virtual  private gateway: 관리자가 임의로 정의한 destination으로 traffic을 routing한다. VPN연결을 위한 VPN gateway등이 그 예가 된다.

아래와 같이 설정해 놓으면 10.0.0.0 ~ 10.0.255.255는 VPC 내부로 routing되고, 이외의 모든 traffic은 igw-06eb1f727711c1d09(Internet gateway로 정의)라고 정의한 router로 routing된다.

 

모든 Subnet은 1개의 Routing table을 가져야 하며, 하나의 Routing table은 여러개의 subnet에 중복되서 적용될 수 있다.

 

Public subnet & Internet gateway

VPC내에 생성되는 EC2 Instance는 10.0.x.x와 같은 private IP이외에 Elastic IP(이하 EIP)를 통해서 일반 인터넷 주소인 Public IP까지 총 2개의 IP를 가질 수 있다.

Subnet 내의 EC2 Instance들이 직접 인터넷 EIP를 통해서 in/out bound connection이 연결 가능한 subnet을 public subnet이라고 정의 하는데, 이 in/out bound traffic은 internet gateway(이하 IGW)를 통해서 이루어지며, 콘솔 설정으로 만들 수 있고, 생성 후 VPC에 attach한 후, 사용하고자 하는 subnet의 routing table에 설정을 해주면 된다.

위 그림과 같이 subnet에서 인터넷으로, traffic은 EC2의 EIP를 통해서 router를 타고 router에 의해 정의된 routing경로를 따라 internet gateway를 거쳐서 인터넷에 연결된다.

 

Private subnet & NAT

Public subnet이 있으면 당연히 Private subnet도 있다. Private subnet은 EIP를 가지지 않고 private IP만 가지고 있으며, Internet으로 in/out bound연결이 불가능하며, 단지 다른 subnet으로만 연결이 가능하다.

보통 일반적인 회사에서 private network구성을 할 때 많이 사용하는 방법인데, private IP를 쓴다 하더라도 외부 시스템으로의 접속이 필요한 경우가 있다. 예를 들어 다른 서버와 connection을 하거나 patch를 읽어오는 것과 같은 outbound connection은 사용되는 경우가 많다. 일반 private network의 경우에는 outbound connection에 대해서 public IP를 binding하여 연결을 제공하는 방식으로 NAT(Network Address Translator)라는 장비를 사용하는데, Amazon에서도 마찬가지로 이러한 NAT를 이용해서 Private subnet 내의 instance가 Internet으로 나가는 outbound traffic이 지원될 수 있도록 한다.

NAT를 이용한다고 해서 특별한 기능을 Amazon이 제공하는 것이 아니고, Software기반의 NAT를 public subnet에 설치한 후에 private subnet에서 Internet으로 나가는 outbound traffic에 대한 routing경로를 이 NAT를 통하게 하는 것이다.

조금 사용을 편리하게 하기 위해서 Amazon에서는 AMI이미지 형태로 미리 NAT EC2이미지를 제공하고 있기 때문에, 별도의 선호 제품이 없을 경우에는 이 이미지를 사용하면 된다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html

보통 이 NAT를 사용할 경우, 전체 VPC에 대해서 한 두 개의 NAT만 사용하는 경우가 있는데, 애플리케이션이 private subnet에서 밖으로 나가는 outbound protocol이 많을 경우에 이 NAT자체가 병목 구간이 될 수 있기 때문에 NAT에 대한 traffic을 수시로 확인하고 알맞은 용량으로 운영을 해야 한다. 또한 Amazon 내부 서비스라 하더라도 Private IP가 아니고 Public IP를 사용하는 경우가 많고, 이 경우 private subnet에 있는 EC2인스턴스들은 NAT를 거치기 때문에 Amazon서비스에 대한 호출도 NAT를 사용함을 인지하고 NAT용량을 체크해야 한다. (예, S3는 public IP만 제공한다. 그래서 private subnet에서 S3로 traffic은 모두 NAT를 거치게 된다.)

 

VPN

VPN은 Virtual Private Network의 약자로 Public(인터넷)망을 통해서 회사의 Private network망에 연결하게 해주는 서비스이다. 예를 들어 회사가 10.0.1.xx 대역의 네트웍을 쓰고 있고, 내가 집에서 노트북으로 회사의 네트웍에 접속하고자 한다고 하자. 내 IP는 Public IP로 198.12.x.x를 사용한다고 하자. 회사 네트워크는 private망이기 때문에 접속이 불가능하다. 그래서 VPN gateway를 회사 네트워크와 내 PC에 설치해 놓으면 가상으로 내 PC를 회사 네트워크와 연결하여 같은 네트워크 대역으로 사용할 수 있게 해준다. 개인 PC와 회사 private 네트워크 뿐만 아니라, 물리적으로 분리되어 있는 지역간 사무실이나 네트워크까지 이 VPN 네트워크를 사용하면 하나의 private network으로 묶을 수 있다.

Amazon에서도 역시 VPN을 사용할 수 있는데, VPN을 사용하기 위해서는 VPN gateway를 설치해야 한다. 직접 소프트웨어 기반의 VPN을 설치할 수 도 있지만, Amazon에서 제공하는 VPN을 사용할 수 도 있다. VPN은 그 보안 및 암호화 방법에 따라 IPESC, IKE 등 여러가지 방법을 제공하는데, Amazon에서 제공하는 VPN의 경우에도 상당히 다양한 방법의 VPN프로토콜을 지원한다.(IPSEC, IKE, SHA-1방식의 Hashing, BGP peering 등) 자세한 내용은 아래 링크 참고.

http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Introduction.html

VPN을 통해서 VPC에서 할 수 있는 것은 region간 서로 다른 VPC를 같은 subnet으로 묶거나, 또는 회사 데이터 센터의 subnet을 VPN을 통해서 VPC와 같은 네트워크 대역으로 묶을 수 있다.

VPN을 구성할 때 고려해야 할 점은, VPC를 구성할 때 VPN을 통해서 다른 region이나 데이터 센터(회사)와 연결할 가능성이 있다면, subnet의 IP주소를 이에 맞게 구성해야 한다는 것이다. 만약에 vpc를 구성할 때 처음부터 10.0.0.0/16으로 Full range를 다 사용해 버리면 나중에 다른 데이터 센터와 VPC로 연결할 때 IP가 겹칠 수 있고, 이를 바꾸어야 하는 대 작업이 생길 수 있기 때문에 VPC디자인 시 먼저 subnet의 IP대역을 적절하게 분할하여 설계할 필요가 있다.

 

Security Group

Security Group은 VPC안에서 일종의 방화벽 처럼 사용된다. VPC가 아니더라도 Security group은 AWS에서 필수적으로 사용되는데, Security group은 inbound 또는 outbound traffic에 대해서 port별로 접근을 제어할 수 있는 기능을 제공한다. 마치 방화벽과 같은 기능을 하는 서비스라고 생각하면 된다. VPC안에서의 Security group의 차이점은 VPC를 사용하지 않는 경우 Security group에서는 inbound traffic에 대해서만 접근 제어가 가능한데, VPC내의 Security group의 경우에는 in/outbound traffic 모두에 대해서 접근 제어가 가능하다. 그 외에도 접근할 수 있는 Security group수나 지원하는 프로토콜의 종류가 차이가 있는데, 자세한 내용은 아래 링크를 참고하기 바란다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#VPC_Security_Group_Differences

Security group을 이용하면, Hosting환경에서 사용하는 DMZ와 같은 개념을 구현할 수 있다. 아래 아키텍처는 Web, REST API, DBMS 세 가지 계층으로 이루어진 시스템이다.

Web layer는 public subnet으로 구성하고, 인터넷으로 부터 들어오는 모든 TCP 80(HTTP) traffic을 받도록 Security group을 구성한다. REST API를 제공하는 subnet은 Web server들이 위치한 subnet으로 부터 들어오는 TCP 8080 traffic만 받도록 하고, DB들이 위치한 subnet은 API server용 subnet에서 들어오는 DB연결용 3306포트만 받도록 한다. 이런식으로 네트워크를 구성하면 조금 더 높은 수준의 보안을 제공할 수 있다.

 

Bastion

VPC를 사용하면, private subnet의 경우에는 외부에서 telnet이나 SSH로 접근 할 수 있는 방법이 없다.(Public IP가 없기 때문에) 또한 Public subnet에 있는 EC2 instance의 경우에도 모든 인스턴스에 SSH연결을 열어 놓게 되면 보안상으로 문제가 발생할 수 있는 가능성이 있다. 그래서 Bastion이라는 개념을 사용하는데, 일종의 Telnet접속 콘솔이라고 생각하면 된다.

VPC내의 모든 Instance들은 이 Bastion으로부터 Telnet 또는 SSH접속만을 허용하도록 Security group을 설정하고, 이 Bastion역시 SSH접속을 운영자나 PC운영센터(회사)의 IP대역을 통해서 SSH접속만을 할 수 있도록 Security group을 설정해 놓으면 VPC로의 접근을 안전하게 통제할 수 있으며, 단일 접속 지점만을 제공하기 때문에 모든 사용자의 접근 내용을 한군데로 logging해서 감시할 수 있는 장점이 있다. Bastion은 단일 접속 지점인 만큼 하나의 Instance로 운영하는 것보다는 HA를 사용하거나 일반적인 접속을 위한 Bastion과 Super user(Admin)만을 위한 별도의 Bastion을 포함하여 2개 이상을 운영하는 것이 좋다.

 

VPC Scenarios

지금까지 간략하게 VPC의 기능에 대해서 알아보았다. VPC를 제대로 사용하면 상당히 다양한 구조의 network을 구성할 수 있다. 반대로 얘기하면, 모르면 구성이나 사용이 매우 어렵다는 이야기가 된다. Amazon에서는 VPC에 대한 주요 사용 패턴에 따른 약 4가지 시나리오를 이미 준비해 놓고, VPC Wizard에서 지원하고 있다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenarios.html를 보면 Amazon에서 제공하는 주요4가지 시나리오에 대한 설명과 설정 방법을 참고할 수 있다.

 

 

이 문서는 아래 조대협님 글을 기준으로 작성하였습니다.

https://bcho.tistory.com/779

Trackbacks 0 : Comments 0

Write a comment