Amazon Web Services

최근 수정 시각:

파일:aws-regions.png
전 세계에 포진해있는 AWS의 데이터 센터들

Amazon Web Services(AWS)
아마존 웹 서비스

파일:aws.png

파일:aws_logo_smile_1200x630.png

CEO

앤드류 제시

본사

미국 워싱턴 주 시애틀

창립

2006년

모기업

아마존닷컴

홈페이지 트위터 페이스북 블로그

1. 개요2. 배경3. 서비스
3.1. 컴퓨팅
3.1.1. EC23.1.2. EC2 Container Service3.1.3. Elastic Beanstalk3.1.4. Lambda
3.2. 스토리지
3.2.1. S33.2.2. CloudFront3.2.3. Elastic File System3.2.4. Glacier3.2.5. Snowball3.2.6. Storage Gateway3.2.7. Snowmobile
3.3. 데이터베이스
3.3.1. RDS3.3.2. DynamoDB3.3.3. ElastiCache3.3.4. Redshift3.3.5. DMS
3.4. 네트워크
3.4.1. VPC3.4.2. Direct Connect3.4.3. Route 53
3.5. 개발 도구
3.5.1. CodeCommit3.5.2. CodeDeploy3.5.3. CodePipeline
3.6. 관리 도구
3.6.1. CloudWatch3.6.2. CloudFormation3.6.3. CloudTrail3.6.4. Config3.6.5. OpsWorks3.6.6. Service Catalog3.6.7. Trusted Advisor
3.7. 보안 및 인증
3.7.1. Identity & Access Management(IAM)3.7.2. Directory Service3.7.3. Inspector3.7.4. WAF3.7.5. Certificate Manager
3.8. 분석 및 통계
3.8.1. EMR3.8.2. Data Pipeline3.8.3. Elasticsearch Service3.8.4. Kinesis3.8.5. Machine Learning
3.9. 사물 인터넷
3.9.1. AWS IoT
3.10. 게임 개발
3.10.1. GameLift
3.11. 모바일
3.11.1. Mobile Hub3.11.2. Cognito3.11.3. Device Farm3.11.4. Mobile Analysis3.11.5. SNS
3.12. 애플리케이션
3.12.1. API Gateway3.12.2. AppStream3.12.3. CloudSearch3.12.4. Elastic Transcoder3.12.5. SES3.12.6. SQS3.12.7. SWF
3.13. 기업용 애플리케이션
3.13.1. WorkSpace3.13.2. WorkDocs3.13.3. WorkMail
3.14. 인공지능
3.14.1. Lex3.14.2. Polly3.14.3. Rekognition3.14.4. Machine Learning
4. 자격증5. 참조6. 국내 딜러7. 관련 문서

1. 개요[편집]

전 세계 시장의 독보적인 1위를 자랑하는 클라우드 컴퓨팅 플랫폼

IT 인프라 구축에 필요한 온갖 서비스들을 제공한다. AWS에서 제공하는 모든 서비스는 API로 제어할 수 있다는 것이 특징인데, 기본적으로 HTTP나 REST, SOAP로 이루어지며, JavaPython, PHP, Ruby, .NET 등에서 쓸 수 있는 라이브러리 및 샘플 코드도 제공한다.# 일단 문서를 보자.

웹 관리 콘솔(Mamagement Console)[1]에서 클릭 몇번으로 간단하게 제어하는 것도 가능하다.

아마존의 모든 기능을 원하는대로 자동화할 수 있어 가능한 얼마든지 비용을 줄이는 방향으로 최적화할 수 있다. 물론 솔루션 아키텍트의 역량에 달렸지만.. 심지어 아마존에서도 이런 식으로 비용을 절감하여 사용할 것을 적극 권장하는데, 실제로 AWS 공인 솔루션 아키텍트 과정에서는 AWS 서비스를 비용 효율적인 아키텍처로 구축하는 모범 사례에 대해서 학습하게 된다.[2]

힘들게 비싼 돈주고 서버 사고 IDC에 넣고 골치썩을 일 없이 쓴 만큼만 아마존에 내면 땡이기 때문에, 가진 게 아이디어하고 두뇌밖에 없는 실리콘 밸리 워너비 벤쳐기업들이 사업 시작할 때 가장 많이 쓰는 서비스가 되었다. 심지어 AWS 위에다가 클라우드 서비스를 재구성해서 다른 개발자나 기업한테 팔아먹는 식의 서비스까지 생겨날 정도가 되었으며, API는 있는데 AWS 웹 콘솔이 지원 하지 않는 기능을 자기들이 콘솔로 만들어서 서비스하기까지 한다(...)[3] 작은 기업들만 쓰는 것도 아닌 게, 애플iCloudMicrosoft Azure와 AWS 위에서 동작하는 것으로 유명하다. ?![4] AWS가 뻑나면 iCloud 전체가 뻑난다는건 주지의 사실. 그리고 해외의 유명 대학에서는 연구를 위해 IT인프라를 자체 확보하지 않고 AWS나 Microsoft Azure를 쓰는 경우도 점차 늘고 있다.[5]

