AWS SLA 관련 해서

AWS를 3년간 이용하면서 EC2에 대한 여러 이슈(네트워크, Status Fail 등)를 겪어 왔습니다.

그러나 대부분의 이슈가 SLA범주 내에 속하는 사항이라 별도의 크레딧은 신청하지는 않았습니다.

(가끔 AWS에서 먼저 크레딧을 제공주는 경우도 있었습니다.)

 

우리나라 시각으로 2016년 9월 말 주말 자정 쯤에 DynamoDB에 접속이 되지 않는 이슈가 발생되었습니다. AWS Support를 통해 확인을 해 보니 이때 AWS 내부 네트웍 문제로 접속에 문제가 있었다는 답변을 받았습니다.

이 기간 동안 AWS 이용해서 서비스를 제공하는 업체 입장에서는 서비스 장애였습니다.

 

그래서 DynamoDB SLA가 어떤지 찾아 보았습니다. 그러나 DynamoDB는 SLA가 없다는 것을 확인하였습니다.(홈페이지 상에서는 SLA 관련된 사항을 확인 해 볼 수 없어, AWS Support를 통해서 확인하였습니다.) 

당연히 있을 것이라 생각하였는데 없다는 것을 확인하니 좀 당황스러웠습니다. 

그래서 다른 서비스들의 SLA들은 어떤지 궁금하여 아래와 같이 정리해 보았습니다.

 

SLA가 제공되는 서비스

• Amazon EC2 & EBS

• Amazon RDS

• Amazon S3

• Amazon Cloud Front

• Route 53

위 사항을 제외한 다른 서비스들의 SLA는 확인해 볼 수 없었습니다.(2016년 10월 기준)

SLA 전체를 설명하는 문서는 없으며, 각 개별 서비스 문서에서만 SLA 관련 사항을 확인해 볼 수 있습니다.

 

AWS 서비스별 SLA 기본 사항

SLA를 충족하지 못 할 경우 아래 기준으로 사용 불가 시간에 대해 크레딧을 신청할 수 있습니다.

EC2의 경우는 아래와 같습니다.

월별 가동시간 비율	서비스 크레딧 비율
99.0% 이상 99.95% 미만	10%
99.0% 미만	30%

SLA 99.95%는 한달에 약 22분이고, 99%는 약 7.2시간에 해당합니다.

이 시간 동안 서비스가 원활하지 않았다면, 서비스 크레딧을 신청 할 수 있습니다.

 

RDS, S3, CloudFront는 아래와 같습니다.

월별 가동시간 비율	서비스 크레딧 비율
99.0% 이상 99.95% 미만	10%
99.0% 미만	25%

 

Route53의 경우 SLA는 100%입니다.

Route 53이 100% 이용 가능하지 않은 기간	서비스 크레딧
5 ~ 30분	서비스 크레딧 1일분
31분 ~ 4시간	서비스 크레딧 7일분
4시간 초과	서비스 크레딧 30일분

서비스 크레딧을 받기 위해서는 이슈가 명확해야 합니다.

즉, 이용자가 AWS 원인으로 이슈가 발생되었다는 것을 증명해야 합니다.

예외는 아래와 같습니다.

• AWS의 이용 약관에 위배되어 서비스가 중지 된 상태

• AWS의 노력 이외의 곳에서 일어난 문제(회선 업체 문제 등)

• AWS 이외의 이슈로 의심되는 곳(소프트웨어 문제 등)

각 서비스별 환불 조건

• EC2와 EBS
  Amazon EC2의 경우, 고객이 가동 중인 모든 인스턴스가 외부 연결을 확보하지 못 하였을 때
  Amazon EBS의 경우, 첨부된 고객의 모든 볼륨(volume)이 대기열에 대기 중인 IO에 대하여 읽기 쓰기 IO를 수행하지 못 하였을 때

• RDS
  Multi-AZ 설정을 해야 하며, DB Engine은 MySql, MariaDB, Oracle, PostgresSQL 중 하나 여야 합니다.
  (AWS에서 밀고 있는 Aurora는 SLA를 확인할 수 없었습니다.)

• S3 & Cloudfront
  SLA 범주를 넘는 것에 대한 증명 자체가 쉽지 않을 것을 보입니다.

• Route53
  Route53을 이용하여 pubic hosted zone을 만들었을 때, Default로 4개의 name server가 할당되며, 이를 모두 사용하지 않는 경우, 예를 들어 4개 중 2개만을 사용하는 등의 경우에는 Route53의 SLA 가 적용되지 않습니다.

정리

AWS에서 제공하는 서비스 중 SLA가 제공되는 항목이 생각보다 적습니다.

그리고 서비스 크레딧을 받기 위한 조건도 까다롭게 보입니다.(뭐  하나 쉬운  게 없네요...)

그럼에도 불구하고 개인적으로 AWS와 같은 Public Cloud는 사용할 수 밖에 없다고 생각 합니다.

• 글로벌 서비스를 위해 네트웍, 서버 장비 등을 하나 하나 준비해서 운영하는 것은 매우 어려울 것이라 생각 합니다. 이와 같은 서비스(public cloud)를 손수 만들어 사용한다 해도 AWS 만큼 잘 운영을 할 수 있다는 보장도 어렵습니다.

• AWS와 같은 public cloud를 사용하는 주된 이유는 신속한 인프라 전개로 서비스를 빠르게 만들어 시장에 출시하고 고객의 피드백을 바탕으로 개선해 나가는 것입니다.

다만, 이용자 입장에서 안전한 서비스 이용과 이슈 발생에 대한 보상을 수월하게 받았으면 하는 바람입니다.(저도 서비스를 제공하고 있지만, 욕심이 과한 거 같기도 합니다. ㅋㅋ)

참고

• http://blog.serverworks.co.jp/tech/2016/10/12/aws-sla/