서버리스란

서버리스는 서버가 없다는게 아니라 서버를 관리할 필요가 없고, 서버가 보이지 않고, 서버를 프로비저닝 하지 않는 것이다.
그냥 코드를 배치하면 된다. 쉽게 말해 함수를 배치하는 것.
원래 서버리스는 FaaS(Function as a Service)를 뜻했지만 지금의 서버리스는 원격 관리되는 것을 모두 포함한다.
Lambda, DynamoDB Cognito, API Gateway, Amazon S3, SNS와 SQS, Kinesis Data Firehose, Aurora Serverless, Step Functions, Fargate 등이 있다.

람다(Lambda)

람다는 가상의 함수이다. 관리할 서버 없이 코드를 프로비저닝하면 함수가 실행된다.
제한 시간이 있어서 실행 시간이 짧다. 최대 15분.
Lambda를 사용하지 않으면 람다 함수가 실행되지 않고 비용 역시 함수가 실행되는 동안만 청구되며 호출을 받으면 온디맨드로 실행된다.
스케일링이 자동화된다. 더 많은 람다 함수를 동시에 필요로 하는 경우 AWS가 자동으로 프로비저닝해서 람다 함수를 늘려준다.

가격책정

Lambda가 수신하는 요청의 횟수에 따라 과금되는데 호출 횟수와 컴퓨팅 시간, 즉 Lambda가 실행된 시간만큼 청구된다.
프리 티어에서도 Lambda를 넉넉하게 제공해 주는데 Lambda 요청 1백만 건과 40만 GB-초의 컴퓨팅 시간이 포함된다.

장점

다양한 AWS 서비스와 통합할 수 있다.
Lambda에 여러 가지 프로그래밍 언어를 사용할 수 있어서 상당히 자유로운 편이다.
CloudWatch와의 모니터링 통합도 쉽다.
그리고 함수당 더 많은 리소스를 프로비저닝 하려면 함수당 최대 10GB의 램을 프로비저닝 할 수 있다.
함수의 RAM을 증가시키면 CPU 및 네트워크의 품질과 성능도 함께 향상된다.

지원 언어

Node.js 또 Python, Java 즉 Java 8 호환이나 Java 11, C# .NET Core Golang, C# /Powershell Ruby, 또 웬만한 언어는 모두 Lambda에서 사용 가능하다.
커뮤니티가 지원하는 사용자 지정 런타임 API 덕분이다.
예를 들어 Rust 언어 함수를 Lambda에서 사용하는 것도 오픈 소스 프로젝트가 있어서 가능하다.

컨테이너 이미지

Lambda 컨테이너 이미지를 지원한다.
Lambda 컨테이너 이미지는 아주 특별한 것인데 컨테이너 이미지 자체가 Lambda의 런타임 API를 구현해야 한다.
즉 아무 컨테이너 이미지나 Lambda에서 실행되지는 않고 컨테이너 이미지를 만들 때 전제 조건이 필요하다.
ECS와 Fargate는 계속 임의의 도커 이미지를 실행할 때 더 많이 사용된다.
따라서 시험에서 Lambda에 컨테이너를 실행해야 할 경우 해당 컨테이너가 Lambda 런타임 API를 구현하지 않으면 ECS나 Fargate에서 컨테이너를 실행해야 한다.

람다 제한

제한에는 실행 제한과 배포 제한이 있다.

실행 제한

실행 시 메모리 할당량은 128MB에서 10GB이고 메모리는 1MB씩 증가한다. 메모리가 증가하면 더 많은 vCPU가 필요하다.
최대 실행 시간은 15분이다. 이를 초과하면 Lambda 실행에 바람직하지 않다.
환경변수는 4KB까지 가질 수 있는데 상당히 제한적인 공간이나 Lambda 함수를 생성하는 동안 큰 파일을 가져올 때 사용할 수 있는 임시 공간이 있다.
/tmp 폴더에 용량이 있으며 크기는 최대 10GB다.
Lambda 함수는 최대 1,000개까지 동시 실행이 가능하며 요청 시 증가할 수 있지만 동시성은 미리 예약해 두는 것이 좋다.

