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

CEO	앤드류 제시
본사	미국 워싱턴 주 시애틀
창립	2006년
모기업	아마존닷컴
홈페이지 트위터 페이스북 블로그 트위치

1. 개요2. 배경3. 서비스

3.1. 컴퓨팅

3.1.1. EC23.1.2. Lightsail3.1.3. ECR(Elastic Container Registry)3.1.4. ECS(Elastic Container Service)3.1.5. EKS(Elastic Kubernetes Service)3.1.6. Lambda3.1.7. Batch3.1.8. Elastic Beanstalk3.1.9. Serverless Application Repository3.1.10. AWS Outposts

3.2. 스토리지

3.2.1. S33.2.2. Elastic File System3.2.3. FSx3.2.4. S3 Glacier3.2.5. Storage Gateway3.2.6. AWS Backup

3.3. 데이터베이스

3.3.1. RDS3.3.2. DynamoDB3.3.3. ElastiCache3.3.4. Neptune3.3.5. Amazon Redshift3.3.6. Amazon QLDB3.3.7. Amazon DocumentDB3.3.8. MCS(Managed Cassandra Service)

3.4. 마이그레이션 및 전송

3.4.1. AWS Migration Hub3.4.2. Application Discovery Service3.4.3. Database Migration Service3.4.4. Server Migration Service3.4.5. Snowball3.4.6. DataSync

3.5. 네트워킹 및 콘텐츠 전송

3.5.1. VPC3.5.2. CloudFront3.5.3. Route 53

3.5.3.1. DNS3.5.3.2. Registar3.5.3.3. Health Check

3.5.4. API Gateway3.5.5. Direct Connect3.5.6. AWS App Mesh3.5.7. AWS Cloud Map3.5.8. Global Accelerator

3.6. 개발 도구

3.6.1. CodeCommit3.6.2. CodeDeploy3.6.3. CodeBuild3.6.4. CodeDeploy3.6.5. CodePipeline3.6.6. Cloud93.6.7. X-Ray

3.7. 관리 및 거버넌스

3.7.1. CloudWatch

3.7.1.1. Logs3.7.1.2. Metrics3.7.1.3. Events

3.7.2. CloudFormation3.7.3. CloudTrail3.7.4. Config3.7.5. OpsWorks3.7.6. Service Catalog3.7.7. Trusted Advisor

3.8. 미디어 서비스

3.8.1. Elastic Transcoder

3.9. Machine Learning

3.9.1. Lex3.9.2. Polly3.9.3. Rekognition

3.10. 분석

3.10.1. EMR3.10.2. CloudSearch3.10.3. ElasticSearch Service3.10.4. Kinesis3.10.5. Data Pipeline

3.11. 보안, 자격 증명 및 규정 준수

3.11.1. (IAM)Identity & Access Management3.11.2. Cognito3.11.3. Inspector3.11.4. Directory Service3.11.5. ACM(Amazon Certificate Manager)3.11.6. WAF & Shield

3.11.6.1. WAF3.11.6.2. Shield

3.11.6.2.1. Shield Advanced

3.12. 사물 인터넷

3.12.1. IoT Core

3.13. 모바일

3.13.1. Mobile Hub3.13.2. Device Farm

3.14. 애플리케이션 통합

3.14.1. Simple Notification Service3.14.2. Simple Queue Service3.14.3. SWF

3.15. 고객 참여

3.15.1. SES

3.16. 비즈니스 애플리케이션

3.16.1. WorkMail

3.17. 최종 사용자 컴퓨팅

3.17.1. WorkSpace3.17.2. AppStream3.17.3. WorkDocs

3.18. 게임 개발

3.18.1. GameLift

3.19. 기타

3.19.1. Windows Server용 EMP

4. 자격증5. 사고6. 참조7. 국내 딜러8. 기타9. 관련 문서

1. 개요[편집]

아마존닷컴의 클라우드 컴퓨팅 사업부. 현재 클라우드 분야에서 압도적인 세계 1위의 점유율을 차지하고 있다.

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

웹 관리 콘솔(Management Console)이 제공되어 이곳에서 제품들을 클릭 몇 번으로 간단하게 제어하는 것도 가능한데, 이것조차도 AWS에서 제공하는 API를 통해 구축된 것이다. 그래서 오히려 웹 관리 콘솔보다 API로 할 수 있는 것이 훨씬 많다.

아마존의 모든 기능을 원하는대로 자동화할 수 있어 가능한 얼마든지 비용을 줄이는 방향으로 최적화할 수 있다. ~~물론 솔루션 아키텍트의 역량에 달렸지만...~~ 심지어 아마존에서도 이런 식으로 비용을 절감하여 사용할 것을 적극 권장하는데, 실제로 AWS 공인 솔루션 아키텍트 과정에서는 AWS 서비스를 비용 효율적인 아키텍처로 구축하는 모범 사례와 고가용성, 내결함성, 탄력성(확장성)을 끌어올리는 디자인 방법론에 대해서 학습한다.