이전까지는 스타트업 문화 자체가 약하고[6] 클라우드 컴퓨팅에 대한 이해가 떨어지는 등 여러 요인으로 AWS는 아는 사람만 쓰는 부류의 서비스였다.[7] 미국, 유럽 등에 유행하기도 전에 클라우드를 도입한 기업들은 AWS보다는 KT의 uCloud Biz 같은 국내 클라우드 서비스를 활용했는데, 아무래도 국내에 진출하기 위해 적극적으로 홍보하기 전까지는 인지도가 떨어졌던 영향이 컸기 때문인 듯.[8] 국내에서는 수도권에 있는 데이터 센터 하나면 내수용 서비스에는 무리가 없다는게 이유일지도 모른다. 그러나 2018년 1월 현재는 정부 차원에서 기술 기반 창업의 장려, 지속적인 데이터 센터 확충에 따른 규모의 경제 실현, 마이크로 서비스 아키텍처의 확산, 서울 리전(Region)의 개시 등 여러 요인으로 AWS 솔루션 도입을 검토하는 기업들이 많아졌고, 관련 직종의 구인공고에서 AWS 개발 경험자를 우대하는 경향을 많이 볼 수 있게 되었다.

2016년 이전까지는 국내에 AWS 데이터 센터가 존재하지 않아서 가장 가까운 도쿄 리전(Region)에 인스턴스를 생성해서 사용해왔는데, AWS 수요가 급격히 늘어서 이에 대응해 2016년 서울 리전(Region)이 설립되었다. 따라서 아시아 한정으로 일본, 싱가폴, 그리고 대한민국 총 세 곳에서 AWS 리전(Region)이 운영되고 있다. 호주는 논외.[9][10] 아마존 웹 서비스 한국 블로그

아마존닷컴트위치를 인수한 후에는 정말 미친듯이 데이터센터 확충에 열을 올리고 있다. 하지만 트위치 SEL서버는 홍콩 있어 회선비, 세금 등 절세하고 있다.

참고로 나무위키의 메일 서버가 이곳을 사용하고 있으며[11], 배틀그라운드 게임 서버도 이곳을 이용하는 것으로 확인되었다.

2. 배경[편집]

AWS가 왜 아래 후술할 수많은 서비스들을 API로 제공하게 되었는가 하면, 이미 아마존 자체가 그렇게 존재하고 있기 때문이다. 그러니까, 아마존닷컴 서비스 자체가 이미 AWS 위에서 돌아가고 있는 것이다.

