<386 SAM 개요 >
> SAM 은 CF 의 축약 버전 느낌으로, 개발자들 영역에서 조금 더 친화적인듯 (SAM 은 387강 내용 정도로도 시험에는 충분하다고 함)
> 서버리스 앱을 개발 & 배포하는 Framework
> 앱을 개발하고, SAM 과 연계되는 Configuration 을 YAML 로 작성한다
> 이 간단한 SAM YAML 로 AWS 는 복잡한 CF 를 기동시킨다 (CF 가 지원하는 모든 것들을 사용할 수 있음 : Output, Mappin, Params, Resources 등)
> SAM 은 내부적으로 CodeDeploy 를 사용하여 람다 함수를 배포할 수 있다.
> 또한 API Gateway, Dynamo DB, Lambda 등을 LOCAL 환경에서 사용할 수 있도록 지원한다
요약 > 서버리스 앱 개발에 중점을 두고, 로컬에서 디버깅할 수 있게 하고, CF 를 사용해서 배포할 수 있도록 하는 거
<Recipe>
> SAM 은 Recipe 로 구성, 맨 위에 SAM 템플릿임을 나타내는 헤ㅐ더가 추가된다
>> Transform: 'AWS::Serverless-2016-10-31'
> 템플렛 코드를 작성할 때는 CF 가 아닌 SAM Construct (규격?) 을 사용한다
>> AWS::Serverless::Function (for Lambda)
>> AWS::Serverless::Api (for API Gateway)
>> AWS::Serverless::Simpletable (for DD)
> 패키징하고 배포를 위해서 "sam deploy" 명령어를 사용 (pckg 기능 포함)
> SAM Accelerate 을 사용해서 로컬의 람다 변경 사항을 빠르게 동기화하는 명령도 있음 : "sam sync --watch"
<SAM 배포 살펴보기>
> 앱 Code 들과 SAM 템플렛이 있는 상황 > Locally "sam build" 를 수행하여 통합 앱을 로컬로 형성함
> 그럼 CF Template 이 나옴 (이후로는 CF에서 하던 짓)
> 이를 zip 하고 S3 에 업로드를 하고, create/execute Change Set(수정) 을 CF 단에 하게되면, CF 변경이 기동된다
>> 서버리스라 3개 서버리스 대표 리소스들이 주요 대상인듯?
<SAM Accelerate>
> 그냥 전체 CF execution 하는거 번거로우니까 (소소한 람다 작업에도) 단계별로 잘라서 해보는거 지원하는거임 ㅇㅇ
> AWS에 리소스를 배포하는 중 지연 시간을 줄이는데 사용되는 일련의 기능
> sam sync 명령어 - 현 프로젝트를 SAM 으로 배포할것임?으로 AWS에게 알려주는거인가? ㅋㅋㅋㅋㅋ ㅅㅂ
> Service API 를 사용하여 코드만 바뀌었을 경우 AWS 는 인프라를 모두 update 하지 않는다 (bypass CF)
> 위 그림 상황에서 sam sync 를 사용하면, 앱 코드를 로컬에서 변경할 경우 SAM은 이 코드를 자동으로 람다 함수와 동기화함
> 로컬 개발후 Cloud 에서 람다 기능 테스트를 새 람다 업데이트 배포하기 전에 빠르게 test 하고 싶다면 Accelerate 기능 쓰면 된다고 한다 ㅋㅋ
>> 솔직히 ㅅㅂ 이거 쓸 정도로 귀찮으면 걍 접어야 하는거 아님? ㅈ 같네
> sam sync - 그냥 사용하면, code & infra 를 동기화한다
> --code - 코드만 동기화한다 (CF 를 사용하지 않음, 업데이트가 매우매우빠름)
> --code --resource AWS::Serverless::Function (예시) - 람다 함수와 해당 종속성에 대해서만 업데이트 한다 (특정 리소스 지정)
> --code --resource-id HelloWorldLambdaFunction - 리소스의 ID 를 명시하여 동기화한다
> --watch - 파일 변경 사항들을 지속 모니터링한다! 그리고 변경사항을 감지시 automatically synchronize 함 (진짜 극한의 귀찮음 해결이다 ㅋㅋㅋㅋ)
>> --code 까지 포함되면 코드만 모니터링 함, 없으면 configuration 가지 모니터링함
--------------------------------------------------
<388 SAM CLI>
> 387 강 들으면 당연히 느낌 오겠지만 로컬 위주임. 로컬에서 클라우드랑 연계시켜주는거 위주.
> 왜냐면 클라우드 영역에 들어갈땐 로컬에서 build 해서 CF Template 을 만들기 때문에, SAM 은 로컬 Framework 이라고 보는게 맞는듯
> 굳이 설치하진 않음. AWS 공식 문서를 참고하면 SAM 을 설치할 수 있다
--------------------------------------------------
<389 SAM 프로젝트 생성>
> SAM 을 직접 사용하는거라 그냥 강의만 들음
> sam init 명령어를 사용하면 많은 파일들을 한번에 해결하므로, 하나씩 무슨 일을 하는지 살펴보자고 함
> 한 폴더를 패키지로 삼아, root 경로 내부에 src 폴더를 만들고 그 안에 app.py 를 둠 (샘플로 가져옴)
# 패키지 구조
/src
ㄴ app.py
/gen # 미리 준비해두는 경로
ㄴ template-generated.yaml # 명령 수행 이후 생성되는 CF 런칭용 파일
commands.sh
template.yaml
> root 경로에 template.yaml 로 SAM File 을 만든다
> root 경로에 실행할 명령어들을 작성할 commands.sh 를 만든다
# template.yaml
# SAM FILE
AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: SAM 템플렛에 대한 설명
Parameters:
IdentityNameParameter:
Type: String
Resources:
helloworldpython:
Type: 'AWS::Serverless:Function'
Properties:
Handler: app.lambda_handler # {python 파일이름}.{람다 함수이름}
Runtime: python3.6
CodeUri: src/
Description: 람다함수 설명
MemorySize: 128
Timeout: 3
> template.yml 파일도 다운 받는데, 제일 위에 Transform Key 가 있는 것을 확인할 수 있다 (이거 시험에 자주나옴, 나오면 무조건 SAM)
> 리소스는 람다 함수임을 알 수 있다
> 속성: Handler: 파일이름.함수이름 인걸 알 수 있다
>> 따라서, 우리가 정한 함수 이름처럼. app.py 로 바꿔서 app.lambda_handler 로 속성을 바꿔줘야 함
> Code Uri 는 root 가 아닌 root 내 src 다이렉토리에 있다
> MemorySize 랑 Timeout 등도 설정할 수 있다
>> 가장 간단한 SAM 설정
-----------------------------------
<390강 SAM 배포>
> 배포 과정 Script 는 commands.sh 에 준비하는 것 같고, 다음과 같이 정리가 되었다
# Create an S3 Bucket
aws s3 mb s3://{bucket-name}
# PCKG to CF Template ($sam package ~ 로 해도 동일한 결과)
aws cloudformation package --s3-bucket {bucket-name} --template-file {SAM-Template-File-Name} --output-template-file gen/{CF-Template-File-Name}
> AWS CLI 를 사용하여 우선 S3 버킷 먼저 생성한다 (중복 이름이면 오류 발생함 ㅇㅇ)
> 다음으로는 cf 를 패키징 하는 것 (s3 버킷을 필수적으로 명시, template file 도 필수적으로 명시, output file 도 gen 디렉터리에 생성되므로 명시 (gen 디렉토리 생성함)
>> gen 경로 내에 최종적으로 패키징된 CF Template 이 생성된다 (이걸 CF에 업로드 해야함)
> 그래서 generated 된 파일을 살펴보면 다음과 같음
# CF Packaged File
AWSTemplateFormatVersion: '2010-09-09'
Description: 기존 Template 설명
Resources:
helloworldpython:
Properties:
CodeUri: s3://{s3-bckt-name}/{file-name} # 코드가 자기 디렉토리가 아닌 s3 를 참조하도록 변경
Description: Lambda 에 대한 설명
Handler: app.lambda_handler
MemorySize: 128
Runtime: python3.6
Timeout: 3
Type: AWS::Serverless::Function
Transform: AWS::Serverless-2016-10-31
> 다른건 다 동일한데, Code 를 참조하는 곳이 이젠 S3 임을 알 수 있다 (코드가 S3에 업로드 되었고 CF 에서 이를 인지할 수 있도록 주소가 명시된다)
> 이후로는 지속적으로 commands.sh 에 다음과 같은 명령어를 더 실행한다 (기록용인듯ㅇㅇ)
# CF에 배포
aws cloudformation deploy --template-file {CF-Template-File-With-Dir} --stack-name hello-world-sam
> 가장 처음에 실행하면 FAIL 함. CAPABILITY_IAM 이 없어서 그렇다고 함
> 그래서 위 명령어 뒤에 다음과 같은 capability option 을 추가한다 (IAM Role 을 알아서 추가하라는 옵션인듯?)
$ ~~ --capabilities CAPABILITY_IAM
> CF 로 이동해보면 (CLI 가 동작한 지역으로) Stack 이 생성되고 있고, Create 이 진행되고 있음이 띄워진다.
> 생성 완료 후 Resource 를 보면, LambdaFunction 과 IAMRole 두 개의 리소스가 생성됨을 알 수 있다
> 실제 람다로 이동하면 hello-world-sam 의 이름을 가지고 시작하는 함수를 볼 수 있고, 우리가 설정한 python 이 업로드 되어 있는걸 볼 수 있다
-----------------------------------
<391강 SAM 과 API Gateway>
> 이번엔 API Gateway 와 연동하는 것을 알아본다. 아까 Template 그대로 쓰는데 API Gateway 부분을 추가한다
> 우선 app.py 를 다음과 같이 수정한다
# API Gateway 가 지원하는 응답 형식
def respond(err, res=None):
return {
'statusCode': '400' if err else '200',
'body': err.message if err else json.dumps(res),
'headers': {
'Content-Type': 'application/json',
},
}
# 응답을 API Gateway 에 맞춰서 응답하도록 변경
def lambda_handler(event, context):
print("Received Event: " + json.dumps(event, indent=2))
return respond(None, res="hello world!")
> template.yml 도 더 수정한다
# 위 template.yml 에서 이어서 작성
...
Timeout:3
Events:
HelloWorldSAMAPI: # /hello 경로를 GET 으로 호출시 위 Lambda 함수를 호출한다
Type: Api
Properties:
Path: /hello
Method: GET
> 위에서 수행했던 CF packaging command 를 다시 실행하여 CF Template yml 을 다시 생성한다
> 그리고 Deploy 도 똑같이 수행을 하고, CF 로 이동해보자
> 새로운 Stack 이 생기는게 아니라 새로고침을 하면 UPDATE_IN_PROGRESS 를 볼 수 있고, 완료시 훨씬 많은 것들이 생겼음을 알 수 있다
> 이게 개쩌는거다. 우리가 지금까지 Lambda, ApiGateway 를 공부했는데, 일일이 다 생성했던 것들이다. Stage, API, Deployment, Permission 등등..
> 이런걸 간단한, 솔직히 그렇게 어렵지 않은 Template 하나로 모든걸 제어할 수 있다는게 강력한 것
> API Gateway 로 이동해서 구경하면, hello-world-sam API 가 생성되어 있고, 그 안에 /hello 경로 내부 GET 함수가 생성되어 있음
> python 에서 잘못된 걸 발견 > 수정 > 다시 package 및 deploy 명령어 실행 > CF 에서 변경점 Catch 후 반영해줌
-----------------------------------
<392강 SAM 과 Dynamo DB>
> 이제 마지막 서버리스 자원인 (범위내) DD 와의 연동을 알아본다
> 통신 / 함수 / DB 까지 완전한 서버리스 형태를 만들 수 있는것!
> 다시 한번 수정을 하는데, Python 을 아래와 같이 수정한다
import boto3
import json
import os # 환경변수 OS 로 부터 가져오기
# DB Client 는 핸들러 외부에 하는거 기억!(람다)
region_name = os.environ['REGION_NAME'] # 환경변수 가져오므로, Template 에 명시해줘야 함
dynamo = boto3.client('dynamodb', region_name=region_name) # 현재 리전으로 설정
table_name = os.environ['TABLE_NAME']
# API Gateway 가 지원하는 응답 형식
def respond(err, res=None):
return {
'statusCode': '400' if err else '200',
'body': err.message if err else json.dumps(res),
'headers': {
'Content-Type': 'application/json',
},
}
# 응답을 API Gateway 에 맞춰서 응답하도록 변경
# 특정 테이블의 전체 내용을 반환하는 함수
def lambda_handler(event, context):
print("Received Event: " + json.dumps(event, indent=2))
# DD 에서 조회한걸 반환해보자 (FULL SCAN)
scan_result = dynamo.scan(TableName=table_name)
return respond(None, res=scan_result)
> Template 도 하기와 같이 추가된다
# Template 을 이어서 추가한다
...
Resources:
helloworldpython:
Type: AWS::Serverless::Function
Properties:
Handler: app.lambda_handler
...
Timeout: 3
Environment:
Variables:
TABLE_NAME: !Ref Table # CF 에서 배웠던 다른 자원 Reference 하기 (아래 Table 을 가져옴)
REGION_NAME: !Ref AWS::Region # Pseudo Params : AWS 가 CF 템플렛 내에서 직접 지원하는 Params
Events:
HelloWorldSAMAPI:
...
# 또한 람다 함수가 직접 아래 DD 를 접근하므로, 적합한 권한을 줘야함
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref Table # 사실 이건 String 이여야 하는데 이거가 뭘 뜻하는지 정확히 모르겠음. 아래 이름..?
Table: # 새로 추가됨, 참고로 Template 내용들은 알아보면 훨씬 많게 설정할 수 있음 (각각 배울 때 했던 것들 거의 다 할 수 있음)
Type: AWS::Serverless:SimpleTable
Properties:
PrimaryKey:
Name: {column_name}
Type: String
ProvisionedThroughput: # 처리하는 친구들 (Unit) 정하는거
ReadCapacityUnits: 2
WriteCapacityUnits: 2
> 계속 똑같이 Packaging 하고, Deploy 하고, UPDATE 완료까지 본다
> 아까랑 똑같은데 하나가 늘어나 있다 (DynamoDB::Table Resources 가 형성됨)
> DD로 이동해보면 실제로 하나가 생겨있고, greeting 이라는 칼럼이 있음 (몇 개 item 들 테스트로 넣음)
> Lambda 의 IAM Role 을 확인해보면 형성된 Role 로 기입되어 있음
> 이 Role 로 이동해보면 우리가 원했던 "LambdaBasicExecutionRole" 과 "DD 내 {위 테이블이름} 에 대한 Get,Delete, Put, Scan ...등등 모든 DD 관련 Action Policy " 가 추가됨
>> AWS 관리 Policy 가 아닌, 새로운 inline policy 를 CF 가 직접 만들어서 DD 관련된걸 넣어주게 됨
> 최종적으로 /hello 를 API Gateway 를 통해 호출해보면, 아까 넣어둔 모든 Item 들이 Response Body 로 전달되는 것을 확인할 수 있다 (아까 람다 함수의 respond 에 따라서) (JSON 으로 응답받는 API)
> 상당히 개쩔긴 하는듯..!!!
-----------------------------------
<393강 SAM Policy Templates : 정책 템플렛, Serverless Model Policy Template>
> Policy Template : 람다 함수에 권한을 적용할 수 있는 Template 들의 목록, 대표적인 항목들만 확인
> 대표적인 항목들은 이름이 꽤나 직관적이라, 무슨 역할을 하는지와, 어떻게 template 에 명시되는지만 알아두자
> S3ReadPolicy
>> S3내의 객체에 대하여 읽기 권한만 부여하는 Policy Template
> SQSPollerPolicy
>> 람다 함수가 SQS Queue 로 부터 Poll 을 할 수 있도록 한다
> DynamoDBCrudPolicy
>> 람다 함수가 DD에 대하여 CRUD 를 수행할 권한을 부여하는 Policy Template
> IAM 을 생성하기 보단 SQSPoll 에 대한 Policy Template 을 활용한다
>> SAM Policy Template 이 SAM 프레임워크가 활용할 때, IAM Policy 로 변화하여 람다에 적용된다
> 함수의 역할을 쉽게 파악할 수 있고, IAM 과 같은 복잡한 권한 설계에 대한 걱정이 크게 사라진다
-----------------------------------
<394강 SAM 과 Code Deploy 의 연동>
> SAM 이 CD 를 활용해서 람다 배포를 진행한다
> 람다 Alias 를 활용한 Traffic Shifting 기능을 활용한다
> Pre-Post Traffic Hook 을 정의하여 배포가 정상적으로 진행되었는지 확인할 수 있다 (위에 말한 Traffic Shift 전/후로)
> CW Alarm 을 활용하여 Rollback 을 쉽게 자동화할 수 있다
> CD 는 또 다른 람다 함수를 이용해서 Pre-Traffic Hook 을 먼저 진행한다 (준비 확인, 선택사항)
> 우리가 정한 update strategy 를 따라서 V2 Alias 로 트래픽을 이전한다
> CW Alarm 을 모니터링 한다 (문제 없는지, 선택사항)
> Traffic shift 가 끝나면 Post Traffic Hook 을 돌릴 수 있다 (Test 용도, 선택사항)
> V1 이 사라진다
> 몇 가지 기억할 항목들이 있다
> AutoPublishAlias
>> SAM 이 새로운 코드가 배포될 때 그것을 탐지하도록 함
>> 새로운 버전 (new lambda version) 의 람다 함수를 배포한다
>> 기존 manage 하는 alias 를 새 버전으로 포인팅하도록 바꾼다
> DeploymentPreference
>> alias 포인팅을 바꾸는 변경 과정을 어떻게 할지 (배포를 어떻게 할지) 방식을 선택할 수 있다 (Canary, Linear, AllAtOnce)
>> 모두 Code Deploy 의 설정이였다
> Alarms
>> CD 가 Rollback 을 수행할 Alarm 을 정의할 수 있다
> Hooks
>> PreTraffic / PostTraffic 으로 구분할 수 있다
>> Alarm 이나 Hook 이나 모두 다른 곳에 정의한 리소스를 참조하는 !Ref 를 사용한다 (위 사진에 안나타 있는 것)
<실습>
> 새 Directory 에서 $sam init --runtime python3.7 명령어로 SAM 앱을 하나 시작함
> AWS Quick Start 로 제공하는 예시 앱으로 기동하라고 선택함
> 그리고 $sam build 를 통해 SAM 앱을 빌드한다
>> app.py 를 보면 "hello world" 를 반환하는 람다 함수를 제공해줬음
>> template.yml 을 보면, 위 app.py 에 대한 함수와, API Gateway 를 만들어주는 것을 알 수 있다
> 이 AWS 제공 예시 앱을 CD 로 배포하도록 추가하려는 것,따라서 template 을 수정한다
# template.yml 중 ..
... 람다 함수 정의
Properties:
CodeUri: hello_world/
...
Events:
HelloWorld: # Gateway 설정
Type: Api
Properties:
...
# 여기서부터 CD 연동 설정
AutoPublishAlias: live # Properties 의 하기 항목, 원하는 alias 이름
DeploymentPreference:
Type: Canary10Percent10Minutes # 배포 방식 중 하나 (10분동안 10퍼의 트래픽, 10분 뒤 100퍼로 이동)
> $sam build 를 다시 시동 (빌드 이후에 패키징 하고 배포하는거였나..? 위에선 빌드 안하지 않음?)
> 위에선 바로 package 하긴 했었음. build 는 code 경로를 build 해서 output 을 만드는 거고, 그 output 이 SAM 의 CodeUri 로 변경되는 듯ㅅ? 위에서 왜 안했는지는 모르겠음. 간단해서 안했나 ㅋㅋ ㅅㅂ
> $sam deploy --guided 를 사용하여 더 쉽게 배포함 (옵션을 ㅈㄴ 친절하게 물어봐주면서 진행됨)
>> region 입력하세요, 배포전 변경점들을 표시할까요?, SAM CLI Iam 자격 증명을 허용하나요, samconfig 에 이것들을 저장할까요 이런거
>> 패키징이랑 deploy 를 같이 해주는 듯?
>> 암튼 AWS Console 로 가보면 원한게 다 생성된 것을 알 수 있다
>> Alias 와 함께 람다 함수가 배포됨. (live 란 alias 에 내가 패키징한 버전이 deploy 됨)
> 이젠 로컬에서 다시 작업후 람다가 재배포되는 것을 살펴보자. 람다함수를 로컬에서 조금 바꾼다
> sam build 로 빌드 파일을 바꾸고, sam deploy --guided 로 똑같이 배포한다
> Code Deploy 가 관여한다.
> 람다로 이동하면 새로운 2버전이 생성되어 있고, live 라는 alias 에 대해 10% 만 버전2로 이동하도록 설정되어 있다 (traffic shifting)
> CodeDeploy 로 가면 실제로 CodeDeploy 가 생성되어 돌아가고 있는 것을 볼 수 있다 (Template에 필요한 업데이트 방식을 명세만 해줬는데, AWS 는 CD 가 필요한 걸 아는 것)
> 10분이 지나면 live 가 오직 v2 로만 포인팅 하는 것도 볼 수 있다
-----------------------------------
<395강 SAM 로컬 기능>
> SAM 으로 AWS Lambda 를 Local 에서 기동할 수 있다
> $sam local start-lambda 를 수행하면 Lambda 함수를 Local Endpoint 가 제공되어 활용할 수 있다 (emulation)
>> test 수행 가능
> $sam local invoke 명령어를 수행하면 End Point 로 띄우는게 아니라 payload 를 입력받아 1회성 호출을 진행한다
> 람다가 AWS 리소스에 API 를 호출한다면 (DD 로부터 데이터 가져오기 등), --profile 옵션을 활용해서 제대로 동작하도록 한다 (뭔가 연동이 추가적으로 필요한건 알겠는데 profile 이 뭔소린지는 잘 모르겠음)
> $sam local start-api 를 활용하면 로컬 API Gateway 가 띄워진다 (백엔드 앱서버가 띄워지나봄)
> 모든 API 들과 함수를 호스팅할 로컬 HTTP 서버를 띄운다.
>> 함수 코드 업데이트시 로컬 영역에서 자동으로 다시 로딩된다
> $sam local generate-event 를 사용해서 가짜 이벤트를 생성해볼 수 있다
>> 가령, [S3 Event] 가 발생했다고 가정해보자! 하고 Test 가 가능한것. 그럼 이 명령어의 결과물인 가짜 Event 를 $sam locak invoke 명령어에 입력값으로 넣어줘서 호출 Test 를 해볼 수 있는 것
>> S3, API Gateway, SNS, Kinesis, DD 등등 Event 모킹 가능
-----------------------------------
<396강 SAM Multiple Env : 다중 환경 >
> 개발 Stack 들을 구성하여 다양한 환경을 SU 할 수 있다 (Dev / Prod 등)
> 즉, SAM Temp 를 때로는 개발 환경에, 필요할 때는 운영 환경에 배포하는 것
> 이를 위해서는 samconfig.toml 이라는 파일을 활용해야 함
>> 약간 app-properties-{환경} 파일이랑 비슷한 느낌
# samconfig.toml 이 강의안에 나온 예시 파일
version = 0.1
[dev.deploy.parameters]
stack_name = "my-dev-stack"
s3_bucket = "XXXX-dev"
s3_prefix = "XXXX/dev"
region = "us-east-1"
capabilites = "CAPABILITY_IAM"
parameter_overrides = "Environment=Development"
[prod.deploy.parameters]
stack_name = "my-prod-stack"
s3_bucket = "XXXX-prod"
s3_prefix = "XXXX/prod"
...
[dev.sync.parameters]
watch = true
[prod.sync.parameters]
watch = false
> 하나의 toml 파일에 [] 로 여러 Stack 에 대한 Param 을 각각 정의해줄 수 있다
> 위 예시처럼 이 param 은 현재 prod stack 이니 A 값이야, dev stack 이니 B 값이야 이런식으로.
> 배포할 떄 --config dev 라는 명령어를 사용하여 옵션을 넣어줄 수 있는 것!
-----------------------------------
<퀴즈>
>> 참고로, 퀴즈에 강의에 안나왔던거 자주 나오는 듯. 그냥 배우는거다 하고 생각하고 추가적으로 알고 있어야 할 듯 하다
> 2: Transform: "AWS::Serverless-2016-10-31" 로 시작하는 템플렛은 SAM 으로 형성된 템플렛임!
> 4. Policy Template 들 확인!
> 5 (틀림) . 이게 나왔는지는 잘 모르것다..? "SAM 을 사용하여 Serverless App Pckg 들을 다른 AWS 계정들과 공유할 수 있는 AWS 비스는?"
>> 정답 : AWS SAR (Serverless Application Repository) - SAM Repo 인듯
>> 내 오답: AWS RAM (머임 ㅋㅋ)
> 6 (틀림). SAM CLI + AWS Tool Kit 를 함께 사용하면 Lambda 함수를 Local Debug, 변수 검사, Code 한 줄씩 실행 가능하다.. 고 합니다.. 이것도 안배운 것 같아요 ㅋㅋ 적어도 이 강의에선
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 27 - 유저가 누군지 알아보는 Cognito (0) | 2024.10.06 |
|---|---|
| [CDA] 섹션 26 - 클라우드 개발 키트 (CDK) (0) | 2024.10.03 |
| [CDA] 섹션 24 - AWS CICD : CodeCommit, CodePipeline, CodeBuild 및 기타 (0) | 2024.09.17 |
| [CDA] 섹션 23 - AWS 서버리스 : API Gateway (0) | 2024.09.09 |
| [CDA] 섹션 22 - AWS 서버리스 : Dynamo DB (0) | 2024.09.01 |