힘들게 비싼 돈주고 서버 사고 IDC에 넣고 골치썩을 일 없이 쓴 만큼만 아마존에 내면 땡이기 때문에, 가진 게 아이디어하고 두뇌밖에 없는 실리콘 밸리 워너비 스타트업들이 사업 시작할 때 가장 많이 쓰는 서비스가 되었다. 심지어 AWS 위에다가 클라우드 서비스를 재구성해서 다른 개발자나 기업한테 팔아먹는 식의 서비스까지 생겨날 정도가 되었으며, API는 있는데 AWS 웹 콘솔이 지원하지 않는 기능을 Route 53의 사례처럼 자기들이 콘솔로 만들어서 서비스하기까지 한다.(...) 작은 기업들만 쓰는 것도 아닌 게, 애플의 iCloud도 Google Cloud Platform과 AWS를 사용하는 것으로 유명하다.[1] AWS가 뻑나면 iCloud 전체가 뻑난다는건 주지의 사실. 그리고 해외의 유명 대학에서는 연구를 위해 IT인프라를 자체 확보하지 않고 AWS나 Microsoft Azure, Google Cloud Platform을 쓰는 경우도 점차 늘고 있다. 현실적으로 수백대의 서버를 직접 구축해서 데이터 분석 등을 위해 이용하는데는 한계가 있으므로 이와 같은 클라우드 서비스를 이용하는 것이다.

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

2016년 이전까지는 국내에 AWS 데이터 센터가 존재하지 않아서 가장 가까운 도쿄 리전(Region)에 인스턴스를 생성해서 사용해왔는데, AWS 수요가 급격히 늘어서 이에 대응해 2016년 서울 리전(Region)이 설립되었다. 따라서 아시아 한정으로 일본, 싱가폴, 그리고 대한민국 총 세 곳에서 AWS 리전(Region)이 운영되고 있다. 호주는 논외. 추가로 한국지사가 설립되었으므로 2016년 1월 1일부터 대한민국 이용자에게 VAT가 부과되기 시작했다. 넷플릭스가 한국에 진출하면서 생길 부하를 견디기 위해 설립됐다는 얘기도 있다. (넷플릭스의 모든 서비스는 AWS 기반으로 제공된다.) 실제로 AWS 한국 리전(Region)이 설립된 날이 넷플릭스가 한국에서 서비스를 시작한 날과 동일하다. 아마존 웹 서비스 한국 블로그

참고로 나무위키의 메일 서버가 이곳을 사용하고 있으며 가입 인증 메일의 헤더를 까보면 메일 서버 아이피가 워싱턴 D.C.에 있는 아마존 서버로 나온다. 배틀그라운드 게임 서버도 이곳을 이용하는 것으로 확인되었다. 트위치 역시 아마존닷컴에게 인수된 뒤로는 AWS 서버를 사용하고 있다.[4]

2. 배경[편집]

아마존은 미국의 블랙 프라이데이 같은 대형 이벤트에 걸리는 부하를 감당하기 위해 많은 양의 서버를 가지고 있었고 평소에 남는 서버를 이를 외부에 빌려주는 사업을 시작했다는 설이 있으나, 아마존닷컴 CTO인 버너 보겔스는 "AWS는 독자적인 주문형 컴퓨팅 사업을 기획하여 시작했으며, 서비스 시작 후 2개월만에 이미 당시 아마존닷컴의 총 컴퓨팅 용량을 넘었다"라고 직접 밝혔다. ※출처-Quora 만약 남는 용량을 빌려 주는 사업이었다면, 매해 11-12월과 같은 모자라는 시점에는 어떻게 외부 고객에 서비스해야하는지 생각만 해보더라도 불가능한 사업 방식임을 알 수 있다.

버너 보겔스는 "경험을 통해 기존의 다중 데이터 센터 모델에서 안정적이고 확장 가능한 인프라를 유지 관리하는 데 드는 비용은 시간과 노력 모두에서 컴퓨팅 활용도를 최대 70%가 될 수 있으며, 이를 장기간 유지하기 위해서는 상당한 자본 투자가 필요하며, 비용을 30% 이하로 줄일 수있는 서비스를 제공할 수 있었다. 당시 외부 기업 및 스타트업의 서버 활용도는 통상 10-20% 미만이어서, 종량 요금제를 사용하면 사업이 가능하다고 판단했다. AWS는 2006년 봄에 첫 번째 스토리지 서비스(Amazon S3)를, 그해 가을에 컴퓨팅 (Amazon EC2)을 제공"하기 시작했다.

