서버리스

서버리스란

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

람다

• 람다는 가상의 함수이다. 관리할 서버 없이 코드를 프로비저닝하면 함수가 실행된다.
• 제한 시간이 있어서 실행 시간이 짧다. 최대 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 서비스를 워크플로에 넣을 수 있다.
• 워크플로에 사람이 개입해서 승인을 해야만 진행되는 단계를 설정할 수 있다.
• 어떤 지점에 이르러서는 사람이 결과를 확인하고 승인을 하면 다음 단계로 넘어 가고, 아니면 워크플로가 멈춰 실패하게 한다.
• 다양한 사용처가 있는데, 예를 들어 주문 이행이나 데이터 처리, 웹 애플리케이션 등 구성하기 복잡한 워크플로를 시각적으로 구성하려고 할 때 사용한다.

참고

Amazon Cognito을 사용해 모바일 사용자 계정을 페더레이션하거나 사용자에게 IAM 권한을 제공할 수 있으며, 사용자는 이를 통해 S3 버킷에 있는 개인 공간에 액세스할 수 있다.