블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'VPC'에 해당되는 글 3

  1. 2013.09.09 Amazon Elastic Load Balancer (2)
  2. 2013.08.18 Amazon VPC (Virtual Private Cloud) 소개 (3)
  3. 2012.11.14 Tips Amazon Cloud 사용시 고려 사항 (1)
 

 

Elastic Load Balancer

 조대협

ELB는 아마존에서 제공하는 일종의 L4와 같은 로드 밸런서이다. 내부적으로 VM위에서 동작하는 소프트웨어 로드밸런서이고, 아마존 환경에 맞춰서 최적화 되어 있다.

 



Multiple zone support

ELB는 기본적으로 multiple zone을 지원한다. ELB 생성시, ELB를 배포할 Amazon Availability Zone을 지정할 수 있다. 여러 개의 zone multiple ELB instance가 배포 되기 때문에 ELB 인스턴스는 기본적으로 ip 주소를 가지지 않는다. 대신 DNS 주소를 가지는데, 테스트를 해보면 알겠지만, ELB DNS 주소는 경우에 따라서 1개 이상의 주소를 리턴하게 된다.

이는 multiple zone을 지원하기 위해서 뿐만 아니라, ELB의 용량이 모자르게 되면 내부적으로 자동으로 scaling을 하는데, 먼저 ELB scale up을 해서 인스턴스 크기를 키우고, 모자르다면 다른 ELB 인스턴스를 만들어서 추가 하는 scaling out 작업을 수행한다.

여러개의 ELB를 하나의 end point로 묶기 위해서 DNS 리스트 방식을 사용하게 된다.

SSL Termination

ELB SSL 기반의 HTTPS 프로토콜을 지원할 수 있다.ELB 설정에 SSL 인증서를 세팅해놓으면 Client --> ELB SSL, ELB --> 백엔드 EC2까지는 HTTP로 통신을 하게 된다.

X-forwarded for Header

ELB EC2 인스턴스 앞에서 로드밸런싱을 하게 되면 EC2 입장에서 incoming address ELB의 주소로 인식하게 된다. 애플리케이션에 따라서 client ip를 알아야 할 경우가 있는데, EC2 입장에서는 ELB request를 하는 주체가 되기 때문인데, 이러한 문제를 해결하기 위해서 ELB는 원래의 client ip X-forwarded-for (XFF) 헤더 안에 실어서 보내준다. EC2에서는 이 XFF HTTP Header를 열어 봄으로써 원본 client ip를 알아낼 수 있다.

Sticky Session

ELB가 추가적으로 제공하는 기능중에 하나가 sticky session이라는 기능이다. 이 기능은 client로 부터 들어오는 http request를 항상 같은 ec2 인스턴스로 라우팅을 해주는 기능인데, ELB sticky session의 원리는 cookie를 사용한다.

Sticky session 기능을 on 해놓으면, http response cookie를 세팅하여, 해당 client가 가는 ec2 instance에 대한 정보를 저장해 놓는 방식이다.

몇 가지 추가 설정이 필요한데, 애플리케이션이 이미 http cookie를 사용하고 있으면, 해당 cookie 명을 넣어서 사용중인 애플리케이션 cookie를 사용하게 하고, 만약에 애플리케이션이 cookie를 사용하지 않으면, 별도로 ELB cookie를 만들도록 한다.



위의 그림과 같이 sticky session 기능은 cookie를 사용하기 때문에, multiple ELB 상황에서도 항상 같은 request를 같은 ec2 인스턴스로 라우팅할 수 있게 해준다.

Health Check

ELB ELB에 연결된 EC2 인스턴스에 대한 자체적인 Health Check 기능을 가지고 있다. 사용자 설정에서 정해진 옵션에 따라서 주기적으로 EC2 인스턴스에 Health Check 메세지를 보내고, 만약에 EC2 인스턴스가 장애로 판단되면, 해당 인스턴스를 로드밸런싱 리스트에서 제외한다.

반대로, 제외되었던 인스턴스라도, 주기적으로 체크해서 정상화가 되면 다시 로드 밸런싱 대상에 추가하게 된다.

DNS Fail Over

다음으로 ELB 간의 HA이다. Load Balancing은 앞에서 언급한 바와 같이 DNS Round Robin 을 사용한다. 마찬가지로 HA 역시 DNS 방식을 사용하는데, Amazon DNS ELB 인스턴스들의 상태를 감시하다가 문제가 생기면, DNS 리스트에서 제외를 한다.