AWS가 왜 아래 후술할 수많은 서비스들을 API로 제공하게 되었는가 하면, 이미 아마존닷컴 자체가 그렇게 존재하고 있기 때문이다. 아마존닷컴의 모든 기능은 API로 서로 통신하는 서비스 지향 아키텍처SOA, 오늘날로 치면 마이크로서비스 아키텍처로 구성되어 있었다. 클라우드 사업을 펼치기에 유리한 상태였던 것이다.

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

모든 팀들은 데이터와 기능들을 서비스 인터페이스로 연결시켜라.
팀들은 이 인터페이스를 통해서 연락해야 한다.
다른 어떤 커뮤니케이션 방법도 허용되지 않는다. 직접 링크를 보내거나 다른 팀의 스토리지에 직접 액세스 해서도 안 되며, 공유 메모리나 백도어 같은 것도 안 된다. 모든 커뮤니케이션은 네트워크를 통한 서비스 인터페이스로 이루어져야 한다.
어떤 기술을 쓰든 상관없다. HTTP, Cobra, Pubsub, 독자 프로토콜...그건 상관없다. 베조스는 그런 데 관심 없다.
모든 서비스 인터페이스는 예외 없이 외부에서 이용 가능하게 만들어져야 한다. 그 말은 팀들은 외부 개발자들이 인터페이스를 이용할 수 있게 해야 한다는 것이다. 예외는 없다.
이를 실천하지 않는 사람은 누구든 해고될 것이다.
~~읽어줘서 고맙다. 좋은 하루가 되길.~~[5]

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

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

3. 서비스[편집]

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

3.1. 컴퓨팅[편집]

3.1.1. EC2[편집]

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

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

셸이나 SFTP 접속은 별도의 인증서를 사용해서 이루어진다. 그래서 인증서 로그인 기능이 없는 알드라이브나 EditPlus 등에서는 이용이 불가능하다. 셸에는 Xshell이나 PuTTY 같은 제품을, FTP 접속은 Xftp나 FileZilla 등의 제품을 사용하면 접속이 가능하다.

온 디맨드 인스턴스 (On-Demand Instance)
사용한 만큼 과금된다. 단, 과금의 단위가 1분이기 때문에 1초를 사용해도 1분 어치가 과금된다. 다른 회사의 호스팅 서비스는 1초를 사용하려 해도 1개월어치를 선불로 낸다. 2019년 현재는 Google Cloud Platform의 Compute Engine도 분 단위로 과금된다.
그리고 인스턴스(서버)를 켜 놓은 시간으로 과금되기 때문에 고성능 인스턴스를 켜 놓고 잊어버리면 월말에 어마어마한 요금 폭탄을 맞게 된다. 서버에 접속한 시간 기준이 아니라 켜 놓은 시간 기준이다. 따라서 안 쓰는 인스턴스는 반드시 Stop시켜야 한다. Stop한 인스턴스도 EBS 스토리지(인스턴스가 저장된 가상 디스크) 1GB당 0.1달러(SSD 기준)를 매달 지불하므로 다시 켤 일이 없는 인스턴스는 Terminate시켜서 완전히 삭제하고 해당 인스턴스가 사용한 모든 EBS 볼륨도 지워줘야 한다.[6] 보통 Terminate시키면 EBS 볼륨도 자동으로 삭제되지만 옵션에서 이걸 막을 수 있게 돼 있으므로 확인은 필수.
그러나, 이런 번거로움을 감수할 만한 엄청난 메리트가 있으니 바로 가격이다. 대표적으로 t3.nano의 시간당 비용은 0.0065달러... 한달내내 켜놔도(약 750시간) 약 5달러를 낸다. EBS 볼륨은 유지한 상태로 인스턴스 타입을 바꾸는 게 가능하기 때문에 제일 싼 t3.nano 인스턴스로 먼저 시스템을 구축하고 나서 정상 작동 여부를 테스트한 뒤 고성능 인스턴스로 바꿔서 재부팅하는 방법으로 요금을 아낄 수 있다.[7] 다른 구식 호스팅 서비스에서는 서버를 두 대를 결제해서 데이터를 복사하는 방법(데이터 마이그레이션)이 유일한데 이렇게 하면 서버 두 대의 한 달치 요금을 중복 결제하게 되어 오히려 요금이 늘어난다.
스팟 인스턴스 (Spot Instance)
현재 사용되고 있지 않은 EC2 자원을 경매로 싸게 낙찰받아 이용할 수 있다. 수요가 증가하여 제시 가격보다 현재 시세가 높아질 경우 약 2분의 유예 기간을 준 뒤 인스턴스가 내려간다. t3.micro 같은 작은 인스턴스도 이 옵션을 사용할 수 있으며, 이 경우 온디맨드 가격인 0.0144$ 보다 훨씬 싼 0.0046$에 인스턴스를 사용할 수 있다.
언제 인스턴스가 내려가 버릴지 모르는 서비스인데 불안해서 어떻게 쓰냐 하고 생각할 수 있지만, 보통 스팟 인스턴스는 작업 결과를 S3 버킷 같은 데 쌓는 방식으로 사용한다. 그러다가 인스턴스가 내려가 버리면 위의 온 디맨드 인스턴스를 대신 켜서 하던 일 계속한다. 관리 비용이 증가하는 건 단점이지만 고성능 인스턴스의 스팟 경매 가격은 한가한 리전일 경우 반값 이하로 싼 경우가 많기 때문에 관리 비용을 충분히 상쇄하고도 남는다.
예약 인스턴스 (Reserved Instance)
사용할 기간(1년 혹은 3년)과 사용량(No/Partial/All Upfront)을 예약하면서 초기 선납비용을 내면, 시간당 사용료를 할인받는 방식.
완전 선납 플랜을 사용하는 경우 시간당 사용료가 0이 된다. 가장 작은 t3.nano 인스턴스의 표준 1년 완전 선납 가격은 32달러. 이게 월간이 아니라 연간 사용액이다!
단, 이 예약 인스턴스는 '계약'의 형식이라 원칙적으로 환불이 안 되며 일단 결제하면 계약 기간동안 매월 할부 방식으로 돈이 빠져나간다. 인스턴스를 꺼놨어도 이 돈은 계약 만료시까지 계속 청구된다. 윗 문단의 설명도 그렇고 AWS 홈페이지의 설명도 저렇게 돼 있어서 마치 인스턴스를 꺼 놓으면 그 달은 결제 금액이 없는 것처럼 착각할 수 있는데 아니다. 청구서에는 매월 정액 요금이 빠져나간다. 단지 All Upfront는 일시불이고 No Upfront는 12개월 할부인 게 차이일 뿐. 원래 24시간 상시가동하는 인스턴스를 위해 있는 서비스이므로 인스턴스 사용 시간이 한 달에 300시간 미만(절반)이면 온 디맨드 인스턴스를 사용하는 게 가격적으로 더 유리하다.

