AWS CCP 자격증 - 8 (ECS)

ECS

 

Docker?

도커(Docker)를 먼저 짚고 넘어가 보죠

도커에 대해서는 이미 들어보셨겠지만 여기서는 단순하게만 살펴볼 겁니다

도커란 앱 배포를 위한 소프트웨어 개발 플랫폼입니다

이전에는 Linux에 애플리케이션을 설치하고 그에 따라 작동하는 방식이었지만 도커를 사용하면 컨테이너에 앱을 패키징하게 됩니다

여기서 컨테이너란 모든 운영 체제에서 쉽게 실행할 수 있다는 점이 특별하다고 할 수 있겠습니다

앱이 컨테이너에 패키징되면 위치에 상관없이 매번 같은 방식으로 실행됩니다.

 

따라서 어떤 기계든 상관없이 호환성 문제가 없고, 동작을 예측할 수 있습니다 작업량도 적으며 유지 보수와 배포가 쉽죠

모든 프로그래밍 언어로 작업할 수 있으며 운영 체제나 기술에도 구애받지 않습니다

도커를 사용하면 몇 초 만에 컨테이너를 스케일링 업 다운이 가능하죠

이로 인해 오늘날 애플리케이션 배포에 있어서 도커가 아주 강력한 도구로 떠오른 겁니다

 

 

EC2 인스턴스에서 도커를 살펴보면

Java 코드로 실행하는 도커

NodeJS 코드를 실행하는 도커 MySQL 데이터베이스를 실행하는 도커 Java를 실행하는 도커 등이

모두 같은 EC2 인스턴스에 있습니다

따라서 도커 컨테이너에 애플리케이션을 패키징하기만 하면

 

EC2 인스턴스에서 실행하는 것이 아주 쉬워질 겁니다

도커 이미지는 따로 생성해 주어야 하는데

이는 컨테이너가 실행되는 방식으로

도커 리포지토리라는 장소에 저장됩니다 

이 주소에서는 공용 도커 리포지토리인 도커 허브를 이용할 수 있는데 여기서 여러 기술과 운영 체제에 대한 기본 이미지를 찾아볼 수 있습니다.

 

Linux 운영 체제인 Ubuntu와 데이터베이스 기술인 MySQL NodeJS, Java 등 프로그래밍 언어에 대해서 찾을 수 있죠

본 섹션에서 볼 사설 도커 리포지토리 Amazon ECR에는 개인 도커 이미지를 저장할 수 있습니다.

좀 더 심화된 내용입니다만, 도커와 가상 머신 중 어느 쪽을 사용할까요?

 

도커는 시각화 기술에 해당하지만 정확히는 아닙니다 리소스를 호스트와 공유하게 되는데

즉 하나의 서버에 여러 컨테이너를 둘 수 있다는 의미가 되죠

EC2와 도커를 비교해 보면 쉬울 겁니다 AWS 상에는 인프라가 있고 호스트 운영 체제 그리고 하이퍼바이저가 존재합니다하이퍼바이저에는 액세스가 없죠

여기에 EC2 인스턴스가 생성되면 게스트 운영 체제 위에 애플리케이션이 들어갑니다.

또 다른 EC2도 이처럼 생성되며 세 번째 EC2 인스턴스도 이처럼 인식될 겁니다

EC2 인스턴스를 만들 때에 수행되는 작업이라고 할 수 있죠

하지만 도커의 경우에는 인프라가 있고

EC2 인스턴스인 호스트 OS 그다음에 도커 데몬이 위치합니다 도커 데몬이 실행되면 그 위에 여러 컨테이너를 실행할 수 있습니다.

이들은 아주 가볍고 패키징된 상태가 아니며 전체 운영 체제나 가상 머신 없이 실행됩니다.

도커를 다용도로 활용하고 스케일링이나 실행이 쉬운 이유라고 할 수 있죠

이렇게 도커의 개요를 살펴봤습니다

 

ECS

ECS = Elastic Container Service

도커 컨테이너를 실행할 때 사용합니다.

동작하기 위해서는 어딘가에서 도커 컨테이너를 실행해야 하는데  ECS에서는 반드시 여러분이 프로비저닝해야 하며

인프라를 자체적으로 유지해야 합니다

그 말은 EC2 인스턴스를 사전에 만들어야 한다는 뜻입니다.