DNS 방식이기 때문에, TTL 시간을 가지고 있고, TTL 시간이 지나야 리스트가 클라이언트에 업데이트 되기 때문에, TTL 시간이 지나기 전까지는 client가 계속 장애가 난 인스턴스로 로드가 밸런스 될 수 있다. 그래서 Load Balancer 기반의 Fail Over 보다는 넘어가는 시간이 느리다.

VPC & ELB

앞서 VPC에 대한 개념에 대해서 설명하였는데, ELB 역시 VPC 안쪽이나 바깥쪽 양쪽에 배포가 가능하다. VPC 바깥쪽에 배포를 하여 public ip를 가지고 VPC 안쪽의 EC 인스턴스에 대해서 로드밸런싱이 가능하며, 또한 VPC 안쪽에 배포를 하여 private ip를 가지고 EC 인스턴스에 대해서 로드 밸런싱이 가능하다.

주의해야할점

마지막으로 ELB 사용 및 테스트시 주의할점을 몇가지 언급해보면 다음과 같다.

ELB로 성능 테스트를 하다 보면, 부하가 일정 수준으로 못 올라가는 경우에 ELB에서 Network In/Out bound 쪽에서 병목이 있는 것을 발견할 수 있는데, 이는 ELB의 용량이 충분하지 않기 때문이다. ELB는 자체적으로 scaling을 하기는 하지만, scaling이 그리 빠르지 않다. 그래서 성능 테스트를 할 경우에는 wramp up 기간을 둬서 충분히 부하를 줘서 인위적으로 ELB scaling하게 해 놓은 후에, 부하 테스트를 해야 ELB 단의 병목을 피할 수 있다.

또는 wramp up 이 되었는지 여부가 확실 하지 않으면 DNS look up으로 몇 개의 ELB 인스턴스가 생성되었는지 확인해보거나, 제일은 Amazon쪽에 부하 테스트 기간을 알려주면 미리 Amazon 쪽에서 ELB scaling 해 준다.

그리고 부하테스트를 하다 보면, 특정 EC2 Instance나 특정 Availability Zone으로 몰리는 현상이 있을 수 가 있다. 특정 Zone으로 부하가 몰리는 현상은 흔히 발생하는 데, ELB 자체가 부하를 골고루 분산해 주지 않는다. 다만 특정 Zone이나 Instance로 몰리는 현상이 아주 심할 경우에는 몇 가지 요인을 생각해볼 수 있는데, 먼저 부하 테스트 쪽의 DNS 캐쉬를 의심해볼 수 있다.

ELB간의 로드밸런싱은 DNS Round Robin을 사용하기 때문에, 클라이언트 쪽의 캐쉬를 지워주지 않으면 그 시간동안 계속해서 특정 ELB 인스턴스에만 부하를 주게 된다.

특정 인스턴스로 몰리는 현상의 경우 Sticky Session을 사용하는 경우, 클라이언트 쪽의 Cookie를 지워 주지 않아서, Cookie를 참조해서 계속 같은 EC2 인스턴스로 부하가 가는 경우가 많다.

 

그래서 ELB 기반의 부하테스트를 할 때에는 고성능 적은 수의 클라이언트 보다는 많은 수의 저성능 클라이언트를 사용하는 것이 부하를 골고루 나눠 지게 할 수 있다.

 

Amazon VPC (Virtual Private Cloud)