메일 포트(25번)가 기본적으로 막혀 있다. 스팸메일 보내는 용도로 악용되는 것을 막기 위해 차단한 듯. 아예 못 쓰는 것은 아니고 따로 신청하면 풀어준다. # EC2 뿐만 아니라 아래 Lightsail도 같은 정책이 적용된다.

3.1.2. Lightsail[편집]

EC2보다 간소화된 VPS 서비스로, 대다수 VPS 서비스 업체에서 염가로 제공하는 서비스와 비슷한 형태이다. EC2와 달리 월정액 과금 시스템이라 돈계산도 비교적 편하다. 리눅스/유닉스 인스턴스와 같은 제공 사양에 그보다 약간 비싼 윈도우 인스턴스를 사용할 수 있다. 5개의 무료 고정 IP, 3개의 무료 DNS, 최대 20TB 블록스토리지, 5개의 로드 밸런서, 20개의 SSL 인증서를 제공한다. # 리눅스는 Amazon Linux와 CentOS, Ubuntu를 설치할 수 있다.

그리고 서울에 리전이 있다. 다른 해외 업체에서는 가까워봐야 도쿄가 제일 가까운데, 서울에 리전이 있다는 것은 한국 이용자들에게는 특장점. 다만 경쟁업체 중 하나라고 할 수 있는 Vultr도 2020년 5월 12일에 서울 리전을 개설했다. 또한 최근에 가격을 인하하여 최저 인스턴스(512MB RAM, 20GB SSD, 1TB 아웃풋 트래픽)가 월 3.5달러밖에 하지 않는다. ~~아마존 이외 VPS 사업자들 망하는 소리 들린다~~ ~~그나마 Vultr가 대응한다고 3.5달러 플랜을 추가하긴 했는데, 아마존이 더 스펙이 좋다(...)~~ EC2와는 약간 독립적인 서비스라서 UI도 좀 다르고, 한동안 AWS 크레딧도 사용이 불가능했다. (현재는 크레딧 사용가능)

웹 서버 돌리기에는 꽤 괜찮은 서비스다. 트래픽도 상당히 후하다. 최저 인스턴스인 3.5달러 짜리가 무려 한 달에 1TB 트래픽을 주는데, 국내에 비슷한 가격으로 이 트래픽 주는 데가 없다.