AWS가 여러분을 위해 컨테이너를 시작하고 중지하는 것을 책임지며

사용자가 웹 애플리케이션을 ECS에서 만들기 원한다면

애플리케이션 밸런서와의 통합을 책임집니다

그림에서처럼 여러 EC2 인스턴스가 있고 우리는 사전에 이 EC2 인스턴스를 만들어야 합니다.

이들은 ECS 서비스에 의해 다른 컨테이너에서 실행됩니다

ECS 서비스는 새로운 도커 컨테이너를 가질 때마다 어떤 EC2 인스턴스를 도커 컨테이너에 위치할지 알고 있습니다.

따라서 시험에서 AWS 도커 컨테이너 실행이 나온다면 ECS를 생각하세요

 

Fargate

Fargate 또한 AWS에서 도커 컨테이너를 실행할 때 사용합니다

그러나 Fargate에서는 인프라를 프로비저닝할 필요가 없습니다

EC2 인스턴스를 만들 필요가 없고 관리할 필요가 없죠

AWS가 제공하는 매우 간단한 서비스입니다

이는 서버리스 서비스인데요 우리가 관리할 서버가 없기 때문입니다.

AWS는 우리가 필요한 컨테이너를 각 컨테이너의 CPU와 RAM 사양에 맞게 실행시켜 줍니다.

 

따라서 Fargate를 사용하는 것이 훨씬 간편합니다.

Fargate가 여기 있습니다 여기 새로운 도커 컨테이너가 Fargate에서 실행됩니다

Fargate는 자동으로 이 컨테이너를 실행해 줍니다.

 

어디에 있는지 우리가 알지 못하지만 실행될 것입니다

Fargate 관련 기본 아이디어는 어떤 EC2 인스턴스도 관리하지 않기 때문에 쉽게 사용할 수 있습니다.

ECS에서는 EC2 인스턴스를 먼저 만들었지만 Fargate에서는 그럴 필요가 없죠

러나 두 개의 서비스 모두 AWS에서 도커 컨테이너를 실행하게 해줍니다

 

ECL (Elastic Container Registry)

마지막으로 AWS에서 실행되기 위해서

도커 이미지를 저장해야 하는데요

이때 컨테이너 레지스트리가 필요합니다

여기에 ECR을 사용할 수 있는데요 바로 일래스틱 컨테이너 레지스트리입니다

 

AWS의 사설 도커 레지스트리입니다

도커 이미지를 저장하여 ECS 서비스나 Fargate 서비스에 의해 실행됩니다.

두 번째 예시로 ECR과 Fargate가 있습니다 애플리케이션의 이미지를 Amazon ECR에 저장하고자 합니다.

그러면 Fargate는 이 이미지를 살펴보고 이들로부터 컨테이너를 만들어 Fargate 서비스에서 직접 실행합니다.

여기에서 한 컨테이너, 여기에서 한 컨테이너가 될 수 있죠

그러나 이것은 ECR이기 때문에 여러 이미지를 가질 수 있고 Fargate에 여러 컨테이너를 만들 수 있습니다.

 

ECS, Fargate, ECR 비교해서 기억하시면

시험에서 관련 문제를 모두 푸실 수 있으실 겁니다

 

서버리스란?

 

 

서버리스가 무엇일까요? 서버리스는 귀에 익지만 개발자가 서버를 관리하지 않는 새로운 패러다임입니다.

그저 가장 잘하는 것을 합니다 코드 또는 함수를 배포하는 일이죠

 

처음에 서버리스는 AWS Lamdba와 함께 서비스형 함수로 만들어졌습니다.

즉, 코드를 배포하고 각 함수는 Lambda 서비스에 의해 독립적으로 실행됩니다.

 

그러나 요즘 들어서는 서버리스라는 뜻은 "관리되는 어떤 것"으로 여기에 사용자에 의한 서버 관리가 포함됩니다

즉, 서버리스 데이터베이스, 메시지, 스토리지 등을 포함합니다 따라서 서버리스는 서버가 없다는 뜻이 아닙니다

이면에 서버가 존재합니다 그렇지 않고서 서비스가 동작할 수 없죠

이 말은 최종 사용자 입장에서 서버를 관리하거나 프로비저닝하거나 심지어 볼 수 없다는 뜻입니다.

 

Amazon S3가 예시중 하나입니다.

 