배포 제한

압축 시 최대 크기는 50MB 압축하지 않았을 때는 250MB다.
이 용량을 넘는 파일의 경우 /tmp 공간을 사용해야 한다.
시작할 때 크기가 큰 파일이 있으면 /tmp 디렉터리를 사용한다.
배포 시에도 환경변수의 한도는 4KB다. (중요하다)
예를 들어 30GB의 RAM과 30분의 실행 시간이 필요하고 3GB의 큰 파일을 있을 때는 워크로드 처리에 Lambda 함수가 적합하지 않다는 걸 판단할 수 있어야 한다.

Customization At the Edge (엣지에서의 사용자 지정)

보통은 함수와 애플리케이션을 특정 리전에서 배포하지만 CloudFront를 사용할 때는 엣지 로케이션을 통해 콘텐츠를 배포한다.
모던 애플리케이션에서는 애플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요구하기도 한다.
이를 엣지 함수라고 하며 CloudFront 배포에 연결하는 코드다.
이 함수는 사용자 근처에서 실행하여 지연 시간을 최소화하는 것이 목적이다.
CloudFront에는 두 종류의 함수가 있는데 CloudFront 함수와 Lambda@Edge다.
엣지 함수를 사용하면 서버를 관리할 필요가 없다. 전역으로 배포되기 때문
사용 사례로는 CloudFront의 CDN 콘텐츠를 사용자 지정하는 경우를 들 수 있다. 사용한 만큼만 비용을 지불하며 완전 서버리다.

사용 사례

웹사이트 보안과 프라이버시
엣지에서의 동적 웹 애플리케이션에도 쓰이고 검색 엔진 최적화(SEO)에도 활용 가능
오리진 및 데이터 센터 간 지능형 경로에도 활용
엣지에서의 봇 완화 엣지에서의 실시간 이미지 변환
A/B 테스트 사용자 인증 및 권한 부여
사용자 우선순위 지정 사용자 추적 및 분석 등

CloudFront Functions

CloudFront에 클라이언트가 요청을 보내는 것을 뷰어 요청이라고 한다.
그런 다음 CloudFront가 오리진 요청을 오리진 서버에 전송한다.
서버가 CloudFront에 오리진 응답을 보내고 CloudFront가 클라이언트에게 뷰어 응답을 전송한다.
CloudFront 함수는 JavaScript로 작성된 경량 함수로 뷰어 요청과 응답을 수정할 때만 사용한다.
확장성이 높고 지연 시간에 민감한 CDN 사용자 지정에 사용된다.
시작 시간은 1밀리초 미만이며 초당 백만 개의 요청을 처리한다.
CloudFront의 네이티브 기능으로 모든 코드가 CloudFront에서 직접 관리된다.
CloudFront 함수는 고성능, 고확장성이 필요할 때 뷰어 요청과 뷰어 응답에만 사용된다.

Lambda@Edge

이 함수는 Node.js나 Python으로 작성하며 초당 수천 개의 요청을 처리할 수 있다.
모든 CloudFront 요청 및 응답을 변경할 수 있다.
뷰어 요청은 앞서 본 대로고 오리진 요청은 CloudFront가 오리진에 요청을 전송하기 전에 수정할 수 있다.
오리진 응답은 CloudFront가 오리진에서 응답을 받은 후에 수정된다.
뷰어 응답은 CloudFront가 뷰어에게 응답을 보내기 전에 수정된다.
함수는 하나의 리전에만 작성할 수 있다. CloudFront 배포를 관리하는 리전과 같은 리전이다.
함수를 작성하면 CloudFront가 모든 로케이션에 해당 함수를 복제한다.

사용 사례