다만 서비스 구매시 같이 달려오는 수두룩한 부가 서비스와는 별개로, 서버 그 자체의 성능은 조금 아쉬운 편이다. $20/월 플랜에서도 디스크 쓰기 속도가 60MB/s(...)로 나오며, 다른 회사들 중에서 Digital Ocean을 예시[8]로 들자면 350MB/s, 4달러 올려서 1000MB/s를 뽑는 Vultr[9]와 확실히 비교되는 부분이라 여러모로 조금 아쉬운 편. CPU 성능도 다른 서비스에 비해 많이 딸리는 편으로, 모든 플랜의 CPU가 가상 CPU라 다른 사용자와 공유하고, 성능도 경쟁사에 비해 상당히 떨어지는 편이라 중대형 서비스를 돌리기에는 부적합하다. 차라리 부가 서비스들을 최소한으로 하고 서버 스펙에 치중한 다른 Lightsail의 비슷한 서비스를 개설하는게 나아보인다는 평도 있다.

백업은 스냅샷을 이용하는데, 매일 1회씩 7일까지 보관되는 자동 스냅샷을 설정할 수 있다. 스냅샷 과금은 한 달에 1 GB당 0.05달러.

주의할 점으로 고정 IP를 연결을 해두는 것으로 과금이 발생하지 않지만 연결하지 않은 고정 IP에 대해서는 소정의 과금이 발생하므로(첫 1시간 무료, 이후 시간당 0.005$, 750시간 기준 3.75$~~512MB 요금제보다 비싸다(...)~~) 사용하지 않는 고정IP는 반드시 삭제해둬야 한다.

3.5 달러짜리 최저 인스턴스는 1개월 동안 무료로 제공한다.

3.1.3. ECR(Elastic Container Registry)[편집]

컨테이너 이미지를 저장, 관리 및 배포하는 서비스

3.1.4. ECS(Elastic Container Service)[편집]

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

3.1.5. EKS(Elastic Kubernetes Service)[편집]

완전 관리형 Kubernetes 제어 서비스

3.1.6. Lambda[편집]

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

JavaScript, Python, Java, C#, Go, Java, Ruby, .NET Core를 사용할 수 있다.

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

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

PHP를 애용하는 유저에 한하여 PHP를 지원하지 않는다는 점은 아쉬운 부분이다. PHP가 필요하면 구글 앱 엔진(GAE)을 사용할 수 있다.

3.1.7. Batch[편집]

대규모 배치 컴퓨팅 워크로드 처리 서비스

3.1.8. Elastic Beanstalk[편집]

웹 앱의 배포 및 관리 서비스

3.1.9. Serverless Application Repository[편집]

AWS에서 구성 가능한 서버리스 애플리케이션을 배포할 수 있다.

아직 한국어로는 번역이 고르지 못 한 편이다.

3.1.10. AWS Outposts[편집]

금융, 정부 등의 중요 데이터를 클라우드에 배치할 수 없는 케이스를 고려하여 On-premise에서 AWS 서비스를 그대로 사용할 수 있게 확장해 주는 서비스이다.

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에 암호화 안한 미군측이 찍은 정찰위성이나 드론 사진들이 이리저리 신나게 나돌아다니는걸 누가 발견했다(...) 범인은 저 관련 정보기관과 일하던 회사(...)[10]

3.2.2. Elastic File System[편집]

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

3.2.3. FSx[편집]

고성능 파일 시스템의 생성 과정을 간소화한 서비스

3.2.4. S3 Glacier[편집]

본격 백업 전용 스토리지.

얼핏 S3와 비슷해 보이지만 S3가 개별 스토리지를 "Bucket"이라고 부르는 데 비해 이쪽은 그걸 "Vault"라고 부른다. 테이프 기반 백업 서비스이기 때문에 인바운드는 편하게 할 수 있지만 아웃바운드는 시간이 오래 걸린다. 그래서 애초에 이름 부터가 빙하 (...)다.

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

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

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

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

일반 사용자에겐 그다지 메리트가 없는 서비스인데, 저장비용은 상당히 낮으나 유사시 이를 반출하기가 상당히 까다롭기 떄문이다. 위에도 나와있듯이 파일 리스트를 보는데만도 벌크검색 5시간, 표준검색 3시간이 소요되며. 긴급검색을 요청시 15분 이내로 리스트를 볼 수 있지만 가격이 상당히 비싸다. 또한 반출시에는 0.126 달러 / GB 의 요금이 부과되고 다운로드 받는 속도도 상당히 느리다. 따라서 일반사용자의 백업 & 복구 용도로의 사용으로는 적절하지 않으며, 다른 서비스를 이용하는 것이 바람직하다고 볼 수 있다.

마지막으로, 데이터를 업로드한지 3개월 이내에 삭제시 별도의 삭제 요금이 부과된다.

3.2.5. Storage Gateway[편집]

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

3.2.6. AWS Backup[편집]

AWS 서비스를 백업하고 중앙 관리하는 서비스이다.

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. Neptune[편집]

그래프를 위한 데이터베이스 서비스

3.3.5. Amazon Redshift[편집]

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

3.3.6. Amazon QLDB[편집]