조대협 (http://bcho.tistory.com)


VPC Virtual Private Cloud의 약자로 아마존 클라우드 내에서 private ip를 사용하는 일종의 가상 private network 망을 만들어줄 수 있게 해주는 서비스이다.

이 서비스 전에는 EIP 이외에는 정적 서비스를 사용할 수 없었으며, 또한 10.0.x.x와 같은 private ip를 사용할 수 없었다. VPC 서비스와 함께, 내부 ip 대역을 사용할 수 있게 되었으며 조금 더 유연한 네트워크 관리가 가능하게 되었다.


VPC

VPC Amazon 콘솔에서 생성하면 되는데, VPC의 범위는 , 하나의 VPC는 하나의 Region내에서만 생성이 가능하다. VPC를 두개 이상의 region에 걸쳐서 사용이 불가능하다.단 하나의 VPC는 여러개의 Amazon Availibility 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의 타입에 따라서, 크게 세가지로 분리할 수 있다.



Ÿ   *  Local : VPC 내의 다른 subnet으로 traffic routing 한다.

Ÿ   Internet gateway : internet gateway를 통해서, 외부 인터넷으로 trafficrouting 한다.

Ÿ   * Virtual private gateway : 관리자가 임의로 정의한 destination으로 trafficrouting한다. VPN 연결을 위한 VPN gateway 등이 그 예가 된다.


아래와 같이 설정을 해놓으면, 10.0.0.0~10.0.255.255 VPC 내부로 routing이 되고, 172.16.0.0~172.31.255.255 vgw-9628c9ff 라고 정의한 routerrouting이 된다.



또 다른 예를 보자.



이 경우에는 172.31.0.0~172.31.255.255는 내부 VPC 내로 routing이 되고, 이 외의 모든 traffic igw-0eab8665 (internet gateway로 정의했음) 을 통해서 외부 인터넷으로 routing이 되게 된다.

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


Public subnet & Internet gateway

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

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



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


Private subnet & NAT

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



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



NAT를 이용한다고 해서, 특별한 기능을 Amazon이 제공하는 것이 아니고, Software 기반의 NAT public subnet에 설치한후에, private subnet에서 인터넷으로 나가는 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에 대해서 알아보자. VPN (Virtual Private Network) 서비스의 약자로, public(인터넷) 망을 통해서 회사의 private network 망에 연결하게 해주는 서비스 이다.

예를 들어 회사가 10.0.1.XX 대역의 네트웍을 쓰고 있고, 내가 집에서 노트북으로 회사의 네트웍에 접속하고자 한다고 하자. IP public internet 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 ).

자세한 내용은 아래 Link 참고
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 GroupVPC 안에서 일종의 방화벽 처럼 사용된다. VPC 가 아니더라도 Security GroupAWS에서 필수적으로 사용되는데, Security 그룹은 inboud 또는 outbound traffic에 대해서 port 별로 접근을 제어할 수 있는 기능을 제공한다. 마치 방화벽과 같은 기능을 하는 서비스라고 생가하면 된다.

 VPC 안에서의 Security Group의 차이점은 VPC를 사용하지 않는 경우 Security Group에서는 inbound traffic에 대해서만 접근 제어가 가능한데, VPC내의 Security Group의 경우에는 in/outbound traffic 모두에 대해서 접근 제어가 가능하다.

그 외에도, 생성할 수 있는 Security Group수나 지원 하는 Protocol의 종류가 차이가 있는데, 자세한 내용은
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 접속 Console이라고 생각하면 된다.



VPC 내의 모든 Instance들은 이 Bastion으로 부터의 telnet 또는 SSH 접속 만을 허용하도록 Security Group이 설정하고, Bastion역시 SSH 접속을 운영자의 PC나 운영센터 (회사) IP 대역을 통해서 SSH 접속만을 할 수 있도록 Security Group을 설정해놓으면 VPC로의 접근을 안전하게 통제할 수 있으며, 단일 접속 지점만을 제공하기 때문에, 모든 사용자의 접근 내용을 한군데로 logging해서 감시할 수 있는 장점이 있다.

Bastion은 단일 접속 지점인 만큼 하나의 instance로 운영하는 것보다는 HA를 사용하거나 또는 일반적인 접속을 위한 Bastion, super user만을 위한 (나중에 일반 접속용 Bastion이 장애가 나서 접속이 불가할 때 사용할 용도) 별도의 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가지 시나리오에 대한 설명과 설정 방법을 참고할 수 있다.

 

AWS (Amazon Web Service) 사용시 주의 사항


1. IP가 매번 바뀐다.

aws의 ec2 instance는 restart시 마다 ip가 매번 바뀐다. ip를 바꾸지 않으려면 EIP (Elastic IP)를 사용해야 하는데, 비용이 크다. 그래서 이런 경우에는 aws에 자체 dns 서버를 세팅하고, instance 가 start up 될때 마다, 고유 서버의 dns 이름을 새로 binding된 ip와 맵핑해서 dns서버에 등록하도록 스크립트를 짜 놓으면 유용하다.


2. io bandwidth를 믿지 마라

aws의 가장 큰 어려운 점이, 네트워크 대역폭이다. 아무래도 공유 서비스이다 보니 네트워크 대역폭이 매우 느리다. 즉 내부 서버간 예를 들어 application server - dbms 또는 application server간에 네트워크 대역폭이 느리고 또는 일정하지 않기 때문에 대 부분의 병목이 여기서 발생한다.