우리가 스토리지 계층으로 사용했지만 어떤 서버도 관리하지 않았기 때문입니다.

Amazon S3는 무한대로 스케일링할 수 있고 서버가 없습니다. 그저 파일을 업로드하면 됐습니다.

 

DynamoDB도 마찬가지입니다 DynamoDB에서 테이블을 만들었죠 테이블을 위해 서버를 프로비저닝하지 않았습니다.

서버와 테이블은 수신하는 로드에 맞게 오토 스케일링할 수 있었죠 따라서 서버리스 서비스입니다.

 

도커 컨테이너를 실행할 때 사용하는 Fargate도 있습니다.

ECS에서는 도커 컨테이너를 실행하기 위해 EC2 인스턴스를 만듭니다 따라서 서버리스가 아니죠

그러나 Fargate에서는 도커 컨테이너를 보내면 Fargate에서 자동으로 실행 방법을 찾아 실행합니다 이 때문에 서버리스 서비스가 됩니다

AWS Lambda

EC2 인스턴스를 이용하면 클라우드에 가상 서버를 갖게 됩니다.

그러나 메모리의 용량과 CPU 성능에 제한을 받게 됩니다.

우리가 사용하지 않을 때도 지속해서 실행됩니다. 스케일링하고 싶을 때는 오토 스케일링 그룹을 사용합니다.

 

이 말은 시간이 지남에 따라 서버를 추가하거나 제거한다는 뜻인데 때때로 오래 걸리거나 구현이 복잡할 수 있습니다

 

Lambda에서는 이를 새롭게 생각해 볼 수 있습니다

이 경우, 서버가 필요하지 않고 가상 함수를 가지게 됩니다 이 함수들은 시간에 제한을 받는데 짧은 유형의 실행을 위한 것입니다

 

수요에 따라 실행함으로 함수를 실행할 때마다 실행될 것입니다

함수가 필요하지 않다면 실행하지 않을 것이고 이를 위해 구축하지 않을 것입니다.

스케일링이 필요하면 Lambda 서비스의 일부분으로 자동으로 됩니다

Lambda가 AWS에서 인기 있는 서비스가 된 이유입니다

 

Benefits of AWS Lambda

AWS Lambda를 사용하는 혜택은 먼저 가격 정책이 매우 쉽습니다.

요청 당 및 컴퓨팅 시간당 비용을 지불하게 되는데 프리 티어도 넉넉합니다.

 

매달 백만 개의 Lambda 호출과 40만 GB-초의 컴퓨팅 시간을 줍니다.

이 말은 괜찮은 서비스를 Lambda에서 공짜로 실행할 수 있다는 뜻입니다.

 

또한 전체 AWS 서비스와 통합됩니다 지금까지 본 많은 서비스와 통합할 수 있죠 중요한 점은 이벤트 기반이라는 것입니다

즉, 이벤트가 일어났거나 필요할 때 함수가 AWS에 의해 호출됩니다.

Lambda가 반응형 서비스인 이유입니다

 

시험에 중요하게 나옵니다 많은 프로그래밍 언어와 완전히 통합되며 CloudWatch를 통해 쉽게 모니터링할 수 있습니다.

CloudWatch가 무엇인지 배우지 않았지만 이는 AWS에서 솔루션을 모니터링합니다.

 

마지막으로 함수당 리소스를 가져오기 쉽습니다 함수당 10GB의 RAM을 사용할 수 있는데 RAM을 증가하면 CPU와 네트워크 품질 역시 개선되고 모든 것이 좋습니다

 

또한 Lambda는 많은 언어를 지원합니다. 

 

Lambda의 사용사례 

서버리스 섬네일 생성 서비스입니다

예를 들어, S3 버킷이 있고 여기에 이미지를 추가한다고 생각해보면, 사용자는 해변 이미지를 S3 버킷에 업로드합니다.

 

S3 버킷은 람다 함수를 트리거하고 이미지가 업로드되면 람다 함수가 이미지를 가지고 섬네일로 만들 것입니다.

섬네일은 Amazon S3으로 다시 보내죠 섬네일은 이미지의 작은 버전이죠

또는 섬네일 관련 메타데이터를 DynamoDB에 보낼 수도 있습니다.

이미지 크기, 이름, 생성 날짜 등등을 포함할 수 있습니다

이 모든 것은 완전히 이벤트 기반이고 완전히 서버리스입니다

 