투명하고, 변경 불가능하며, 암호화 방식으로 검증 가능한 트랜잭션 로그를 포함하는 중앙 데이터베이스

3.3.7. Amazon DocumentDB[편집]

MongoDB와 호환되는 고가용성, 완전 관리형 문서 기반 데이터베이스 서비스

3.3.8. MCS(Managed Cassandra Service)[편집]

확장 가능한 고가용성의 관리형 Apache Cassandra 호환 데이터베이스 서비스

3.4. 마이그레이션 및 전송[편집]

3.4.1. AWS Migration Hub[편집]

On-premise를 AWS로 이전하는 것을 돕는 종합 서비스

3.4.2. Application Discovery Service[편집]

On-premise 환경의 서버의 시스템 특성, 성능, 종속성 그리고 유용한 정보를 수집하는 서비스

3.4.3. Database Migration Service[편집]

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

3.4.4. Server Migration Service[편집]

On-premise를 AWS로 이전하는 것을 돕는 서비스

3.4.5. Snowball[편집]

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

3.4.6. DataSync[편집]

데이터 이전을 간소화, 자동화 그리고 가속화하는 서비스

3.5. 네트워킹 및 콘텐츠 전송[편집]

3.5.1. VPC[편집]

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

3.5.2. CloudFront[편집]

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

꼭 파일 형태로 돼 있어야 서비스 가능한 것은 아니고 HTTP 요청을 보냈을 때 응답이 거의 일정한 모든 서비스에 사용할 수 있다. 예를 들어 검색 쿼리가 포함된 HTTP GET 요청 등이다.

정적 컨텐츠 (이미지, 동영상, 오디오, HTML 문서 등)에 최적화되어 있고 동적 컨텐츠 (웹 어플리케이션)를 캐싱하면 HTML 문서로 변환되므로 캐싱 불일치 문제가 발생한다.

캐싱 용도 이외에도 단순히 접속자와 서버 간의 라우팅 경로를 최적화하기 위해 CloudFront를 사용할 수도 있다.

3.5.3. Route 53[편집]

DNS 및 도메인 서비스

3.5.3.1. DNS[편집]

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

3.5.3.2. Registar[편집]

도메인 구입 및 관리도 지원하는데, 가격이 다른 국내 업체보다는 비싼 편이다. .com이 1년에 12달러, .net이 11달러다.

kr 도메인은 취급하지 않는다.

3.5.3.3. Health Check[편집]

Endpoint의 상태를 체크하여 Route53 DNS에서 활용하거나 SNS와 활용하여 문자, 이메일 알림 또는 Lambda 함수 트리거 등이 가능하다.

3.5.4. API Gateway[편집]

HTTP 요청으로 Lambda 이벤트를 생성, HTTP Proxy, 기타 AWS 서비스와 연결 그리고 VPC 링크로의 연결을 가능케하는 서비스이다.

Lambda와 함께 Serverless Architecture를 구성하는 핵심 요소이다.

3.5.5. Direct Connect[편집]

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

3.5.6. AWS App Mesh[편집]

마이크로서비스 모니터링 및 제어 서비스

3.5.7. AWS Cloud Map[편집]

클라우드 리소스에 대한 서비스 검색 지원

3.5.8. Global Accelerator[편집]

서비스의 가용성 및 성능을 개선해 주는 서비스이다.

전 세계에 Anycast로 Endpoint를 구성하여 Request를 로드 밸런싱한다.

3.6. 개발 도구[편집]

3.6.1. CodeCommit[편집]

Git 리포지토리 서비스

3.6.2. CodeDeploy[편집]

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

3.6.3. CodeBuild[편집]

코드 컴파일, 테스트 및 배포를 자동화하는 완전 관리형 서비스이다.

3.6.4. CodeDeploy[편집]

다양한 컴퓨팅 서비스의 배포를 자동화하는 완전 관리형 서비스이다.

3.6.5. CodePipeline[편집]

Release Software using Continuous Delivery

3.6.6. Cloud9[편집]

온라인 코드 IDE 이다.

3.6.7. X-Ray[편집]

요청 트레이스, 예외 수집 및 프로파일링 기능을 통해 배포한 애플리케이션의 동작을 분석하는 서비스이다.

3.7. 관리 및 거버넌스[편집]

3.7.1. CloudWatch[편집]

3.7.1.1. Logs[편집]

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

3.7.1.2. Metrics[편집]

지표 모니터링 서비스이다.

3.7.1.3. Events[편집]

이벤트 또는 일정에 의해 대상을 트리거하는 서비스이다.

3.7.2. CloudFormation[편집]

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

3.7.3. CloudTrail[편집]

사용자 활동 및 API 추적 서비스이다.

3.7.4. Config[편집]

Track Resource Inventory and Changes

3.7.5. OpsWorks[편집]

Automate Operation with Chef