이를 해결하기 위한 방법은 큰 ec2 instance를 사용하면 높은 대역폭을 사용할 수 있으며,

Provisioned IOPS를 지원하는 ec2 instance의 경우에는 일정 수준의 IOPS를 보장해준다. (물론 돈을 내야 한다.)

또는 고 성능의 IOPS를 보장하는 인스턴스를 사용하는 것도 방법이 된다.

다른 방법으로는 Placement group이라는 옵션을 사용할 수 있다. 이는 clustering이 필요한 솔루션 (Nosql이나 cache 솔루션)을 사용할때 이 placement group을 이용하면, 해당 서버들을 가능하면 물리적으로 가까운 곳에 위치 시켜서, network 지연을 최소화 한다.

참고 http://bcho.tistory.com/630


3. 미리 resource를 확보해라.

EIP는 5개, EC instance는 20개가 처음 계정을 만들었을때 디폴트 값이다. 테스트 환경을 사용하거나 몬가 하다보면 eip나 ec2 instance가 모자르게 되는데, 미리 미리 확장에 대비해서 확보해놓는 것도 중요하다. 신규 신청시 시간이 걸리기 때문에 미리 신청해놔야 하며, 상품에 따라서 미리 확보해놓으면 과금이 될 수 있다. 아래는 디폴트로 확보되는 자원의 수이다.

EIP – 5
EC2 instance – 20
EBS Volumes – 5,000 volumes or an aggregate size of 20 TiB (max volume size is 1TB)
PIOPS - 10,000 Provisioned IOPS or an aggregate size of 20 TiB (whichever is smaller) S3 Buckets – 100 
Route53 - 100 Hosted Zones and 10,000 Resource Record Sets per Hosted Zone 
ELB - 10 concurrent load balancers 
RDS – 20 RDS MySQL instances (each instance has hard limit max 1024GB) and up to 5 Read Replica instances can be created from a Master. 
VPC – 5 VPCs, 20 subnets each, 50 Security Groups each, 50 rules per Security Group and 5 Security Groups per instance. 10 Network ACLS per VPC, 20 rules per ACL. 10 Route Tables per VPC and 20 entries per route table


4. 가급적이면 VPC를 사용하자.

VPC는 Virtual Private Cloud의 약자로 10.x.x.x 와 같은 내부 ip 대역을 사용할 수 있게 해준다. 이는 논리적으로 다른 서비스(다른 사용자의)와 분리하게 해줄뿐더러, ip를 고정으로 사용할 수 있게 해주시 때문에 위의 1번 문제를 회피할 수 있도록 해준다.


5. 과금에 관련해서.

안쓸때는 꺼놔라. 다 과금 된다.

1시간5분을 사용하더라도 2시간으로 과금된다. 서버의 startup과 down은 시간 단위로 하자.


6. RDS

최대 용량이 1TB이다. 장점은 AZ(Zone)간의 HA를 기본적으로 지원한다.

replica는 db당 최대 5개 까지만 지원한다.


7. multicast

AWS는 multicast를 지원하지 않는다. 상당수의 클러스터링 솔루션이 muticast를 사용하는 경우가 많다.(Oracle RAC) 이경우에는 AWS에서 클러스터를 사용할 수 없다.


8. ELB는 고정 IP가 아니다.

ELB는 HA와 확장성을 지원하기 위해서 DNS Round Robine 방식으로 연결된다. 즉 고정 IP를 사용할 수 없다. 시스템에 대한 접근 IP(방화벽등을 위해서)가 필요할 경우 ELB 앞단에 HA Proxy등 별도의 Proxy를 둬야 한다.


9. AWS에는 IDS가 없다.

기본적으로 탑재된 침입 탐지등의 ids/ips 솔루션이 없기 때문에, 보안이 중요한 경우 이를 사전 고려 해서 ec2 위에서 기동 될 수 있는 ids/ips 솔루션을 탑재하는 것이 좋다.


10. 장기적인 이용에는 on-demand instance를 이용하지 마라.

on-demand instance는 그때 그때 사용하기는 좋지만 과금 모델이 가장 비싸다. 어느정도 기간을 가지고 이용할 예정이면 reserved instance나 spot instance를 이용하는 것이 저렴하다.