CloudFront Functions는 캐시 키를 정규화한다.
요청 속성을 변환하여 최적의 캐시 키를 생성한다.
요청이나 응답에 HTTP 헤더를 삽입, 수정, 삭제하도록 헤더를 조작하고 URL을 다시 쓰거나 리디렉션한다.
요청을 허용 또는 거부하기 위해 JWT를 생성하거나 검증하는 요청 인증 및 권한 부여에도 사용되며, 모든 작업이 1밀리초 이내에 이뤄진다.
반면에 Lambda@Edge의 실행 시간은 10초가 걸릴 수도 있다.
CPU와 메모리가 증가하므로 여러 라이브러리를 로드할 수 있고 타사 라이브러리에 코드를 의존시킬 수 있다.
가령 SDK에서 다른 AWS 서비스에 액세스할 수 있도록
네트워크 액세스를 통해 외부 서비스에서 데이터를 처리할 수 있어 대규모 데이터 통합도 수행할 수 있다.
파일 시스템이나 HTTP 요청 본문에도 바로 액세스할 수 있다. 다양한 사용자 커스텀이 가능하다.

Lambda in VPC

기본적으로 Lambda 함수를 시작하면 여러분의 VPC 외부에서 시작된다. 즉 우리는 VPC 내에서 리소스에 액세스할 권한이 없다.
RDS 데이터베이스, ElastiCache 캐시 내부 로드 밸런서를 시작하면 Lambda 함수가 해당 서비스에 액세스할 수 없다.
Lambda 배포의 기본 설정이다. 인터넷의 퍼블릭 API에 액세스하는 것은 가능하다.
DynamoDB에 액세스할 수 있는 건 DynamoDB가 AWS 클라우드의 퍼블릭 리소스이기 때문이다.
하지만 프라이빗 RDS 데이터베이스에는 연결할 수 없다. 이를 해결하려면 VPC에서 Lambda 함수를 시작해야 한다.
이를 위해서는 VPC ID Lambda 함수를 시작하려는 서브넷을 지정하고 Lambda 함수에 보안 그룹을 추가해야 한다.
그러면 Lambda가 서브넷에 ENI를 생성해 우리의 VPC에서 실행되는 가령 Amazon RDS에 액세스할 수 있게 된다.

사용 예시 (RDS 프록시)

Lambda 함수가 RDS 프록시에 연결할 수 있으려면 VPC에서 Lambda 함수를 시작해야 한다.
RDS 프록시는 퍼블릭 액세스가 불가능하므로 Lambda 함수를 퍼블릭으로 시작하면 RDS 프록시에 네트워크 연결을 할 수가 없다.

Dynamo DB

완전 관리형 데이터베이스로 데이터가 다중 AZ 간에 복제되므로 가용성이 높다.
DynamoDB는 클라우드 네이티브이며 AWS의 독점 서비스다.
NoSQL DB지만, 트랜잭션을 지원한다.
DynamoDB를 이용하면 방대한 워크로드로 확장이 가능합니다 데이터베이스가 내부에서 분산되기 때문이다.
초당 수백만 개의 요청을 처리하고 수조 개의 행, 수백 TB의 스토리지를 갖게 된다.
성능은 한 자릿수 밀리초를 자랑하고 일관성 또한 높다.
보안과 관련된 모든 기능은 IAM과 통합되어 있다. (보안, 권한 부여, 관리 기능 포함)
비용이 적게 들고 오토 스케일링 기능이 탑재돼 있다.
유지 관리나 패치 없이도 항상 사용할 수 있다.
데이터베이스를 프로비저닝할 필요가 없다.
항상 사용할 수 있으므로 테이블을 생성해 해당 테이블의 용량만 설정하면 된다.
테이블 클래스는 두 종류다.
액세스가 빈번한 데이터에는 Standard 클래스
액세스가 빈번하지 않는 데이터는 IA 테이블 클래스.
DynamoDB는 테이블로 구성되며 데이터베이스를 생성할 필요가 없다. 이미 존재하기 때문이다.