3.7.6. Service Catalog[편집]

Create and Use Standardized Products

3.7.7. Trusted Advisor[편집]

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

3.8. 미디어 서비스[편집]

3.8.1. Elastic Transcoder[편집]

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

3.9. Machine Learning[편집]

3.9.1. Lex[편집]

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

3.9.2. Polly[편집]

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

3.9.3. Rekognition[편집]

지능형 이미지 분석 서비스

3.10. 분석[편집]

3.10.1. EMR[편집]

Hadoop 서비스

3.10.2. CloudSearch[편집]

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

3.10.3. ElasticSearch Service[편집]

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

3.10.4. Kinesis[편집]

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

3.10.5. Data Pipeline[편집]

Orchestration for Data-Driven Workflows

3.11. 보안, 자격 증명 및 규정 준수[편집]

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

AWS 서비스에 접근할 권한을 세분화하는 서비스이다.

Root 계정 대신 IAM을 통해 제한적인 권한을 부여하여 조직적인 관리를 가능하게 한다.

3.11.2. Cognito[편집]

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

3.11.3. Inspector[편집]

Analyze Application Security

3.11.4. Directory Service[편집]

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

3.11.5. ACM(Amazon Certificate Manager)[편집]

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

3.11.6. WAF & Shield[편집]

3.11.6.1. WAF[편집]

웹 방화벽 서비스이다. CloudFront와 연계하여 사용할 수 있다.

3.11.6.2. Shield[편집]

유해 트래픽 차단 서비스이다.

3.11.6.2.1. Shield Advanced[편집]

고성능 유해 트래픽 차단 서비스이다.

이 서비스를 이용하면 자신의 Endpoint에 들어오는 공격 뿐만 아니라 AWS에서 얼마나 많은 규모의 공격을 처리하고 있는지 볼 수 있다.

공격이 발생하면 처리 프로세스가 나타나서 시각적으로 공격을 인지할 수 있다.

3.12. 사물 인터넷[편집]

3.12.1. IoT Core[편집]

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

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

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

3.13. 모바일[편집]

3.13.1. Mobile Hub[편집]

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

3.13.2. Device Farm[편집]

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

3.14. 애플리케이션 통합[편집]

3.14.1. Simple Notification Service[편집]

AWS 서비스 통합에 도움을 주는 서비스이다.

알림 수단으로는 이메일 및 문자 등의 알림 수단을 지원한다.

단순 알림 서비스에 불과한 것은 아니고 각종 이벤트를 SNS에서 Lambda로 연결하여 Lambda 함수를 실행할 수 있다.

3.14.2. Simple Queue Service[편집]

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

3.14.3. SWF[편집]

Workflow Service for Coordinating Application Components

3.15. 고객 참여[편집]

3.15.1. SES[편집]

대량 이메일 발송 서비스.

3.16. 비즈니스 애플리케이션[편집]

3.16.1. WorkMail[편집]

기업용 이메일 서비스

3.17. 최종 사용자 컴퓨팅[편집]

3.17.1. WorkSpace[편집]

가상 데스크톱 서비스

3.17.2. AppStream[편집]

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

3.17.3. WorkDocs[편집]

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

3.18. 게임 개발[편집]

3.18.1. GameLift[편집]

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

3.19. 기타[편집]

3.19.1. Windows Server용 EMP[편집]

(End-of-support Migration Program), 줄여서 EMP는 Windows Server 레거시 환경에서 구동하기 위해 개발 된 애플리케이션을 코드 변경 없이 AWS의 최신 Windows Server에서 구동할 수 있게 변환해 주는 서비스이다.

Windows Server 2003, 2008 및 2008 R2의 레거시 애플리케이션을 리팩토링 없이 AWS에서 지원되는 최신 버전으로 마이그레이션하기 위한 기술 및 전문가 지침이 포함되어 있다고 한다.

4. 자격증[편집]

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

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

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

5. 사고[편집]

2018년 11월 22일 아침에 한국서버가 1시간 30분 정도 먹통이 되었다. AWS 한국 블로그에 게재된 글에 따르면, 사고 발생 직후 "이슈가 발생되는 동안 고객에게 거의 실시간으로 정보를 제공하는 방법"인 AWS 서비스 대시보드 및 로그인 시 보이는 개인 대시보드에 고지하였으며 이는 클라우드 업계의 표준 고지 방법이라고 주장하였다. 또한, 사고 2일후 게재된 예비 조사 결과에서 대고객 사과 고지를 하였으며, 이번 사고로 영향을 받은 모든 고객의 서울 리전의 11월 EC2 청구 항목에 대해 10%를 환불을 진행하였다. 과학기술정보통신부 역시 "아마존웹서비스(AWS)가 서비스 장애 고지 관련 클라우드컴퓨팅법을 준수한 것으로 잠정 결론"을 내렸다.

