아마존 웹 서비스

AWS를 약자로 쓰는 다른 단어들에 대한 내용은 AWS 문서 참고하십시오.

클라우드 컴퓨팅 플랫폼 Top3 클라우드 서비스 목록
{{{#!wiki style="margin: 0 -10px -5px; min-height: 26px;" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin: -6px -1px -11px -1px"; word-break: keep-all;"	IaaS (인프라형 클라우드)

Amazon Web Services(AWS)	Microsoft Azure	Google Cloud Platform(GCP)
PaaS (개발형 클라우드)

Google Colaboratory	Heroku	RedHat OpenShift
SaaS (소프트웨어형 클라우드)

SalesForce	ZOOM	Slack
STaaS (스토리지 클라우드)

Google Drive	OneDrive	Dropbox

}}}}}}}}} ||

파트너 브랜드

{{{#!wiki style="margin:0 -10px -5px; word-break: keep-all"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-6px -1px -11px"

글로벌 파트너

파일:MSC 크루즈 로고 화이트.svg

공식 파트너

지역 파트너

e스포츠

}}}}}}}}}

<colbgcolor=#374762><colcolor=#ffffff> 아마존 웹 서비스 Amazon Web Services

정식명칭	Amazon Web Services INC (아마존웹서비스 주식회사)
CEO	애덤 셀립스키[1]
본사	미국 워싱턴 주 시애틀
국가	[[미국\| 파일:미국 국기.svg 미국 ]][[틀:국기\| 파일: 특별행정구기.svg 행정구 ]][[틀:국기\| 파일: 기.svg 속령 ]]^{( 다국적 기업)}
설립일	2006년 3월 14일 (16주년)
한국법인	아마존웹서비시즈코리아 유한책임회사 서울특별시 강남구 테헤란로 231
설립자	제프 베이조스
모기업	아마존닷컴
매출	800억 9,600만 달러 ^(2022년)
영업 이익	228억 4,100만 달러 ^(2022년)
고용 인원	62,000명 ^(2021년)
본사
링크	\| \| \| \|

1. 개요2. 영향력3. 배경과 탄생4. 서비스

4.1. 컴퓨팅

4.1.1. EC2

4.1.1.1. 인스턴스 종류

4.1.2. Lightsail4.1.3. Lambda4.1.4. 그 외

4.2. 스토리지

4.2.1. S34.2.2. S3 Glacier4.2.3. 그 외

4.3. 데이터베이스

4.3.1. RDS4.3.2. DynamoDB4.3.3. ElastiCache4.3.4. 그 외

4.4. 마이그레이션 및 전송4.5. 네트워킹 및 콘텐츠 전송

4.5.1. CloudFront4.5.2. 그 외

4.6. 개발 도구4.7. 관리 및 거버넌스4.8. 미디어 서비스4.9. 머신 러닝4.10. 분석4.11. 보안, 자격 증명 및 규정 준수4.12. 사물 인터넷4.13. 모바일4.14. 애플리케이션 통합4.15. 고객 참여4.16. 비즈니스 애플리케이션4.17. 최종 사용자 컴퓨팅4.18. 게임 개발4.19. 기타

5. 자격증6. 사고7. 참조8. 국내 파트너사9. 관련 문서

[clearfix]

1. 개요

경험을 압축하는 알고리즘은 존재하지 않는다[2]

세상은 비동기식이며, AWS는 그 중심에 있다.[3]

AWS사 로고

아마존닷컴의 클라우드 컴퓨팅 사업부. 현재 클라우드 컴퓨팅 분야에서 세계 1위를 차지하고 있다.[4]

소비자들이 아마존이라는 기업을 떠올리면 B2C 고객들을 대상으로 한 커머스 사업부를 떠올리기 때문에, B2B 영역에서 클라우드 서비스를 제공하는 AWS 사업부의 위력을 모르는 경우가 많다. 2022년 기준으로 AWS 사업부의 매출은 아마존 전체 매출의 16% 정도만을 차지하나, 본사업은 적자이고[5] 모든 영업 이익은 AWS에서만 나오고 있다. 즉 아마존의 캐시카우이다. 결국 이 사업은 아마존을 커머스 기업에서 종합 IT 기업으로 탈바꿈하고, 이후 여러 가지 산업에 진출할 수 있는 가능성을 열어준 1등 공신이자 자사를 진정한 빅테크 궤도에 올려놓은 신의 한 수가 된 셈이다.

2. 영향력

AWS

2021년 AWS 서비스 브랜딩 광고 [6]