테이블

DynamoDB에 테이블을 생성하면 각 테이블에 기본 키가 부여되는데 기본 키는 생성 시 결정된다.
각 테이블에 데이터를 추가한다. 항목, 즉 행을 무한히 추가할 수 있다.
각 항목은 속성을 가지며 속성은 열에 표시된다. 속성은 나중에 추가할 수도 있고 null이 될 수도 있다.
DynamoDB에서는 사전 요구 사항 없이 나중에 쉽게 속성을 추가할 수 있다.
DynamoDB 항목의 최대 크기는 400KB이므로 큰 객체를 저장할 때는 적합하지 않다.
문자열, 숫자, 바이너리, 불리언 null과 같은 스칼라 유형 목록, 지도와 같은 문서 유형과 세트 유형을 지원한다.
데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야 할 때 Aurora나 RDS보다는 DynamoDB가 더 나은 선택이다.
기본 키는 파티션 키와 선택 사항인 정렬 키로 구성되며, 속성 테이블이 있다. 데이터베이스 형태다.
속성은 null로 설정하거나 나중에 추가할 수 있다.

Read/Write Capacity Modes

DynamoDB를 사용하려면 읽기/쓰기 용량 모드도 설정해야 한다.
테이블 용량 관리 방식을 제어하는 데는 두 가지 모드가 있다.
기본 설정은 프로비저닝된 모드로 미리 용량을 프로비저닝 해야 한다.
초당 읽기/쓰기 요청 수를 예측해서 미리 지정하면 그것이 테이블의 용량이 된다.
미리 용량을 계획하고 프로비저닝된 RCU와 WCU만큼의 비용을 지불하는 방식이다.
RCU는 읽기 용량 단위 WCU는 쓰기 용량 단위를 뜻한다.
미리 용량을 계획한 경우에도 오토 스케일링 기능이 있으므로 테이블의 로드에 따라 자동으로 RCU와 WCU를 늘리거나 줄일 수 있다.
프로비저닝된 모드는 로드를 예측할 수 있고 서서히 전개되며 비용 절감을 원할 때 적합하다.
온디맨드 모드에서는 읽기/쓰기 용량이 워크로드에 따라 자동으로 확장된다.
미리 용량 계획을 하지 않으므로 RCU나 WCU 개념 자체가 없다.
온디맨드 모드에서는 정확히 사용한 만큼의 비용을 지불한다. 모든 읽기와 쓰기에 비용을 지불해야 한다.
비싼 솔루션으로 볼 수도 있지만 워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용하다.
수천 개의 트랜잭션을 수백만 개의 트랜잭션으로 1분 내로 확장해야 하는 애플리케이션에서 온디맨드 모드를 선택해야한다.
트랜잭션이 없거나 하루에 많아야 4~5회밖에 되지 않는 워크로드라면 트랜잭션 횟수만큼만 비용을 지불하는 온디맨드 모드가 적합하다.

고급 기능

DynamoDB Accelerator, 즉 DAX는 DynamoDB를 위한 고가용성의 완전 관리형 무결점 인메모리 캐시로DynamoDB 테이블에 읽기 작업이 많을 때 DAX 클러스터를 생성하고 데이터를 캐싱하여 읽기 혼잡을 해결한다.
DAX는 캐시 데이터에 마이크로초 수준의 지연 시간을 제공한다.
DAX 클러스터는 기존 DynamoDB API와 호환되므로 애플리케이션 로직을 변경할 필요가 없다.
DynamoDB 테이블과 애플리케이션이 있을 때 몇몇 캐시 노드가 연결된 DAX 클러스터를 생성하면 백그라운드에서 DAX 클러스터가 Amazon DynamoDB 테이블에 연결된다.
캐시의 기본 TTL은 5분으로 설정되어 있으나 변경할 수 있다.
ElastiCache가 아니라 DAX를 사용하는 이유는 무엇일까?
DAX는 DynamoDB 앞에 있고 개별 객체 캐시와 쿼리와 스캔 캐시를 처리하는 데 유용하다.
예를 들어 집계 결과를 저장할 때는 Amazon ElastiCache가 좋고 Amazon DynamoDB는 대용량의 연산을 저장할 때 좋다.
Amazon DynamoDB에 캐싱 솔루션을 추가할 때는 보통 DynamoDB Accelerator 즉 DAX를 사용한다.