S3에서 서버를 프로비저닝하지 않고 Lambda에서도 프로비저닝하지 않죠

DynamoDB에서도 마찬가지로 서버를 프로비저닝하지 않습니다.

좋은 패턴입니다 서버리스 섬네일 생성이 아주 잘 스케일링할 것이기 때문입니다.

서버를 프로비저닝하는 것과 서비스를 스케일링하는 것 관련해서 걱정할 필요가 없습니다.

 

Lambda에서의 다른 사용 사례로 서버리스 CRON 작업 생성이 있습니다.

 

CRON은 스케줄을 정의하게 해주는데 예를 들어, 매시간, 매일 또는 월요일마다 스케줄에 맞게 스크립트를 실행합니다.

기본값으로 CRON 작업은 Linux AMI에서 실행하는데 즉, Linux 머신이죠 그러나 서버리스이기 때문에

EC2 인스턴스를 프로비저닝할 수 없습니다 대신, CloudWatch Events 또는 EventBridge라는 것을 사용합니다.

 

매시간 람다 함수를 트리거하여 작업을 효과적으로 실행합니다 여기에 서버가 없는데, CloudWatch Events와 Lambda가 서버리스기 때문입니다.

 

람다 함수를 통해서 매시간 효과적으로 스크립트를 실행합니다 이것이 트리거입니다.

 

AWS Lambda Pricing (중요)

기본적으로 요금은 요청마다 지불합니다 (Pay per Calls)

처음 백만 번의 Lambda 호출은  무료입니다 또한 매우 저렴하죠. (프리티어)

그 이후에 백만 개의 요청당 0.20달러를 지불합니다

 

기간으로도 비용을 지불해야 하는데요 (Pay per duration)

프리 티어는 400,000GB-초의 컴퓨팅 시간이 무료로 제공됩니다.

즉, 함수가 1GB의 RAM을 갖는다면 400,000초입니다.

또는 함수가 120MB의 RAM일 때 320만 초입니다 그 이후로 600,000GB-초에 1달러를 지불합니다

결론은 AWS에서 Lambda를 실행하는 것은 매우 저렴합니다

따라서 서버리스 애플리케이션과 웹사이트를 실행할 때 인기 있는 서비스이기도 합니다.

CCP 시험에서는 호출과 기간에 따른 Lambda 가격을 알아야 합니다

 

Amazon API Gateway

시험에서는 서버리스 HTTP API를 구축하는 사용 사례로 나옵니다.

 

이 예시에서는 서버리스 기술이 있습니다

바로 Lambda를 사용하여 DynamoDB로부터 데이터를 읽고, 만들고, 업데이트하고 삭제합니다.

둘 다 서버리스 기술이지만 외부의 클라이언트가 람다 함수에 접근하게 하고 싶습니다.

그러나 람다 함수는 API로 바로 노출되지는 않습니다

API Gateway를 통해 노출해야 합니다.

이는 REST HTTP API를 클라이언트에게 제공하여 웹사이트에 직접 연결합니다.

 

클라이언트는 API Gateway에 통신합니다 API Gateway는 요청을 람다 함수에 프록시합니다.

이는 데이터를 변환하죠 API Gateway는 완전 관리 서비스에 사용되며 개발자가 클라우드에서 쉽게 만들고, 게시하고, 유지하며, 모니터링하고 안전한 API를 사용하게 합니다.

서버리스 기술로 완전히 스케일링 가능합니다

RESTful APIs와 데이터의 실시간 스트리밍을 위해 WebSocket APIs를 지원합니다 보안, 사용자 인증, API 스로틀, API 키, 모니터링 등을 지원합니다.

시험에서 서버리스 API를 만들 때를 묻는다면 API Gateway와 Lambda를 생각하셔야 합니다

 

AWS Batch

일괄처리(batch processing)란 컴퓨터 프로그램 흐름에 따라 순차적으로 자료를 처리하는 방식

 

일괄처리 = 개별적으로 어떤 요청이 있을 때마다 실시간으로 통신하는 것이 아닌, 한꺼번에 일괄적으로 대량 건을 처리하는 것.

특히 배치는 보통 정해진 특정한 시간에 실행된다.

 

1. 대량건의 데이터를 처리한다

2. 보통 특정 시간에 실행된다

3. 일괄적으로 처리한다

 