아마존의 창업자이자 CEO인 제프 베조스는 2002년 어느 날 아래 내용의 메일을 사내에 돌렸다고 한다.

  1. 모든 팀들은 데이터와 기능들을 서비스 인터페이스로 연결시켜라.

  2. 팀들은 이 인터페이스를 통해서 연락해야 한다.

  3. 다른 어떤 커뮤니케이션 방법도 허용되지 않는다. 직접 링크를 보내거나 다른 팀의 스토리지에 직접 엑세스 해서도 안 되며, 공유 메모리나 백도어 같은 것도 안 된다. 모든 커뮤니케이션은 네트워크를 통한 서비스 인터페이스로 이루어져야 한다.

  4. 어떤 기술을 쓰든 상관없다. HTTP, Cobra, Pubsub, 독자 프로토콜...그건 상관없다. 베조스는 그런데 관심 없다.

  5. 모든 서비스 인터페이스는 예외 없이 외부에서 이용 가능하게 만들어져야 한다. 그 말은 팀들은 외부 개발자들이 인터페이스를 이용할 수 있게 해야한다는 것이다. 예외는 없다.

  6. 이를 실천하지 않는 사람은 누구든 해고될 것이다.

  7. 읽어줘서 고맙다. 좋은 하루가 되길.[12]

    출처: 스티브의 구글 플랫폼 폭언(http://eggry.egloos.com/3763434)


그래서 아마존 직원들은 열심히 아마존닷컴의 인프라를 서비스 지향 아키텍처로 갈아치웠다. 2006년까지. 어쩌겠어 짤리기 싫으면 해야지 자세한 내용은 출처 참조. 원 작성자인 스티비 예이그(Stevey Yegge)키워 기질이 다분하다는 걸 감안하고 읽자. 읽다보면 아마존도 까고 구글도 까고 마이크로소프트도 까고 다 깐다는 걸 알 수 있다.

3. 서비스[편집]

제공하는 서비스를 목록으로 간략하게 정리하지만, 실제로는 훨씬 더 방대한 서비스들과 개별 기능들을 제공하므로, 공식 문서를 참조할 것.

3.1. 컴퓨팅[편집]

3.1.1. EC2[편집]

AWS의 핵심이면서 가장 많이 사용하는 가상 서버 서비스

Elastic Compute Cloud. CPU 사용량 그런 거 없이 기본적으로 켜놓은 시간을 기준으로 과금하는 구조다. 다만 새 서버 인스턴스를 생성하고 프로그램 올리고 구동하는 게 전부 제공되는 API로 다 되기 때문에 Auto Scaling 서비스와 연계해서 트래픽이 몰리면 인스턴스를 자동으로 늘려서 대응하고 트래픽이 줄어들면 만들었던 인스턴스를 없애는 일을 할 수 있다. 성능별로 micro/small/large/xlarge 등으로 세분화되는데, 주의할 것은 성능 좋은 인스턴스를 쓸수록 그만큼 과금액이 기하급수적으로 늘어난다. 때문에 작은 서버 여러 대로 분산처리를 하는 것이 필수고, 고성능이 필요한 연산이 있으면 필요할 때만 잠깐씩 서버를 생성했다가 계산 끝내고 다시 없애버리는 식으로 사용시간을 아껴야 한다. 시간당 요금을 결제하는 방법부터 다양한 방식의 사용법 및 과금법이 존재한다.

또한 고려할 점이 데이터 트래픽 요금이다. 현재는 인터넷구간으로 월 1GB까지 무료, 10TB까지는 GB당 0.09달러 등으로 책정되어 있다. 그러니 대용량 데이터용을 생각할 때는 회선비용도 고려해야한다. 정적 콘텐츠 제공용으로는 S3+CloudFront, 대규모 데이터 이동시에는 Import/Export Snowball 등의 다른 서비스를 사용해서 비용을 아끼자. AWS에서 EC2 서비스는 제공하는 성능 대비 가장 비싼[13] 서비스라고 생각해야 한다. 소규모에서는 EC2가 저렴하다가 대규모로 서비스가 발전하면 갑자기 확 비싸지는 게 EC2의 특징이다.

이나 SFTP 접속은 별도의 인증서를 사용해서 이루어진다. 그래서 인증서 로그인 기능이 없는 알드라이브EditPlus 등에서는 이용이 불가능하다.

  • 온 디맨드 인스턴스 (On Demand Instance)
    사용한 만큼 과금된다. 단, 과금의 단위가 1시간이기 때문에 1초를 사용해도 1시간 어치가 과금된다. 다른 회사의 호스팅 서비스는 1초를 사용하려 해도 1개월어치를 선불로 낸다. 이보다 더 짧은 주기로 과금을 제어하는 곳은 2016년 현재까지는 Google Cloud PlatformCompute Engine으로, 분 단위로 과금된다.
    그리고 인스턴스(서버)를 켜 놓은 시간으로 과금되기 때문에 고성능 인스턴스를 켜 놓고 잊어버리면 월말에 어마어마한 요금 폭탄을 맞게 된다. 서버에 접속한 시간 기준이 아니라 켜 놓은 시간 기준이다. 따라서 안 쓰는 인스턴스는 반드시 Stop시켜야 한다. Stop한 인스턴스도 EBS 스토리지(인스턴스가 저장된 가상 디스크) 1GB당 0.1달러(SSD 기준)를 매달 지불하므로 다시 켤 일이 없는 인스턴스는 Terminate시켜서 완전히 삭제하고 해당 인스턴스가 사용한 모든 EBS 볼륨도 역시 지워줘야 한다.[14] 보통 Terminate시키면 EBS 볼륨도 자동으로 삭제되지만 옵션에서 이걸 막을 수 있게 돼 있으므로 확인은 필수.
    그러나, 이런 번거로움을 감수할 만한 엄청난 메리트가 있으니 바로 가격. 제일 싼 t2.nano의 시간당 비용은 0.0065달러... 한달내내 켜놔도(약 750시간) 약 5달러를 낸다. EBS볼륨은 유지한 상태로 인스턴스 타입을 바꾸는 게 가능하기 때문에 제일 싼 t2.nano 인스턴스로 먼저 시스템을 구축하고 나서 정상 작동 여부를 테스트한 뒤 위의 고성능 인스턴스로 바꿔서 재부팅하는 방법으로 요금을 아낄 수 있다. 다른 구식 호스팅 서비스에서는 서버를 두 대를 결제해서 데이터를 복사하는 방법(데이터 마이그레이션)이 유일한데 이렇게 하면 서버 두 대의 한 달치 요금을 중복 결제하게 되어 오히려 요금이 늘어난다.

  • 스팟 인스턴스 (Spot Instance)
    현재 사용되고 있지 않은 EC2 자원을 경매로 싸게 낙찰받아 이용할 수 있다. 수요가 증가하여 제시 가격보다 현재 시세가 높아질 경우 약 2분의 유예 기간을 준 뒤 인스턴스가 내려간다. t2.micro 같은 작은 인스턴스도 이 옵션을 사용할 수 있으며, 이 경우 온디맨드 가격인 0.0144$ 보다 훨신 싼 0.0046$에 인스턴스를 사용할 수 있다.
    언제 인스턴스가 내려가 버릴지 모르는 서비스인데 불안해서 어떻게 쓰냐 하고 생각할 수 있지만, 보통 스폿 인스턴스는 작업 결과를 S3 버킷 같은 데 쌓는 방식으로 사용한다. 그러다가 인스턴스가 내려가 버리면 위의 온 디맨드 인스턴스를 대신 켜서 하던 일 계속한다. 관리 비용이 증가하는 건 단점이지만 고성능 인스턴스의 스폿 경매 가격은 한가한 리전일 경우 반값 이하로 싼 경우가 많기 때문에 관리 비용을 충분히 상쇄하고도 남는다.

  • 예약 인스턴스 (Reserved Instance)
    사용할 기간(1년 혹은 3년)과 사용량(No/Partial/All Upfront)을 예약하면서 초기 선납비용을 내면, 시간당 사용료를 할인받는 방식.
    완전 선납 플랜을 사용하는 경우 시간당 사용료가 0이 된다. 가장 작은 t2.nano 인스턴스의 1년 완전 선납 가격은 2015년 12월 현재 38달러. 이게 월간이 아니라 연간 사용액이다!
    단, 이 예약 인스턴스는 '계약'의 형식이라 원칙적으로 환불이 안 되며 일단 결제하면 계약 기간동안 매월 할부 방식으로 돈이 빠져나간다. 인스턴스를 꺼놨어도 이 돈은 계약 만료시까지 계속 청구된다. 윗 문단의 설명도 그렇고 AWS 홈페이지의 설명도 저렇게 돼 있어서 마치 인스턴스를 꺼 놓으면 그 달은 결제 금액이 없는 것처럼 착각할 수 있는데 아니다. 청구서에는 매월 정액 요금이 빠져나간다. 단지 All Upfront는 일시불이고 No Upfront는 12개월 할부인 게 차이일 뿐. 원래 24시간 상시가동하는 인스턴스를 위해 있는 서비스이므로 인스턴스 사용 시간이 한 달에 300시간 미만(절반)이면 온 디맨드 인스턴스를 사용하는 게 가격적으로 더 유리하다.

3.1.2. EC2 Container Service[편집]

Docker 컨테이너로 구축하는 EC2 서비스

3.1.3. Elastic Beanstalk[편집]

웹 앱의 배포 및 관리 서비스

3.1.4. Lambda[편집]

이벤트가 발생하면 코드를 실행하는 일종의 앱 엔진. Serverless Architecture를 구축할 때 대부분 사용한다.

EC2에 올려서 서비스해야 하는 동적인 웹 서비스 부분을 여기에 올려두고 서비스할 수 있다. 꼭 웹이 아니더라도 S3에서의 트리거나 SQS에서의 메시지 수신 등 다양한 방법으로 Lambda서비스를 사용할 수 있다.

EC2에 비교해 장점은 Lambda는 해당 함수의 실행시간을 기준으로 과금한다는 것. 켜 놓은 시간이 아니다! 그래서 Lambda서비스는 사용을 안 하면 비용도 없다. 게다가 모든 고객에게(1년 체험 종료 고객 포함) 무료 용량을 제공한다. 개인 블로그 같은 매우 낮은 트래픽이 발생하는 웹 서비스를 구동할 경우 거의 무료에 가까운 가격으로 홈페이지를 운영할 수 있다. 다만 블로그 콘텐츠를 저장해야 하는 S3와 DynamoDB에서 요금이 발생하므로 완전 무료는 불가능하다. 그리고 사용 가능한 언어가 JavaScript, Python, Java 이 세 언어로 한정된다. PHP를 제공하지 않는 게 상당히 뼈아프다. PHP가 필요하면 구글 앱 엔진(GAE)을 사용할 수 있다.

저장 공간에서 비용이 발생하므로 이런 저장 공간을 무료로 제공하는 써드 파티 서비스(드롭박스 등)를 사용하면 완전무료로 운영하는 게 가능하다. 다만 S3 등의 서비스가 워낙 저렴해서 이런 식으로 비용을 줄이는 게 의미가 있을지는 미지수.

3.2. 스토리지[편집]

3.2.1. S3[편집]

무제한 용량을 제공하는 인터넷 스토리지 서비스

확장성이 뛰어나고 사용한 만큼만 비용을 지불한다. 버킷(Bucket)이라는 영역을 생성하고 데이터를 키-값 형식의 객체(Object)로 저장한다. 매우 저렴한 비용이 특징. 이 서비스를 활용하면 간단한 정적 웹 서비스를 만들어볼 수도 있다.

EC2가 컴퓨팅 카테고리의 근간 기술인 것처럼 이 S3서비스는 스토리지 카테고리의 근간을 이룬다. 계산은 EC2에서, 저장은 S3에서 처리하는 식. 단 파일 단위 액세스만을 지원하고 블록 단위 액세스가 불가능하다. 따라서 EBS(Elastic Block Storage, 일종의 가상 디스크)를 대체하지 못한다.

무료 용량은 없고 저장 공간만큼 매월 비용을 지불해야 한다. 하지만 EC2의 EBS처럼 미리 얼마의 공간을 구매하는 형식이 아니라 사용한 만큼만 비용을 지불하는 구조이다. 비용은 저장하는 데이터의 크기, 액세스 요청 횟수, 데이터 반출(네트워크 아웃)용량 등으로 계산된다.

http와 https 둘 다 지원하므로 가급적 https를 통해 s3에 액세스하도록 하자. 단 https를 사용할 경우 URL에 제약이 걸린다. 예를 들어 my.bucket.s3.amazonaws.com 이라는 URL은 인증서 에러가 나서 https://s3-us-west-2.amazonaws.com/my.bucket 이라고 버킷 이름을 URL 뒤로 넘기면서 버킷의 리전(region)을 구체적으로 지정해야 한다. 이런 제약이 신경쓰이면 아래의 CloudFront 서비스를 사용해 커스텀 도메인을 연결하자.

S3서비스 때문에 요금 폭탄을 맞는 일은 거의 없다. 테라바이트 이상의 데이터를 S3에 업로드해야 그제야 달러 단위의 비용이 청구되기 시작하는데 개인이 그만한 데이터를 갖고 있는 것 자체가 힘들다. AWS의 악명(?)은 켜 놓고 잊어버린 EC2 서비스에서 발생한 것이다.

2017년 5월 아마존 S3에 암호화 안한 미군측이 찍은 정찰위성이나 드론 사진들이 이리저리 신나게 나돌아다니는걸 누가 발견했다(...) 범인은 저 관련 정보기관과 일하던 회사(...)

3.2.2. CloudFront[편집]

세계 어디서나 빠른 속도로 파일을 제공하도록 최적화하는 Content Delivery Network(CDN) 서비스.[15] 위의 S3와 연계하면 이미지 서비스의 극을 달릴 수 있다. 제공해야 하는 콘텐츠가 공개 콘텐츠이고 정적 콘텐츠이면 무료인 Cloudflare 서비스가 있으므로 이쪽을 쓰는 게 유리하다. 나무위키의 콘텐츠 캐시도 클라우드플레어 서비스를 사용하고 있다. 이 서비스는 유료 콘텐츠를 제공할 때 비로소 빛을 발한다. 서명 URL이나 서명 쿠키를 사용해서 인증된 사용자에게만 콘텐츠를 배달하는 서비스를 할 수 있다.

꼭 파일 형태로 돼 있어야 서비스 가능한 것은 아니고 HTTP 요청을 보냈을 때 응답이 거의 일정한 모든 서비스에 사용할 수 있다. 예를 들어 검색 쿼리가 포함된 HTTP GET 요청 등이다. 단 캐시 불일치 문제를 적극적으로 해결해주지 않으므로 동시성이 중요한 곳에서는 사용해선 안 된다.

3.2.3. Elastic File System[편집]

사용량에 따라 과금되는 블록 스토리지[16]. NFS기반.

3.2.4. Glacier[편집]

본격 백업 전용 스토리지.

얼핏 S3와 비슷해 보이지만 S3가 개별 스토리지를 "Bucket"이라고 부르는 데 비해 이쪽은 그걸 "Vault"라고 부른다. 고리짝 옛날옛적 테이프 백업 시스템 느낌으로 일단 데이터가 들어갈 때는 마음대로인데 나올때는 그렇지가 못하다. 그래서 애초에 이름 부터가 빙하 (...)다.

대량의 데이터가 발생하는 환경에서 경우에 따라 LTO 테입 백업보다도 낮은 TCO를 보이기도 한다.[17]

유저들이 데이터를 전송하면, 적당히 모아뒀다가, 적절한 시점에 데이터센터 어딘가에 있는 냉동(?) 서버들에 정리해넣은 다음, 해당 서버들에서 다시 냉동(?) 스토리지로 전 세계에서 엄청난 양의 백업 데이터를 꾹꾹 채워 놓고나면, 해당 서버와 스토리지를 전부 Mothball 해버린다.[18]

이렇게 한참동안 방치(?) 하다가, 데이터 반출요청이 들어오면, 서버 전원을 켜서 파일 리스트를 보여주고, 요청한 데이터를 짱박아놓은 스토리지에서 긁어모은 다음, 다른 서버에 옮겨서 다운받을 수 있게 해 주는 식이다.[19] 일단 파일 리스트를 보려면 서버 전원을 켜고 전기를 넣어야만 하기 때문에 파일 리스트 보는 데만도 돈을 받는다. 일단 백업해 놨다면 진짜 핵이라도 떨어지지 않은 이상 존재를 잊도록 하자. 대신, 1기가당 월 1센트 라는 놀라운 염가에 서비스된다. 한번 쳐박아두면 정말 폴아웃스러운 상황이 닥치지 않는 이상 꺼내지 않을 것들을 저장해 둘 때 유용하다.

보통 기업 사용자 외에 일반 사용자는 위의 S3 서비스와 연계해서 Glacier 서비스를 사용한다. API를 직접 사용해서 사용하기에는 상당히 번거롭기 때문이다. S3에서 라이프사이클 옵션에 '며칠 뒤 Glacier로 이동'이라는 게 있는데 이걸 설정해 주면 편리하게 Glacier를 이용할 수 있다.

3.2.5. Snowball[편집]

대규모 데이터 이동 서비스. 일종의 (하드디스크) 택배 서비스이다.

3.2.6. Storage Gateway[편집]

로컬(사무실 등)의 저장소와 AWS의 저장소를 동기화해주는 서비스.

3.2.7. Snowmobile[편집]

페타바이트급의 방대한 데이터에 대한 이동 서비스. 무려 트럭으로(...)데이터를 받아 자사 클라우드에 업로드해준다.[20]

3.3. 데이터베이스[편집]

3.3.1. RDS[편집]

MySQL과 비슷한 관계형 데이터베이스 서비스.

EC2인스턴스 위에서 돌아가는 서비스이기 때문에 해당 EC2인스턴스의 시간당 요금을 지불한다. 데이터베이스 서비스 특성상 24시간 켜놔야 하므로 실험용으로 RDBMS를 사용하고자 할 경우 t2.nano인스턴스에 직접 MySQL을 깔아 쓰는 게 압도적으로 저렴하다. 이 서비스는 대용량 트래픽을 처리해야 하는 기업 사용자용이다. 혹 반드시 써야겠다면 예약 인스턴스를 구매하고 쓰도록 하자.

MariaDB, MySQL, Oracle 등 주요 데이터베이스 플랫폼을 선택할 수 있다. 이 서비스를 이용하면 Multi-AZ와 같은 기능을 손쉽게 사용 가능하다.

3.3.2. DynamoDB[편집]

MongoDB와 비슷한 NoSQL데이터베이스. 비슷한 서비스를 제공하는 Amazon RDS에 비해 가격이 매우 저렴하다. 다만 아주 소규모 데이터베이스가 필요한 경우 직접 EC2인스턴스에 MongoDB를 깔아서 운영하는 것보다 비싸질 수 있다. 참고로 1년 체험 기간 종료 고객을 포함한 모든 고객에게 25GB의 용량과 월간 2억 건 정도의 읽기/쓰기 요청에 대해서는 무료이다.

AWS에서 데이터베이스 카테고리를 대표하는 서비스이다. 다른 데이터베이스 서비스는 그냥 타사의 데이터베이스 기술을 EC2위에 얹어 놓은 것에 불과하지만 이 DynamoDB는 AWS에서 직접 지원하며 별도의 EC2인스턴스를 필요로 하지 않는다. 때문에 DynamoDB는 시간당이 아닌 사용량에 따라 과금된다.

또한 사용량이 늘어나면 자동으로 규모를 확장하고 사용량이 줄어들면 규모를 축소하는 기능이 있어서 따로 관리하지 않아도 탄력적으로 대응이 가능하다. 물론 수동으로 규모를 조정할 수도 있다.

밑의 RDS보다 다른 AWS 서비스와의 연동이 잘 된다. 예를 들어 SQS트리거라든지 Lambda연동 등.

RDBMS와 비교해 group by, order by, range query 기능이 많이 빈약하다. 보조 인덱스를 생성할 수 있고 정렬 키를 지정할 수도 있지만 인덱스 하나 추가할 때마다 비용이 청구되고 쿼리가 복잡해진다는 단점이 있다. 인덱스 복잡하게 설정하기 귀찮으면 DynamoDB의 데이터를 CloudSearch서비스와 연동시키는 방법이 있다. 이러면 적어도 '검색'하는 것은 자유롭게 할 수 있다. 다만 CloudSearch가 매달 최소 40달러 이상의 요금을 지불하므로(마이크로 검색 노드의 1개월치 요금) DynamoDB에서 테이블 풀-스캔으로 데이터를 검색하는 비용하고 비교를 잘 해야 한다. 사용자가 뭘 어떻게 검색할지 모르는 상황이라 온갖 필드에 인덱스를 주렁주렁 달아야 할 상황이라면 그 각각의 인덱스마다 비용이 청구되므로 CloudSearch가 더 저렴할 수 있다.

DynamoDB는 데이터를 샤딩(Sharding)해서 저장하는데 서로 다른 샤드에 대해서 order by를 사용할 수가 없다. 따라서 게시판 문서 데이터 같이 날짜를 기준으로 전체 레코드에 대해 order by를 할 일이 많은 데이터에 대해 DynamoDB를 사용하려면 일정 날짜 범위(일 단위를 예로 들면 20160603 이라는 '숫자')로 파티션 키(해시 키)를 생성하고 해당 해시 키의 정렬 키로 timestamp를 지정해서 쿼리하는 꼼수를 써야 한다. 이 '일별' 데이터는 같은 샤드에 저장되는 특징이 있기 때문에 년 단위 등 너무 큰 해시 키를 지정하면 DynamoDB의 성능이 크게 저하된다.

여기까지 보면 알겠지만 데이터의 '통계' 작업에는 DynamoDB가 적합하지 않다. 또한 사전에 계획하지 않은 검색 작업에도 취약하다. 데이터를 여러 기준으로 정렬하는 것도 RDBMS에 비해 아주 어렵다. 이런 게 자주 필요하면 밑의 RDS서비스를 사용하는 게 여러모로 낫다. 데이터가 특히 대용량이면 Redshift서비스를 사용해서 대규모 통계 연산을 처리할 수 있다. 극대규모 데이터는 EMR로 처리한다.

태그 검색 등 리스트에 대한 검색 작업을 처리해야 할 경우 CloudSearch를 사용하거나 자신이 직접 Reverse Index를 만들어야 한다. 다행히 DynamoDB에는 stream이라는 기능이 있어서 데이터가 변화할 때마다 Lambda함수를 호출하는 일을 할 수 있다.

3.3.3. ElastiCache[편집]

인-메모리 데이터베이스 서비스

Memcached와 Redis 중 하나를 선택할 수 있다. 이것도 위의 RDS서비스와 마찬가지로 EC2인스턴스 위에서 돌아가는 것이라 시간당 요금을 내야 한다. Memcached를 선택하면 노드를 증설할수록 더 많은 사용자를 수용할 수 있고 Redis를 선택하면 노드를 증설할수록 더 빠른 응답과 강력한 안정성을 제공받을 수 있다. 보통 인-메모리 데이터베이스는 노드 하나만 써도 충분히 빠르고 안정성은 애초에 기대하지 않는 경우가 많아(안정성을 원하면 RDS나 DynamoDB를 쓴다) Memcached를 주로 선택한다.

3.3.4. Redshift[편집]

데이터 웨어하우징. 정말 엄청난(페타바이트 규모) 데이터를 SQL로 다룰 때 사용한다. EMR은 아예 Hadoop이란 게 차이점.

3.3.5. DMS[편집]

데이터베이스 마이그레이션(이동) 서비스

3.4. 네트워크[편집]

3.4.1. VPC[편집]

가상 네트워크 구축 서비스. EC2 서버들간에 격리 구역을 만들 때 사용한다.

3.4.2. Direct Connect[편집]

고속 전용 네트워크 연결 서비스. 일종의 보장된 대역폭을 제공한다.

3.4.3. Route 53[편집]

DNS 서비스. 다만 API는 제공하는데 콘솔에는 메뉴가 없어서 좀 귀찮다. 대신 이걸 제어해주는 서드파티 웹 서비스가 있다.

구입한 도메인을 AWS의 서비스에 연결할 때 사용한다. 도메인을 EC2인스턴스 또는 기타 AWS서비스와 연결하는데 꼭 Route53을 사용할 필요는 없지만 통합 관리가 가능한 장점이 있다. 다만 단순히 도메인을 IP에 연결할 목적이라면 무료 DNS업체들이 있으니 그쪽을 사용하는 게 가격적으로는 더 유리하다. 물론 로드밸런싱 등의 고급 DNS설정이 필요한 경우에는 AWS의 서비스가 저렴하다.

3.5. 개발 도구[편집]

3.5.1. CodeCommit[편집]

Git 리포지토리 서비스

3.5.2. CodeDeploy[편집]

DevOps 서비스. 자동화된 코드 배포와 통합을 지원.

3.5.3. CodePipeline[편집]

Release Software using Continuous Delivery

3.6. 관리 도구[편집]

3.6.1. CloudWatch[편집]

로그(Log) 관리 서비스. EC2, Lambda, S3 등 다른 서비스에서 발생하는 로그 기록을 통합 관리.

3.6.2. CloudFormation[편집]

클라우드 구성 배포 서비스. 위 서비스의 '조합' 템플릿을 입력해 클라우드 인프라 자체를 패키징한다. Elastic Beanstalk와 비슷한 서비스.

3.6.3. CloudTrail[편집]

Track User Activity and API Usage

3.6.4. Config[편집]

Track Resource Inventory and Changes

3.6.5. OpsWorks[편집]

Automate Operation with Chef

3.6.6. Service Catalog[편집]

Create and Use Standardized Products

3.6.7. Trusted Advisor[편집]

컨설팅 서비스. AWS서비스를 최적화하고 결함을 찾아내는 등의 서비스. 일종의 기술지원 서비스이다.

3.7. 보안 및 인증[편집]

3.7.1. Identity & Access Management(IAM)[편집]

인증키 발급 서비스. 위의 서비스들을 연계해서 사용하기 위해 일종의 유저를 생성하는 서비스이다.

3.7.2. Directory Service[편집]

Acticve Directory 서비스. LDAP서비스이다.

3.7.3. Inspector[편집]

Analyze Application Security

3.7.4. WAF[편집]

웹 방화벽 서비스

3.7.5. Certificate Manager[편집]

SSL 인증서 관리 서비스. HTTPS 보안 웹 서버나 커스텀 도메인으로 CloudFront 서비스를 사용할 때 여기서 인증서를 등록한다. 또한 Elastic Beanstalk의 사용할 인증서도 여기서 등록하여 HTTPS로 배포할 수 있다.

3.8. 분석 및 통계[편집]

3.8.1. EMR[편집]

Hadoop 서비스

3.8.2. Data Pipeline[편집]

Orchestration for Data-Driven Workflows

3.8.3. Elasticsearch Service[편집]

루씬(Lucene)기반 검색엔진 서비스. 자연어검색이나 전문검색(Full text search)가 필요할 때 사용한다.

3.8.4. Kinesis[편집]

실시간 스트림 데이터 분석 서비스.

3.8.5. Machine Learning[편집]

Build Smart Applications Quickly and Easily

3.9. 사물 인터넷[편집]

3.9.1. AWS IoT[편집]

사물인터넷용 인터페이스를 제공하는 관리형 플랫폼 서비스

Shadow 기능을 통해 사물 디바이스의 네트워크 불안정 상태를 보완하고, Publish/Subscribe 구조를 따르는 MQTT 프로토콜을 통해 손쉽게 사물 인터넷을 개발해 볼 수 있다.

이 서비스를 API Gateway, Lambda와 연계하여 Serverless 아키텍처 디자인이 가능하다.

3.10. 게임 개발[편집]

3.10.1. GameLift[편집]

세션 기반 멀티플레이어 게임 개발 서비스

3.11. 모바일[편집]

3.11.1. Mobile Hub[편집]

모바일 앱 제작, 테스트, 모니터링 서비스

3.11.2. Cognito[편집]

인증 및 유저 데이터 동기화 서비스

3.11.3. Device Farm[편집]

iOS 및 안드로이드용 애플리케이션(웹 앱 포함) 테스트 서비스

3.11.4. Mobile Analysis[편집]

Collect, View and Export App Analysis

3.11.5. SNS[편집]

푸시 알림 서비스

3.12. 애플리케이션[편집]

3.12.1. API Gateway[편집]

RESTful API 구축 및 관리 서비스. API Endpoint를 정의해 각각의 서비스에 연결할 수 있다. 일종의 URL기반 라우터

3.12.2. AppStream[편집]

저지연 애플리케이션 스트리밍 서비스. 일종의 라이브스트리밍 서비스이다.

3.12.3. CloudSearch[편집]

클라우드 기반 검색 엔진. Apache Solr기반인데 Solr이 Lucene기반으로 만들어져 있어 결과적으로 위의 ElasticSearch와 비슷하다. ElasticSearch에 비해 좀 더 사용하기 편리하고 규모가변성 있는 검색 시스템을 구축할 수 있다. 그러나 가격은 ElasticSearch에 비해 다소 비싸다.

3.12.4. Elastic Transcoder[편집]

동영상 변환(트랜스코딩) 서비스. 고화질 동영상의 저화질 버전을 생성하거나 다른 동영상 포맷으로 변환해준다. S3와 연계하여 사용.

3.12.5. SES[편집]

대량 이메일 발송 서비스.

3.12.6. SQS[편집]

메시지 큐 서비스. RabbitMQ나 ZeroMQ와 비슷한 일을 한다.

3.12.7. SWF[편집]

Workflow Service for Coordinating Application Components

3.13. 기업용 애플리케이션[편집]

3.13.1. WorkSpace[편집]

가상 데스크톱 서비스

3.13.2. WorkDocs[편집]

문서 공유 서비스. 구글독스 비슷한 서비스이다.

3.13.3. WorkMail[편집]

기업용 이메일 서비스

3.14. 인공지능[편집]

3.14.1. Lex[편집]

텍스트 및 음성인식 기반 대화형 인공지능 서비스

3.14.2. Polly[편집]

텍스트 분석 및 음성 변환 서비스

3.14.3. Rekognition[편집]

지능형 이미지 분석 서비스

3.14.4. Machine Learning[편집]

4. 자격증[편집]

AWS 서비스는 초기 진입 장벽이 높은 편은 아니지만, 본격적으로 활용할 경우 어느정도 학습 곡선이 있는 편이다. 기존의 물리적 인프라에 각종 편의 기능까지 클라우드에 몽땅 때려박았으니 당연할수밖에 따라서 AWS 솔루션을 잘 활용하는 검증된 인력을 공급하기 위해 자격 인증 프로그램을 운영하고 있다.

의외로 공부해야 할 분량이 많고, 관련 분야에 대해 어느정도 기초 지식이 필요한 편이므로 유의.

  • AWS Certified Solutions Architect
    AWS 자격증 하면 일반적으로 많이 취득하는 자격증.
    Associate는 AWS상에 확장성, 가용성, 내결함성을 갖춘 시스템을 설계 및 배포하는 데 필요한 기술 전문성을 테스트하고, Professional은 분산 애플리케이션 및 시스템을 설계하는 데 필요한 고급 기술 및 경험을 테스트한다.

  • AWS Certified DevOps Engineer

  • AWS Certified Developer

  • AWS Certified SysOps Administrator

5. 참조[편집]

6. 국내 딜러[편집]

AWS의 비용 처리시 세금계산서가 필요하면 국내 딜러를 이용하면 된다.

7. 관련 문서[편집]


[1] 이것조차도 AWS에서 제공하는 API를 통해 구축된 것이다. 그래서 오히려 웹 관리 콘솔보다 API로 할 수 있는 것이 훨씬 많다.[2] 이 외에도 고가용성, 내결함성, 탄력성(확장성)을 끌어올리는 디자인 방법론을 학습한다.[3] Route 53이 이렇다.[4] 지금은 노스캐롤라이나에 지은 대형 데이터센터로 일부 이전한 상태[5] 현실적으로 수백대의 서버를 직접 구축해서 데이터 분석 등을 위해 이용하는데는 한계가 있으므로 이와 같은 클라우드 서비스를 이용하는 것이다.[6] 사용하는 만큼만 비용을 지불하고 트래픽을 모니터링 및 성능 조절을 자동화할 수 있는 특성상 초기 인프라 구축에 큰 돈을 들일 수 없는 스타트업이 사용하기 좋다.[7] AWS가 국내에 진출하기도 전에 이미 AWS 솔루션을 도입을 컨설팅해주는 회사도 있었다.[8] 심지어 AWS 얘기를 하면 "왜 서점 회사가 그런 걸 하나요?"라고 묻는 경우도 있었다고(...)[9] 추가로 한국지사가 설립되었으므로 2016년 1월 1일부터 대한민국 이용자에게 VAT가 부과되기 시작했다.[10] 넷플릭스가 한국에 진출하면서 생길 부하를 견디기 위해 설립됐다는 얘기도 있다. (넷플릭스의 모든 서비스는 AWS 기반으로 제공된다.) 실제로 AWS 한국 리전(Region)이 설립된 날이 넷플릭스가 한국에서 서비스를 시작한 날과 동일하다.[11] 가입 인증 메일의 헤더를 까보면 메일 서버 아이피가 워싱턴 D.C.에 있는 아마존 서버로 나온다.[12] "하하! 150명의 전 아마존 직원들(현 구글 직원)들은 7번이 내가 끼워넣은 농담이란 걸 알테지. 왜냐면 베저스는 자기가 삘 받은 날에 저런 좋은 말은 절대 하지 않으니까." - Stevey Yegge[13] EC2 기반에서 작동하지 않는 다른 서비스가 존재할 경우[14] 가끔씩 쓰는 인스턴스는 AMI를 만들어서 보관해두면 요금을 아낄 수 있다.[15] 아마존닷컴이 얼마나 많은 상품 사진을 서비스해야 하는지 생각해보자.[16] EC2의 EBS와는 달리 사용량만큼만 과금된다[17] 소니 픽처스 자회사는 비용절감을 위해 자사 영화 데이터 전체를 테이프 백업에서 이 서비스로 교체하기도 했다.[18] 서버 전원을 내려버린다거나... 데이터 손실 방지를 위한 최소한의 조치 외에는 그냥 하드를 뽑아다가 차곡차곡 창고에 쌓아놓는 느낌이다.[19] 그래서 파일을 꺼낼때 짧아도 24~48시간은 걸린다.[20] 유명 상업 위성사진 서비스 기업인 DigitalGlove사가 첫번째 이용자였다. 위성사진 라이브러리 전체를 AWS에 업로드시켜 머신러닝에 활용했다.[21] 책 내용이 모두 웹에 공개되어 있다.

로그가 누락된 본 문서의 기여자 내역은 다음과 같습니다. 해당 페이지를 참조해 주세요.