Streams

DynamoDB에서는 스트림 처리도 가능하다.
테이블의 모든 수정 사항 즉 생성, 업데이트, 삭제를 포함한 스트림을 생성할 수 있다.
사용자 테이블에 새로운 사용자가 등록됐을 때 환영 이메일을 보내는 등 DynamoDB 테이블의 변경 사항에 실시간으로 반응하는 데 활용할 수 있다.
실시간으로 사용 분석을 하거나 파생 테이블을 삽입할 수도 있다.
리전 간 복제를 실행하거나 DynamoDB 테이블 변경 사항에 대해 Lambda 함수를 실행할 수도 있다.
DynamoDB에는 두 가지 스트림 처리가 있다.
DynamoDB 스트림은 보존 기간이 24시간이고 소비자 수가 제한된다. Lambda 트리거와 함께 사용하면 좋다.
자체적으로 읽기를 실행하려면 DynamoDB Stream Kinesis 어댑터를 사용한다.
Kinesis Data Streams에 변경 사항을 바로 보내는 방법도 있다.
이 스트림은 보존 기간이 1년이고 더 많은 수의 소비자 수를 갖고 데이터를 처리하는 방법이 훨씬 많다.
AWS Lambda 함수 Kinesis Data Analytics Kinesis Data Firehose Glue 스트리밍 ETL 등

Global Table

글로벌 테이블은 여러 리전 간에 복제가 가능한 테이블이다.
테이블을 US-EAST-1과 AP-SOUTHEAST-2에 둘 수 있다.
두 테이블 간에는 양방향 복제가 가능하다.
US-EAST-1이나 AP-SOUTHEAST-2 테이블 둘 중 하나에 쓰기를 하면 된다는 뜻
DynamoDB 글로벌 테이블은 복수의 리전에서 짧은 지연 시간으로 액세스할 수 있게 해 준다.
다중 활성 복제가 가능하므로 애플리케이션이 모든 리전에서 테이블을 읽고 쓸 수 있다는 뜻
글로벌 테이블을 활성화하려면 DynamoDB 스트림을 활성화해야 리전 간 테이블을 복제할 수 있는 기본 인프라가 구축된다.

TTL

DynamoDB의 기능 중에 타임 투 리브(TTL)라는 기능은 만료 타임스탬프가 지나면 자동으로 항목을 삭제하는 기능이다.
가령 SessionData라는 테이블에서 ExpTime(TTL)이라는 만료 기간 속성이 있는데, 이 안에 타임스탬프가 들어간다.
TTL을 정의한 다음 에포크 타임스탬프에서의 현재 시간이 ExpTime 열을 넘어설 경우 해당 항목을 만료 처리하고 삭제 처리를 진행하는 개념이다.
데이터 테이블의 항목이 일정 시간 후에 삭제되도록 하는 것. 사용 사례는 웹 세션 핸들링이다.

재해 복구

재해 복구에도 DynamoDB를 활용할 수 있다.
지정 시간 복구(PITR)를 사용하여 지속적인 백업을 할 수 있다. 활성화를 선택할 수 있고 35일 동안 지속된다.
활성화하면 백업 기간 내에는 언제든 지정 시간 복구를 실행할 수 있다. 복구를 진행할 경우 새로운 테이블을 생성한다.
이보다 더 긴 백업 옵션으로는 온디맨드 백업이 있고 이 백업은 직접 삭제할 때까지 보존된다.
온디맨드 백업은 DynamoDB의 성능이나 지연 시간에 영향을 주지 않는다.
백업을 좀 더 제대로 관리할 수 있는 방법 중 하나로 AWS Backup 서비스가 있다.
백업에 수명 주기 정책을 활성화할 수 있고 재해 복구 목적으로 리전 간 백업을 복사할 수 있다.
이 옵션 또한 백업으로 복구를 진행하면 새로운 테이블이 생성된다.