배치 작업에는 시작과 끝이 있습니다

이는 절대 끝나지 않고 항상 실행되는 지속적 또는 스트리밍 작업과 반대에 해당합니다.

배치 작업이란 예를 들어, 오전 1시에 시작하여 3시에 끝납니다 배치 작업은 특정 시점에 일어납니다

따라서 배치 서비스는 동적으로 EC2 인스턴스 또는 스팟 인스턴스를 실행하여

해당 배치 작업을 실행하는 로드를 수용합니다.

배치는 배치 대기열처리에 적합한 양의 컴퓨팅과 메모리를 프로비저닝할 수 있습니다

여러분은 그저 스케줄 된 배치 작업을 배치 대기열에 제출하면 됩니다 나머지는 배치 서비스가 알아서 해주죠

배치 작업은 어떻게 정의할까요?

간단히 도커 이미지와 테스트 정의로 ECS 서비스에서 실행됩니다 이 말은 ECS에서 실행할 수 있는 어떤 것이든

배치에서 실행할 수 있다는 뜻이죠 배치 작업을 실행하는 데 배치를 사용하는 것은 매우 유용합니다

자동으로 EC2 인스턴스 또는 스팟 인스턴스의 알맞은 개수로 스케일링해주고 작업을 실행합니다

따라서 비용 최적화를 할 수 있고 인프라에 덜 신경 써도 됩니다 배치 작업에만 집중할 수 있죠

예를 들어 사용자에 의해 Amazon S3에 배치 방식으로 제출된 이미지를 처리하고자 할 때

이미지는 Amazon S3에 보내지고 이것은 배치 작업을 트리거 합니다.

배치는 자동으로 EC2 인스턴스나 스팟 인스턴스로 만들어진 ECS 클러스터를 갖게 되고 배치를 인스턴스의 개수가 배치 대기열에 있는 배치 작업의 로드를 수용하는 데에 적절한지 확인합니다

이 인스턴스들은 작업을 수행할 도커 이미지를 실행하게 됩니다

처리된 객체를 삽입하는 작업이 될 수도 있고 다른 Amazon S3 버킷으로 이미지를 필터 처리할 수도 있습니다

문제는 Batch와 Lambda의 차이점을 구분하느냐입니다

비슷하게 보이기 때문이죠

Lambda에는 15분이라는 시간의 한계가 있어요

또한 몇 개의 프로그래밍 언어로만 접근할 수 있습니다

거기에 임시 디스크 용량이 제한되어 작업을 실행하기 원한다면 서버리스여야 합니다

반면, Batch는 다릅니다

EC2 인스턴스에 의존하기 때문에 Batch에는 시간 제약이 없습니다.

런타임은 도커 이미지로 패키징 하기만 하면 원하는 만큼 가질 수 있습니다

스토리지의 경우, EC2 인스턴스의 스토리지에 의존합니다

EBS 볼륨이 될 수도, 디스크 용량을 위한 EC2 인스턴스 스토어일 수도 있죠

람다 함수보다는 더 많습니다

마지막으로 Batch는 서버리스 서비스가 아닙니다 관리 서비스이지만 EC2 인스턴스가 실제로 만들어져야 하죠

그러나 AWS가 EC2 인스턴스를 관리하기 때문에 오토 스케일링 등에 관해 걱정할 필요는 없어요

 

Amazon Lightsail

 

Amazon Lightsail은 AWS에서 약간 독특한 서비스로 독립 실행형 서비스입니다.

 

Lightsail을 사용하면 가상 서버 스토리지, 데이터베이스 및 네트워크를 한 곳에서 구축할 수 있습니다.

Lightsail은 가격이 저렴하고 예측 가능합니다

사람들이 Amazon Lightsail을 사용하는 이유는 우리가 배운 EC2 RDS, ELB EBS, Route53와 같은

서비스를 사용하는 것보다 훨씬 더 쉽기 때문입니다

즉 Lightsail은 클라우드 사용 경험이 거의 없고 서비스의 복잡한 작동 방식을 익히고 싶지 않은 사람들을 위해

만들어진 서비스입니다

 

네트워크 작동 방식이나 서버, 스토리지 작동 방식을 배우지 않고 서비스를 사용하는 것입니다.

 

Lightsail은 사용자가 AWS의 작동 방식을 배울 때 사용할 서비스는 아니지만 클라우드 경험이 전혀 없는 사람이라면