아마존웹서비스 장애에 韓 업체 줄줄이 '먹통'…"사과 한 마디 없어" - 노컷뉴스
"재난에도 중단 없다" 더니···아마존 먹통, 한국만 멈췄다 - 중앙일보
'세계1위의 민낯'…아마존, 장애피해 속출에도 공지조차 없어 - 뉴스1
AWS '역대급 장애'에도 사과 없어.."운영·보안 최고 무색" - 뉴시스
"84분 정도 갖고..." 아마존웹서비스 인터넷 장애 사과·보상 '모르쇠' - 조선비즈
신뢰 금 간 '아마존 웹서비스'…"사과는커녕 오류 사실도 알리지 않았다" - 머니투데이방송
AWS코리아, 정부 클라우드 장애 사고 조사에도 배짱 - 전자신문
한달 멈춰도 30% 환불…韓기업들 아마존 불공정계약 '속앓이' - 뉴스1
'아마존의 갑질'…먹통 만들어놓고 "기술문의 비용10% 더 내" - 뉴스1
AWS 장애 고지, 클라우드법 준수로 잠정 결론 - 전자신문
11월 22일 AWS 서울 리전 이슈의 후속 조치 안내 - AWS 한국 블로그
아시아-태평양 서울 리전(AP-NorthEast-2)의 Amazon EC2 DNS 확인(Resolution) 이슈 요약 - AWS Website

6. 참조[편집]

7. 국내 딜러[편집]

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

8. 기타[편집]

학교 이메일이 있는 학생이라면, Github Education의 Student developer pack링크를 따라가면 $150(유효기간 있음)의 크레딧을 얻을 수 있다. (기존 아이디에 추가 가능)

9. 관련 문서[편집]

[1] 지금은 노스캐롤라이나에 지은 대형 데이터센터로 일부 이전한 상태

[2] 사용하는 만큼만 비용을 지불하고 트래픽을 모니터링 및 성능 조절을 자동화할 수 있는 특성상 초기 인프라 구축에 큰 돈을 들일 수 없는 스타트업이 사용하기 좋다.

[3] AWS가 국내에 진출하기도 전에 이미 AWS 솔루션 도입을 컨설팅해주는 회사도 있었다.

[4] 다만 트위치 한국 서버는 AWS 한국 리전에 있지 않고 홍콩에 위치해 있다. 이유는 망 사용료와 세금 절감.

[5] "하하! 150명의 전 아마존 직원들(현 구글 직원)들은 7번이 내가 끼워넣은 농담이란 걸 알테지. 왜냐면 베조스는 자기가 삘 받은 날에 저런 좋은 말은 절대 하지 않으니까." - Stevey Yegge

[6] 가끔씩 쓰는 인스턴스는 AMI를 만들어서 보관해두면 요금을 아낄 수 있다. AMI 역시 달마다 비용이 청구되므로 사용량을 잘 파악하고 쓰지 않는 AMI는 바로바로 삭제해야 한다.

[7] 원래는 t2 인스턴스가 가장 저렴했으나, 2019년에 출시된 t3/t3a(AMD 기반) 인스턴스가 기존 t2 인스턴스보다 더 저렴한 비용으로 나왔으며 성능 또한 향상되었다. 특별한 경우가 아니라면 t3 또는 t3a 인스턴스를 검토해보는 것이 좋을 듯하다.

[8] Standard $20/월 플랜

[9] High Frequency 플랜

[10] 이 사건의 여파인지는 모르겠지만 아마존은 MS와 경쟁하던 미 국방부 클라우드 서비스 공급 사업(JEDI)에서 마이크로소프트에 패배했다. 이때문에 항소까지 해봤지만 MS가 사업한다는 확인사살만 당했다

[11] EC2의 EBS와는 달리 사용량만큼만 과금된다

[12] 소니 픽처스 자회사는 비용절감을 위해 자사 영화 데이터 전체를 테이프 백업에서 이 서비스로 교체하기도 했다.

[13] 서버 전원을 내려버린다거나... 데이터 손실 방지를 위한 최소한의 조치 외에는 그냥 하드를 뽑아다가 차곡차곡 창고에 쌓아놓는 느낌이다.

[14] 그래서 파일을 꺼낼때 짧아도 24~48시간은 걸린다.

[15] 아마존닷컴이 얼마나 많은 상품 사진을 서비스해야 하는지 생각해보자.

[16] 아파치 소프트웨어 재단에서 관리하는 오픈 소스 검색엔진 라이브러리이다. 이 루씬을 가지고 만든 애플리케이션이 ElasticSearch인 것. 원래는 Java 기반이지만 아파치 재단에서 루씬을 Python으로 래핑한 파이루씬(PyLucene)도 존재한다.

[17] 책 내용이 모두 웹에 공개되어 있다.