S3와 통합

S3에 테이블을 내보낼 수 있다. 이를 위해서는 지정 시간 복구 기능을 활성화해야 한다.
DynamoDB 테이블을 S3로 내보내고 쿼리를 수행하려면 Amazon Athena 엔진을 사용한다.
지속적인 백업을 활성화한 상태이므로 최근 35일 이내 어떤 시점으로든 테이블을 내보낼 수 있다.
테이블을 내보내도 테이블의 읽기 용량이나 성능에 영향을 주지 않는다.
따라서 DynamoDB를 Amazon S3로 먼저 내보내기 하여 데이터 분석을 수행할 수 있다.
감사 목적으로 스냅샷을 확보할 수도 있고 데이터를 DynamoDB로 다시 가져오기 전에 데이터 ETL 등 대규모 변경을 실행할 수 있다.
내보낼 때는 DynamoDB JSON이나 ION 형식을 이용한다.
Amazon S3에서 테이블을 가져올 수도 있다.
S3에서 CSV, JSON 그리고 ION 형식으로 내보낸 다음 새로운 DynamoDB 테이블을 생성하는 식이다.
쓰기 용량을 소비하지 않고 새로운 테이블이 생성된다.
가져올 때 발생한 오류는 모두 CloudWatch Logs에 기록된다.

API GATEWAY

AWS의 서버리스 서비스로 REST API를 생성할 수 있으므로 클라이언트가 퍼블릭 액세스할 수 있다.
API Gateway에 클라이언트가 직접 소통하며 다양한 작업을 할 수 있고 Lambda 함수에 요청을 프록시할 수 있다.
API Gateway를 사용하는 이유는 HTTP 엔드포인트뿐만 아니라 다양한 기능,
예를 들어 인증부터 사용량 계획, 개발 단계 등의 기능을 제공하기 때문이다.
API Gateway는 Lambda와 통합하면 완전 서버리스 애플리케이션이 구축되므로 인프라 관리가 필요 없다.
WebSocket 프로토콜을 지원하므로 API Gateway로 두 가지 방법의 실시간 스트리밍이 가능하다.
API 버저닝을 핸들링하므로 버전 1, 2, 3이 생겨도 클라이언트 연결이 끊기지 않는다.
dev, test, prod 등 여러 환경을 핸들링할 수 있고 보안에도 활용할 수 있다.
인증, 권한 부여 등 수많은 보안 기능을 API Gateway에 활성화할 수 있다.
API 키를 생성할 수 있고 API Gateway에 클라이언트 요청이 과도할 때 요청을 스로틀링할 수 있다.
Swagger나 Open API 3.0과 같은 공통 표준을 사용하여 신속히 API를 정의하여 가져올 수 있다.
API Gateway 수준에서 요청과 응답을 변형하거나 유효성을 검사해 올바른 호출이 실행되게 할 수 있다.
SDK나 API 스펙을 생성하거나 API 응답을 캐시할 수도 있다.

통합

Lambda 함수를 사용하는 REST API를 완전 서버리스 애플리케이션에 노출시키는 가장 일반적이고 간단한 방법이다.
백엔드의 HTTP의 엔드포인트를 노출시킬 수 있다.
온프레미스에 HTTP API가 있거나 클라우드 환경에 애플리케이션 로드 밸런서가 있을 때 API Gateway를 활용하면 속도 제한 기능 캐싱, 사용자 인증, API 키 등의 기능을 추가할 수 있다.
HTTP 엔드포인트에서 API Gateway 계층을 활용하는 것이다.
AWS 서비스와도 통합되며, 어떤 AWS API라도 노출시킬 수 있다.
단계 함수 워크플로우를 시작할 수 있고 API Gateway에서 직접 SQS에 메시지를 게시할 수도 있다.
인증을 추가하거나 API를 퍼블릭으로 배포하거나 특정 AWS 서비스에 속도 제한을 추가하기 위해 통합하는 것이다.