Lightsail를 사용할 수 있을 것입니다

Lightsail에서도 리소스에 대한 모니터링 알람 설정을 할 수 있습니다.

Lightsail 사용 사례는 LAMP 스택, Nginx, MEAN Node.js 등을 사용한 아주 간단한 웹 애플리케이션을 배포한다면

 

Lightsail에는 해당 템플릿들이 있습니다 Wordpress나 Magento, Plesk, Joomla 등을 사용한 간단한 웹 사이트는

Lightsail에서 템플릿을 사용해 아주 쉽게 배포할 수 있습니다

마지막으로 AWS에 구축된 개발 또는 테스트 환경이 있는 경우에도 Lightsail은 좋은 선택지입니다.

Lightsail에는 고가용성 개념이 있지만 오토스케일링은 지원하지 않고 AWS에 제한적으로 통합됩니다

요약하자면 Lightsail은 클라우드 사용 경험이 없고 복잡한 설정 없이 저렴하고 예측 가능한 가격으로

서비스를 빠르게 시작하려는 사람에게는 Lightsail이 좋은 선택이 될 것입니다

 

이런 경우가 아니라면 Lightsail은 언제나 틀린 답입니다

 

컴퓨팅 서비스 요약

 

도커는 애플리케이션을 실행시킬 수 있는 컨테이너 기술입니다

그리고 AWS에서 도커를 어떻게 실행시키는지를 공부했습니다

첫 번째 방법은 ECS를 사용하는 것입니다.

ECS를 사용하면 도커 컨테이너를 EC2 인스턴스에서 실행시킬 수 있습니다.

하지만 그전에 먼저 인스턴스를 프로비저닝 해야 합니다

 

다른 방법인 Fargate를 사용하면 인프라 프로비저닝이 없고 과정이 보이진 않지만

동일하게 도커 컨테이너를 사용할 수 있습니다

그리고 Fargate는 서버리스 서비스입니다

도커 컨테이너를 실행하기 위해 EC2 인스턴스를 관리하지 않기 때문입니다

도커 이미지 리포지토리를 가진 ECR을 이용해서 도커 컨테이너를 AWS에 저장할 수도 있습니다

배치 서비스도 공부했습니다 배치를 사용하면 사용하고 있는 여러 EC2 인스턴스에

배치 작업을 실행할 수 있습니다.  배치 서비스는 ECS 위에서 실행됩니다

마지막으로는 저렴하고 예측 가능한 비용으로 애플리케이션을 실행할 수 있는 새로운 유형의 서비스이자

데이터베이스 기술인 Lightsail을 공부했습니다 Lightsail은 대부분 변별력 문제로 출제됩니다

 

람다 요약

Lambda는 서버리스 서비스로 서비스로서의 기능을 제공하며 원활한 스케일링을 가능하게 합니다.

초 당 한 번의 호출에서 수천 번의 호출까지 완전히 반응적으로 대응합니다.

람다에는 두 가지 결제 방식이 있습니다

 

람다 함수에 대한 메모리 프로비저닝 양에 실행 시간을 곱하는 방식과

람다 함수가 호출된 횟수를 계산하는 방식이 있습니다

지원하는 언어를 살펴보면 람다는 다양한 프로그래밍 언어를 지원합니다.

컨테이너 이미지를 지원하기는 하지만 그것을 위해서는 특정 런타임 API를 구현해야 합니다

따라서 람다는 임의의 도커 이미지를 지원하지는 않습니다

임의 도커 이미지를 쓰려면 ECS나 Fargate를 사용할 수 있습니다

 

하지만 사용하려는 도커 이미지에서 람다 컨테이너 런타임 API를 구현하면

도커 이미지를 람다에서 실행할 수 있습니다

하지만 일반적인 방법은 아닙니다

호출 시간은 최대 15분입니다

 

람다의 사용 사례는 Amazon 이력에 업로드된 이미지의 섬네일을 만들거나

또는 서버리스 CRON 작업을 실행하는 것입니다

마지막으로 우리가 만든 람다 기능을 API로 공개하고 싶다면

API Gateway라는 또 다른 서버리스 서비스를 사용할 수 있습니다

API Gateway를 사용하면 함수를 HTTP API로 공개할 수 있으며

보안, 스로틀링, API 키 등의 기능도 사용할 수 있습니다