넷플릭스, 크래프톤, 모더나, 삼성전자, 한국투자증권, AMD 등 세계 굴지의 스타트업과 대기업들이 AWS의 고객이며, 인프라부터 시작하여 보안까지 AWS에 의존비중이 매우 높다. AWS 서버가 뻑나면 시장에 혼돈이 온다는 말이 괜히 있는 말이 아니다. 참고로 나무위키의 메일 서버가 이곳을 사용하고 있으며 가입 인증 메일의 헤더를 까보면 메일 서버 아이피가 워싱턴 D.C.에 있는 아마존 서버로 나온다. 배틀그라운드 게임 서버도 이곳을 이용하는 것으로 확인되었다. 트위치 역시 아마존닷컴에게 인수된 뒤로는 AWS 서버를 사용하고 있다.

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

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

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

AWS의 데이터센터[7]

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

이전까지는 스타트업 문화 자체가 약하고[9] 클라우드 컴퓨팅에 대한 이해가 떨어지는 등 여러 요인으로 AWS는 아는 사람만 쓰는 부류의 서비스였다.[10] 미국, 유럽 등에 유행하기도 전에 클라우드를 도입한 기업들은 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)이 설립된 날이 넷플릭스가 한국에서 서비스를 시작한 날과 동일하다. 하지만 지금 상황을 보면 그냥 우연의 일치에 불과하다. 넷플릿스가 AWS를 쓰는 것 맞지만 미국에 주 서버를 두고 각지의 통신사와 협력하여 오픈커넥트를 설치하는 방식으로 서비스를 하고 있으며, 만약 넷플릭스가 아마존의 클라우드프론트 등을 적극적으로 활용하여 한국 엣지까지 잇는다면 누구나 좋은 품질로 넷플릭스를 볼 수 있었을 것이다. 물론 망 이용료가 비싼 문제는 있겠지만.

국내에서는 자체 데이터센터 없이 타 데이터센터의 공간을 임대하여 운영하고 있지만, 인천광역시 서구 가좌동에 자체 데이터센터가 지어질 예정이다. 관련 기사

3. 배경과 탄생

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

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

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

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

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

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

4. 서비스

AWS 서비스 연혁

제공하는 서비스를 목록으로 간략하게 정리하지만, 실제로는 훨씬 더 방대한 서비스들과 개별 기능들을 제공하므로, 공식 문서를 참조할 것. 전반적으로 Elastic이라는 브랜드를 쓰는 제품들이 많다.

4.1. 컴퓨팅

4.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 볼륨도 지워줘야 한다.[12] 보통 Terminate시키면 EBS 볼륨도 자동으로 삭제되지만 옵션에서 이걸 막을 수 있게 돼 있으므로 확인은 필수.
그러나, 이런 번거로움을 감수할 만한 엄청난 메리트가 있으니 바로 가격이다. 대표적으로 t4g.nano의 시간당 비용은 0.0042달러... 한달내내 켜놔도(약 750시간) 약 3.15달러를 낸다. EBS 볼륨은 유지한 상태로 인스턴스 타입을 바꾸는 게 가능하기 때문에 제일 싼 t4g.nano 인스턴스로 먼저 시스템을 구축하고 나서 정상 작동 여부를 테스트한 뒤 고성능 인스턴스로 바꿔서 재부팅하는 방법으로 요금을 아낄 수 있다.[13] 다른 구식 호스팅 서비스에서는 서버를 두 대를 결제해서 데이터를 복사하는 방법(데이터 마이그레이션)이 유일한데 이렇게 하면 서버 두 대의 한 달치 요금을 중복 결제하게 되어 오히려 요금이 늘어난다.