엔드 포인트 타입

첫 번째 유형은 기본 유형인 엣지 최적화다. 글로벌 클라이언트용
전 세계 누구나 API Gateway에 액세스할 수 있다.
모든 요청이 CloudFront 엣지 로케이션을 통해 라우팅되므로 지연 시간이 개선된다.
API Gateway는 여전히 생성된 리전에 위치하지만 모든 CloudFront 엣지 로케이션에서 액세스될 수 있다.
CloudFront 엣지 로케이션을 원하지 않을 때는 리전 배포를 사용한다.
모든 사용자는 API Gateway를 생성한 리전과 같은 리전에 있어야 한다.
자체 CloudFront 배포를 생성할 수도 있다.
엣지 최적화 배포와 동일한 결과를 내며 캐싱 전략과 CloudFront 설정에 더 많은 권한을 가질 수 있다.
API Gateway 배포 유형은 프라이빗으로 퍼블릭 배포가 아니다.
프라이빗 API Gateway는 VPC 내에서만 액세스할 수 있다. ENI 같은 인터페이스 VPC 엔드포인트를 사용
API Gateway에 액세스를 정의할 때는 리소스 정책을 사용

보안

첫 번째 방법은 IAM 역할을 사용하는 것이다.
가령 EC2 인스턴스에서 실행되는 내부 애플리케이션에서 유용하다.
API Gateway의 API에 액세스할 때 IAM 역할을 사용하도록 하는 것이다.
모바일 애플리케이션이나 웹 애플리케이션의 외부 사용자에 대한 보안 조치로 Amazon Cognito를 사용할 수 있다.
자체 로직을 실행하려면 사용자 지정 권한 부여자를 사용하면 된다. (Lambda 함수)
HTTPS 보안도 있다. 사용자 지정 도메인 이름을 AWS Certificate Manager 즉 ACM과 통합할 수 있다.
엣지 최적화 엔드포인트를 사용할 경우 인증서는 us-east-1에 있어야 하고 리전 엔드포인트를 사용한다면 인증서는 API Gateway 단계와 동일한 리전에 있어야 한다.
끝으로 Route 53에 CNAME이나 A-별칭 레코드를 설정해 도메인 및 API Gateway를 가리키도록 해야 한다.

Step Function

Step functions는 서버리스 워크플로를 시각적으로 구성할 수 있는 기능으로 주로 람다 함수를 오케스트레이션 하는 데 활용한다.
그래프를 만들어서 각 그래프 단계별로 해당 단계의 결과에 따라 다음으로 수행하는 작업이 뭔지 정의한다.
좀 복잡한 워크플로를 만들어 AWS에서 실행시킬 수 있는 편리한 도구
Step functions가 제공하는 기능으로는 시퀀싱, 병행 실행, 조건 설정 타임아웃, 에러 처리하기 등이 있다.
람다 함수만 처리하는 게 아니라 EC2랑도 연동할 수 있고, ECS, 온프레미스 서버 또 API 게이트웨이랑 SQS 큐 등 다양한 AWS 서비스를 워크플로에 넣을 수 있다.
워크플로에 사람이 개입해서 승인을 해야만 진행되는 단계를 설정할 수 있다.
어떤 지점에 이르러서는 사람이 결과를 확인하고 승인을 하면 다음 단계로 넘어 가고, 아니면 워크플로가 멈춰 실패하게 한다.
다양한 사용처가 있는데, 예를 들어 주문 이행이나 데이터 처리, 웹 애플리케이션 등 구성하기 복잡한 워크플로를 시각적으로 구성하려고 할 때 사용한다.