* 스팟 인스턴스 (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도 같은 정책이 적용된다.

2021년 중반부터 ARM 인스턴스가 추가되었다.

2022년 7월에는 M1 기반의 Mac 인스턴스가 정식으로 출시되었다. # 다만 아직 서울 리전을 지원하지 않으며, 2022년 12월 기준 싱가포르 리전을 사용하는 것이 가장 빠르다고 한다.

4.1.1.1. 인스턴스 종류

아래에서 #는 세대(번호)를 뜻한다. 숫자가 클수록 최신 사양이다.

t#: 가장 저렴하며, 무난하게 많이 쓰이는 편. 4세대부터는 AArch64 기반이라 -g가 붙는다.
c#: CPU 특화. 6세대부터는 AArch64 기반이라 -g가 붙는다.
m#: RAM 특화. 6세대부터는 AArch64 기반이라 -g가 붙는다.
r#: 극 RAM 특화. 6세대부터는 AArch64 기반이라 -g가 붙는다.

아키텍처에 따른 분류는 다음과 같다.

(접미사 없음), -d: 인텔 제온 시리즈 사용 인스턴스. -d는 별도의 NVMe 스토리지가 붙어 있는 인스턴스이다.[d]
-a, -ad: AMD EPYC 시리즈 사용 인스턴스. 제온 시리즈 사용 인스턴스에 비해 가격 부담이 덜하다. -ad는 별도의 NVMe 스토리지가 붙어 있는 인스턴스이다.[d]
-g, -gd: ARM Neoverse 시리즈 사용 인스턴스. 성능 대비 가장 싸지만[16] 아키텍처가 AMD64가 아닌 AArch64이다 보니 사용해야 하는 앱이 AArch64를 지원하지 않으면 사용하기 어렵다. -gd는 별도의 NVMe 스토리지가 붙어 있는 인스턴스이다.[d][18]

등급에 따른 분류는 다음과 같다.

nano, micro, small, medium, large, xlarge, 2xlarge...: 일반적인 등급으로, 등급이 높을수록 성능과 가격이 올라간다. small 이하는 t 계열에만 있는 등급이다.
metal: 이른바 '통 서버' 사양이다. 서버의 모든 자원을 끌어 쓸 수 있다.

Mac 인스턴스의 경우 당연히 Mac으로 시작하며, 숫자에 따른 분류는 다음과 같다. 세부 정보 Mac Mini 기반이다.

Mac1: x86 기반 아키텍처를 사용하며, Intel Core I7 CPU를 사용한다.
Mac2: ARM 기반 아키텍처를 사용하며, Apple M1 CPU를 사용한다.

4.1.2. Lightsail

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

그리고 서울에 리전이 있다. MS Azure는 서울 부산에 각각 있다. 다른 해외 업체에서는 가까워봐야 도쿄가 제일 가까운데, 서울에 리전이 있다는 것은 한국 이용자들에게는 특장점. 다만 경쟁업체 중 하나라고 할 수 있는 Vultr도 2020년 5월 12일에 서울 리전을 개설했다. EC2와는 약간 독립적인 서비스라서 UI도 좀 다르고, 한동안 AWS 크레딧도 사용이 불가능했다. (현재는 크레딧 사용가능)

웹 서버 돌리기에는 꽤 괜찮은 서비스였다. 트래픽도 상당히 후하다. 가격 인상 이전에는 최저 인스턴스인 3.5달러 짜리가 무려 한 달에 1TB 트래픽을 주는데[19], 국내에 비슷한 가격으로 이 트래픽 주는 데가 없었으나... 후술하듯 아래 가격 인상과 함께 이 장점은 사실상 사라졌다.

다만 서비스 구매시 같이 달려오는 수두룩한 부가 서비스와는 별개로, 서버 그 자체의 성능은 조금 아쉬운 편이다. $20/월 플랜에서도 디스크 쓰기 속도가 60MB/s(...)로 나오며, 다른 회사들 중에서 Digital Ocean을 예시[20]로 들자면 350MB/s, 4달러 올려서 1000MB/s를 뽑는 Vultr[21]와 확실히 비교되는 부분이라 여러모로 조금 아쉬운 편.
CPU 성능도 다른 서비스에 비해 상당히 많이 딸리는 편으로, 모든 플랜의 CPU가 가상 CPU라 다른 사용자와 공유하고, 성능도 경쟁사에 비해 상당히 떨어지는 편이라 중대형 서비스를 돌리기에는 매우 부적합하며, 단순 개발용으로 사용하는 것이 좋다. 실제 사용 체감은 경쟁사보다 성능이 절반정도라 생각해야 하는 것이 라이트세일은 CPU 버스트 구간과 시간이 존재하며, 점유율의 약 30 ~ 50% 이상을 일정 시간 이상 유지하면 버스트 구간으로 취급한다. 이 버스트 구간 리미트와 시간이 상당히 제한적이며, 버스터 시간을 모두 소모하면 강제로 CPU 성능이 20-30%대로 고정되어버린다. 성능이 제한되면 중대형 서비스 또는 연산이 많은 웹사이트의 경우 정상적인 서비스가 불가능해지니, 차라리 부가 서비스들을 최소한으로 하고 서버 스펙에 치중한 다른 Lightsail의 비슷한 서비스를 개설하는게 나아보인다는 평도 있다.

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

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

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

2024년 7월 기준 시기 미상으로 최소 요금이 512MB 기준 5$로 인상되어[22] 이용할 메리트가 적어졌다.

4.1.3. Lambda

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

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

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

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

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

4.1.4. 그 외

ECR (Elastic Container Registry)
컨테이너 이미지를 저장, 관리 및 배포하는 서비스.
ECS (Elastic Container Service)
Docker 컨테이너로 구축하는 EC2 서비스.
EKS (Elastic Kubernetes Service)
완전 관리형 Kubernetes 제어 서비스.
Batch
대규모 배치 컴퓨팅 워크로드 처리 서비스.
Elastic Beanstalk
웹 앱의 배포 및 관리 서비스
Serverless Application Repository
AWS에서 구성 가능한 서버리스 애플리케이션을 배포할 수 있다.
아직 한국어로는 번역이 고르지 못한 편이다.
AWS Outposts
금융, 정부 등의 중요 데이터를 클라우드에 배치할 수 없는 케이스를 고려하여 On-premise에서 AWS 서비스를 그대로 사용할 수 있게 확장해 주는 서비스이다.

4.2. 스토리지

4.2.1. S3

Simple Storage Service. 무제한 용량을 제공하는 인터넷 스토리지 서비스. 확장성이 뛰어나고 사용한 만큼만 비용을 지불한다. 버킷(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에 암호화 안한 미군측이 찍은 정찰위성이나 드론 사진들이 이리저리 신나게 나돌아다니는걸 누가 발견했다(...) 범인은 저 관련 정보기관과 일하던 회사(...)[24]

4.2.2. S3 Glacier

본격 백업 전용 스토리지.

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

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

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

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

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

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

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

4.2.3. 그 외

Elastic File System
사용량에 따라 과금되는 블록 스토리지.[28] NFS기반.
FSx
고성능 파일 시스템의 생성 과정을 간소화한 서비스.
Storage Gateway
로컬(사무실 등)의 저장소와 AWS의 저장소를 동기화해주는 서비스.
AWS Backup
AWS 서비스를 백업하고 중앙 관리하는 서비스이다.

4.3. 데이터베이스

4.3.1. RDS

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

EC2인스턴스 위에서 돌아가는 서비스이기 때문에 해당 EC2인스턴스의 시간당 요금을 지불한다. 근데 EC2와는 다르게 nano 옵션이 없고 최소 micro를 선택해야 하기 때문에 24시간 켜놔야 하는 데이터베이스 특성상 실험용으로 RDBMS를 사용하고자 할 경우 t4g.nano 인스턴스에 직접 MariaDB(아예 Amazon Linux에서 자체 ARM 서버에 특화된 버전을 지원한다)를 깔아 쓰는 게 압도적으로 저렴하다. 이 서비스는 대용량 트래픽을 처리해야 하는 기업 사용자용이다. 혹 반드시 써야겠다면 예약 인스턴스를 구매하고 쓰도록 하자.

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

4.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함수를 호출하는 일을 할 수 있다.

4.3.3. ElastiCache

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

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

4.3.4. 그 외

Neptune
그래프를 위한 데이터베이스 서비스.
Amazon Redshift
데이터 웨어하우징. 정말 엄청난(페타바이트 규모) 데이터를 SQL로 다룰 때 사용한다. EMR은 아예 하둡이란 게 차이점.
Amazon QLDB
투명하고, 변경 불가능하며, 암호화 방식으로 검증 가능한 트랜잭션 로그를 포함하는 중앙 데이터베이스.
Amazon DocumentDB
MongoDB와 호환되는 고가용성, 완전 관리형 문서 기반 데이터베이스 서비스.
MCS(Managed Cassandra Service)
확장 가능한 고가용성의 관리형 Apache Cassandra 호환 데이터베이스 서비스.
Aurora
RDS에 Auto Scaling 기능을 추가한 형태이다. 다만 구버전의 Mysql, PostgreSQL만 지원하고 MariaDB 등 최신 버전의 DBMS는 지원하지 않는다.

4.4. 마이그레이션 및 전송

AWS Migration Hub
On-premise를 AWS로 이전하는 것을 돕는 종합 서비스.
Application Discovery Service
On-premise 환경의 서버의 시스템 특성, 성능, 종속성 그리고 유용한 정보를 수집하는 서비스.
Database Migration Service
데이터베이스 마이그레이션(이동) 서비스.
Server Migration Service
On-premise를 AWS로 이전하는 것을 돕는 서비스.
Snowball
대규모 데이터 이동 서비스. 일종의 (하드디스크) 택배 서비스이다.
DataSync
데이터 이전을 간소화, 자동화 그리고 가속화하는 서비스.

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

4.5.1. CloudFront

세계 어디서나 빠른 속도로 파일을 제공하도록 최적화하는 Content Delivery Network(CDN) 서비스.[29] 위의 S3와 연계하면 이미지 서비스의 극을 달릴 수 있다. 적어도 한국 대상의 서비스는 클라우드플레어 엣지 라우팅 문제 때문에 클라우드플레어보다는 이쪽을 사용하는 게 유리하다. 한국 사용자는 서울 리전으로 연결되니까. 클라우드플레어를 사용하기 유리할 때는 정적 서비스면서 클라우드플레어 엔터프라이즈 플랜 사용료가 클라우드프론트 사용료보다 쌀 때 유리하다. 유료 콘텐츠를 제공할때도 좋다. 서명 URL이나 서명 쿠키를 사용해서 인증된 사용자에게만 콘텐츠를 배달하는 서비스를 할 수 있다. 2022년부터 HTTP/3을 지원하기 시작했다.

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

기본적으로 정적 컨텐츠 (이미지, 동영상, 오디오, HTML 문서 등)에 최적화되어 있고 동적 컨텐츠 (웹 애플리케이션)를 캐싱하면 HTML 문서로 변환되므로 캐싱 불일치 문제가 발생한다. 하지만 설정을 잘해 주면 동적 컨텐츠용 CDN으로도 충분히 사용할 수 있다.

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

4.5.2. 그 외

VPC
가상 네트워크 구축 서비스. EC2 서버들간에 격리 구역을 만들 때 사용한다.
Route 53
DNS 및 도메인 서비스. 이름의 유래는 DNS 서버가 포트 53에서 쿼리에 반응하며 최종 사용자를 인터넷상의 애플리케이션으로 경로를 지정해 준다는 의미에서 유래한 것이다.[30]

DNS
구입한 도메인을 AWS의 서비스에 연결할 때 사용한다. 도메인을 EC2 인스턴스 또는 기타 AWS 서비스와 연결하는데 꼭 Route 53을 사용할 필요는 없지만 통합 관리가 가능한 장점이 있다. 다만 단순히 도메인을 IP에 연결할 목적이라면 무료 DNS 업체들이 있으니 그쪽을 사용하는 게 가격적으로는 더 유리하다. 물론 로드밸런싱 등의 고급 DNS 설정이 필요한 경우에는 AWS의 서비스가 저렴하다.
Registar
도메인 구입 및 관리도 지원하는데, 가격이 다른 국내 업체보다는 비싼 편이다. .com이 1년에 12달러, .net이 11달러다.
.kr 도메인은 취급하지 않는다.
Health Check
Endpoint의 상태를 체크하여 Route53 DNS에서 활용하거나 SNS와 활용하여 문자, 이메일 알림 또는 Lambda 함수 트리거 등이 가능하다.

API Gateway
HTTP 요청으로 Lambda 이벤트를 생성, HTTP Proxy, 기타 AWS 서비스와 연결 그리고 VPC 링크로의 연결을 가능케하는 서비스이다.
Lambda와 함께 Serverless Architecture를 구성하는 핵심 요소이다.
Direct Connect
고속 전용 네트워크 연결 서비스. 일종의 보장된 대역폭을 제공한다.
AWS App Mesh
마이크로서비스 모니터링 및 제어 서비스.
AWS Cloud Map
클라우드 리소스에 대한 서비스 검색 지원.
Global Accelerator
서비스의 가용성 및 성능을 개선해 주는 서비스이다.
전세계에 Anycast로 Endpoint를 구성하여 Request를 로드 밸런싱한다.

4.6. 개발 도구

CodeCommit
Git 리포지토리 서비스.
CodeBuild
코드 컴파일, 테스트 및 배포를 자동화하는 완전 관리형 서비스이다.
CodeDeploy
다양한 컴퓨팅 서비스의 배포를 자동화하는 완전 관리형 서비스이다.
CodePipeline
CodeCommit과 연계하여 CI/CD 구현을 도와주는 파이프라인 미들웨어 서비스이다. 보안 인증 문제로 AWS 전체 서비스를 제어하기가 까다로운 서드파티 플랫폼보다 AWS와 더 간단하게 통합된다.
Cloud9
온라인 코드 IDE이다.
X-Ray
요청 트레이스, 예외 수집 및 프로파일링 기능을 통해 배포한 애플리케이션의 동작을 분석하는 서비스이다.

4.7. 관리 및 거버넌스

CloudWatch

Logs
로그(Log) 관리 서비스. EC2, Lambda, S3 등 AWS 서비스에서 발생하는 로그 기록을 통합 관리.
Metrics
지표 모니터링 서비스이다.
Events
이벤트 또는 일정에 의해 대상을 트리거하는 서비스이다.

CloudFormation
클라우드 구성 배포 서비스. 위 서비스의 '조합' 템플릿을 입력해 클라우드 인프라 자체를 패키징한다. Elastic Beanstalk과 비슷한 서비스.
CloudTrail
사용자 활동 및 API 추적 서비스이다.
Config
OpsWorks
Service Catalog
Trusted Advisor
컨설팅 서비스. AWS 서비스를 최적화하고 결함을 찾아내는 등의 서비스. 일종의 기술지원 서비스이다.

4.8. 미디어 서비스

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

4.9. 머신 러닝

Lex
텍스트 및 음성인식 기반 대화형 인공지능 서비스.
Polly
텍스트 분석 및 음성 변환 서비스.
Rekognition
지능형 이미지 분석 서비스.

4.10. 분석

EMR
Hadoop 서비스.
CloudSearch
클라우드 기반 검색 엔진. Apache Solr기반인데 Solr이 Lucene기반으로 만들어져 있어 결과적으로 위의 ElasticSearch와 비슷하다. ElasticSearch에 비해 좀 더 사용하기 편리하고 규모가변성 있는 검색 시스템을 구축할 수 있다. 그러나 가격은 ElasticSearch에 비해 다소 비싸다.
ElasticSearch Service
루씬(Lucene)[31] 기반 검색엔진 서비스. 자연어 검색이나 전문 검색(Full text search)이 필요할 때 사용한다.
Kinesis
실시간 스트림 데이터 분석 서비스.
Data Pipeline

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

(IAM) Identity & Access Management
AWS 서비스에 접근할 권한을 세분화하는 서비스이다.
Root 계정 대신 IAM을 통해 제한적인 권한을 부여하여 조직적인 관리를 가능하게 한다.
Cognito
인증 및 유저 데이터 동기화 서비스.
Inspector
소프트웨어 취약성 및 의도하지 않은 네트워크 노출에 대해 AWS 워크로드를 지속적으로 스캔하는 자동화된 취약성 관리 서비스
Directory Service
Active Directory 서비스. LDAP서비스이다.
ACM (Amazon Certificate Manager)
SSL 인증서 관리 서비스. HTTPS 보안 웹 서버나 로드 밸런서, 커스텀 도메인으로 CloudFront 서비스를 사용할 때 여기서 인증서를 등록한다. 또한 Elastic Beanstalk의 사용할 인증서도 여기서 등록하여 HTTPS로 배포할 수 있다.
WAF & Shield

WAF
웹 방화벽 서비스이다. CloudFront와 연계하여 사용할 수 있다.
Shield
유해 트래픽 차단 서비스이다.

Shield Advanced
고성능 유해 트래픽 차단 서비스이다.
이 서비스를 이용하면 자신의 Endpoint에 들어오는 공격 뿐만 아니라 AWS에서 얼마나 많은 규모의 공격을 처리하고 있는지 볼 수 있다.
공격이 발생하면 처리 프로세스가 나타나서 시각적으로 공격을 인지할 수 있다.

4.12. 사물 인터넷

IoT Core
사물인터넷용 인터페이스를 제공하는 관리형 플랫폼 서비스.
Shadow 기능을 통해 사물 디바이스의 네트워크 불안정 상태를 보완하고, Publish/Subscribe 구조를 따르는 MQTT 프로토콜을 통해 손쉽게 사물 인터넷을 개발해 볼 수 있다.
이 서비스를 API Gateway, Lambda와 연계하여 Serverless 아키텍처 디자인이 가능하다.

4.13. 모바일

Mobile Hub
모바일 앱 제작, 테스트, 모니터링 서비스.
Device Farm
iOS 및 안드로이드용 애플리케이션(웹 앱 포함) 테스트 서비스.

4.14. 애플리케이션 통합

Simple Notification Service
AWS 서비스 통합에 도움을 주는 서비스이다.
알림 수단으로는 이메일 및 문자 등의 알림 수단을 지원한다.
단순 알림 서비스에 불과한 것은 아니고 각종 이벤트를 SNS에서 Lambda로 연결하여 Lambda 함수를 실행할 수 있다.
Simple Queue Service
메시지 큐 서비스. RabbitMQ나 ZeroMQ와 비슷한 일을 한다.
SWF

4.15. 고객 참여

SES
대량 이메일 발송 서비스.

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

WorkMail
기업용 이메일 서비스.

4.17. 최종 사용자 컴퓨팅

WorkSpace
가상 데스크톱 서비스.
AppStream
저지연 애플리케이션 스트리밍 서비스. 일종의 라이브스트리밍 서비스이다.
WorkDocs
문서 공유 서비스. 구글독스 비슷한 서비스이다.

4.18. 게임 개발

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

4.19. 기타

Windows Server용 EMP
End-of-support Migration Program, 줄여서 EMP는 Windows Server 레거시 환경에서 구동하기 위해 개발 된 애플리케이션을 코드 변경 없이 AWS의 최신 Windows Server에서 구동할 수 있게 변환해 주는 서비스이다.
Windows Server 2003, 2008 및 2008 R2의 레거시 애플리케이션을 리팩토링 없이 AWS에서 지원되는 최신 버전으로 마이그레이션하기 위한 기술 및 전문가 지침이 포함되어 있다고 한다.
Amazon Linux
RHEL/ 페도라 기반 운영 체제이다. 아마존 웹 서비스와의 연동에 특화되어 있다.

Amazon Time Sync
AWS가 서비스 중인 NTP 서비스. URL은 time.aws.com이다. AWS 인스턴스 외의 개체에서도 사용 가능하며 무료다.

5. 자격증

AWS 서비스는 초기 진입 장벽이 높은 편은 아니지만, 본격적으로 활용할 경우 어느 정도 학습 곡선이 있는 편이다. ~~기존의 물리적 인프라에 각종 편의 기능까지 클라우드에 몽땅 때려박았으니 당연할 수밖에~~ 따라서 AWS 솔루션을 잘 활용하는 검증된 인력을 공급하기 위해 자격 인증 프로그램을 운영하고 있다. 시험 비용이 10만원에서 20만원을 오가 꽤 비싼데, 이전에 AWS 자격증을 취득했거나 바우처를 받으면 50% 할인된 금액으로 시험에 응시할 수 있다. 유효 기간은 3년.

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

* AWS Certified Practitioner

클라우드 개론을 다루는 가장 기초 단계의 자격증. AWS 사용 경험이 없는 입문자나 비개발 직군 종사자들이 많이 응시한다.

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

6. 사고

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

7. 참조

8. 국내 파트너사

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

AWS의 서울 리전 운영이 아마존웹서비시스코리아로 넘어가면서 더 이상 해외 결제가 아니라 국내 PG사인 KCP를 통해 이뤄지므로 해당 포맷을 가지고 비용 처리를 해도 되지만 파트너사를 통해 AWS를 이용할 경우 할인 및 인프라 구축 컨설팅, 고객사 무료 교육 등의 혜택이 있기 때문에 여전히 수요가 많다. 일반 고객과는 접접이 없지지만 클라우드 인프라 구축이 사업 영역인 (CSP)와, 일반 고객들이 주로 만나게 되는 고객 서비스 중심으로 사업하는 (MSP)로 나뉜다. AWS - CSP - MSP - 고객 순서로 이어진다.

CSP

에티버스

MSP

Wavelength Zone

SK텔레콤

9. 관련 문서

[1] 앤디 재시 CEO가 제프 베이조스의 뒤를 이어 아마존 CEO로 자리를 옮기면서 내정된 후임자. [2] AWS가 이야기하는 격언으로서, 인류를 지속적으로 진화시키는 것은 '직감'이 아닌, '직접 겪은 경험을 기반으로 한 데이터와 사고방식'이라는 뜻에서 유래되었다. 실제로 아마존은 타 회사들을 압도적으로 상회하는 수준의 Data-Driven 사고방식을 보여준다. [3] 월스트리트는 해당 세션을 보고 아마존 매수를 추천했다 기사 [4] 점유율 [5] 다만 이 적자는 아마존이 시장 점유율을 유지하기 위해 의도한 것이다. [6] AWS가 B2B 솔루션인 만큼 B2C 고객들은 AWS가 어떤 Product Benefit을 가져다 주는지 모르는 경우가 많다. 해당 광고는 브랜딩 관점에서 AWS라는 서비스가 고객들의 생활에 어떻게 스며들어 있는지 간접적으로 보여준다. 참고로 아마존은 본래 Frugality라는 자사 LP에 따라 고객 관련 영역 또는 꼭 필요한 곳이 아니면 돈을 쓰지 않는 기업으로 유명하다. 다른 빅테크 대비 광고가 적은 이유다. [7] 위치는 당연히 임직원을 제외한 외부인에겐 공개되지 않는다 [8] 지금은 노스캐롤라이나에 지은 대형 데이터센터로 일부 이전한 상태 [9] 사용하는 만큼만 비용을 지불하고 트래픽을 모니터링 및 성능 조절을 자동화할 수 있는 특성상 초기 인프라 구축에 큰 돈을 들일 수 없는 스타트업이 사용하기 좋다. [10] AWS가 국내에 진출하기도 전에 이미 AWS 솔루션 도입을 컨설팅해주는 회사도 있었다. [11] ※출처- Quora [12] 가끔씩 쓰는 인스턴스는 AMI를 만들어서 보관해두면 요금을 아낄 수 있다. AMI 역시 달마다 비용이 청구되므로 사용량을 잘 파악하고 쓰지 않는 AMI는 바로바로 삭제해야 한다. [13] 원래는 t2 인스턴스가 가장 저렴했으나, 2019년에 출시된 t3/t3a(AMD 기반) 인스턴스가 기존 t2 인스턴스보다 더 저렴한 비용으로 나왔으며 성능 또한 향상되었다. 2020년대 들어서 t4g(ARM 기반)가 추가되면서 더욱 가성비가 좋아졌다. 특별한 경우가 아니라면 t3a 또는 t4g 인스턴스를 검토해보는 것이 좋을 듯하다. t4g 인스턴스는 마이크로아키텍처가 다르므로 t3/t3a를 쓰다가 옮길 수 없고 처음부터 t4g로 생성해야 하며, 사용하는 프로그램이 AArch64를 지원하는지를 확인해야 낭패를 보지 않는다. [d] 해당 사양을 사용할 때에만 사용 가능하며, 사양 변경시 회수된다. [d] [16] 다만 7g는 같은 구성의 6g보다 10% 정도 비싸다. [d] [18] -d, -ad에 비해 제공 용량이 약간 적다. [19] 사실 인바운드 512GB, 아웃바운드 512GB라 1TB는 아니다 [20] Standard $20/월 플랜 [21] High Frequency 플랜 [22] 같은 경쟁 업체인 Vultr의 가격의 경우 1GB RAM에 무려 한달에 5$이다. 게다가 여기도 한국 리전을 지원하기 때문에 가격 인상은 사실상 아마존 측의 자폭이나 다름없는 상황. [23] Node.js 환경에서 돌아간다. [24] 이 사건의 여파인지는 모르겠지만 아마존은 MS와 경쟁하던 미 국방부 클라우드 서비스 공급 사업(JEDI)에서 마이크로소프트에 패배했다. 이때문에 항소까지 해봤지만 MS가 사업한다는 확인사살만 당했다 [25] 소니 픽처스 자회사는 비용절감을 위해 자사 영화 데이터 전체를 테이프 백업에서 이 서비스로 교체하기도 했다. [26] 서버 전원을 내려버린다거나... 데이터 손실 방지를 위한 최소한의 조치 외에는 그냥 하드를 뽑아다가 차곡차곡 창고에 쌓아놓는 느낌이다. [27] 그래서 파일을 꺼낼 때 짧아도 24~48시간은 걸린다. [28] EC2의 EBS와는 달리 사용량만큼만 과금된다. [29] 아마존닷컴이 얼마나 많은 상품 사진을 서비스해야 하는지 생각해보자. [30] 아이콘이 미국 53번 국도 도로명판 모양이기는 하나 아마존 Route 53의 이름은 전자기기에서 사용되는 53번째 TCP/IP 포트에서 유래한 것이지, 미국의 53번 국도와 직접적으로 관련되어 있는 것은 아니다. 53번 국도는 미국에서 실제로 존재하는 도로이지만, Amazon Route 53의 이름은 주로 기술적인 컨텍스트에서 비롯된 것이다. [31] 아파치 소프트웨어 재단에서 관리하는 오픈 소스 검색엔진 라이브러리이다. 이 루씬을 가지고 만든 애플리케이션이 ElasticSearch인 것. 원래는 Java 기반이지만 아파치 재단에서 루씬을 Python으로 래핑한 파이루씬(PyLucene)도 존재한다. [32] 책 내용이 모두 웹에 공개되어 있다.

로그가 누락된 본 문서의 기여자 내역은 다음과 같습니다.