SAM template 작성하기

SAM template.yaml anantomy 분석하기

아래는 SAM 구축에 필요한 template의 명세를 나타낸 것이다.

Transform: AWS::Serverless-2016-10-31 
# (required)
# SAM template으로 명시하고자 하면 꼭 AWS::Serverless-2016-10-31를 입력해주어야 한다고 한다. 
#추가적인 transform 형태는 cloudformation 가이드에서 확인한다.

Globals: 
# (optional) / type: set of globals
# 공통으로 사용되는 serverless function, api 및 간단한 table들의 속성을 명시한다. 
# AWS::Serverless::* 의 모든 리소스가 이 global 섹션에 명시된 속성으로 상속된다. 
# SAM에 특화된 영역으로 cloudformation에는 없다. 

Description:
# (optional) / type: String
# aws cloudformation 템플릿에서 확인가능한 본 스택에 대한 설명

Metadata:
# (optional) / type: template metadata
# 템플릿에 대한 추가 정보를 제공하는 객체를 명시. cloudformation 템플릿 메타 데이터 섹션과 연동된다.

Parameters:
# (optional) / type: set of parameters
# 스택을 만들거나 업데이트 할 때 런타임 중 전달할 값들을 명시. 
# 리소스로부터 파라미터나 템플릿 섹션의 outputs를 refer할 수 있다.
# sam 배포 시 커맨드로 사용가능하며 자세한 내용은 
# https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-config.html

Mappings:
# (optional) / type: set of mappings
# lookup table 처럼 조건부 변수 값을 명시하는 데 사용할 수 있는 키와 관련된 값들의 매핑들로써
# 키에 맞는 값을 리소스와 outputs 섹션에서 Fn::FindInMap으로 사용가능하다.
# cloudformation 템플릿에 직접적으로 연동된다.

Conditions:
# (optional) / type: set of conditions
# 업데이트 되거나 생성될 리소스들의 조건을 명시할 수 있는 영역. 
# production인지 테스트인지에 따라 리소스를 조건에 맞게 생성할 수 있음.
# cloudformation 템플릿에 직접적으로 연동된다.

Resources:
# (required) / type: set of resources
# 스택 리소스들을 명시하는 영역. 본 영역의 서로 다른 리소스와 outputs 섹션을 refer할 수 있다고 함.
# cloudformation 템플릿과 비슷함.

Outputs:
# (optional) / type: set of outputs
# 스택의 properties를 확인할 수 있는 값을 명시.
# 예를 들어 s3 버킷을 선언한다면 해당 이름으로 aws cli에서 확인할 수 있음.
# cloudformation 템플릿에 직접적으로 연동된다. 

다른 옵션은 중간에 필요할 때 활용할 수 있을 것 같고, 가장 중요한 Resources 영역을 한번 더 확인해보자.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resources-section-structure.html

Resources:
  Logical ID:
    Type: Resource type
    Properties:
      Set of properties

위는 하나의 resource에 대해 명시하는 것을 보여준다. logical id는 해당 리소스의 별칭을 나타내고 type은 해당 리소스의 타입을 나타낸다. logical id에 추가적으로 physical id가 i-28f9ba55와 같이 리소스 생성 시 자동으로 부여된다. physical id로 리소스를 직접 확인할 수 있다.

필요 Resource별 서비스 살펴보기

프로젝트에 필요한 리소스들은 다음과 같다.

• Amazon RDS (mysql)
• Route 53 (도메인 유지)
• Amplify (프론트 배포용)
• Amazon lambda
• Amazon S3 (lambda 배포용)
• Amazon CloudFront (검토 필요, ssr의 배포에는 필요 없을 수도)
• VPC (프론트 - 백엔드 연결 유지용)
• API Gateway (lambda api point 연결 시 사용)

하나씩 살펴보기로 한다.

API Gateway(1)

Amazon API Gateway는 규모와 관계없이 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스입니다. API 개발자는 AWS 또는 다른 웹 서비스를 비롯해 AWS 클라우드에 저장된 데이터에 액세스하는 API를 생성할 수 있습니다. API Gateway API 개발자는 자체 클라이언트 애플리케이션에서 사용할 API를 생성할 수 있습니다. 또는 타사 앱 개발자가 API를 사용하도록 제공할 수도 있습니다.

우리가 사용하는 서비스에서는 Amplify 배포 및 lambda 엔드포인트를 정의하는 데 사용할 수 있을 것으로 확인된다. cloudformation에서 지원하는 api gateway는 v1과 v2가 있어서 관련된 정보를 찾아보았다.19년 당시에 HTTP API gateway를 런칭하면서 설명하는 내용을 따르면 v1과 v2는 각각 REST와 HTTP로 구분되었다는 것을 알 수 있었다. aws에서 설명하는 rest와 http의 차이는 다음 문서에서 찾을 수 있었다.
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html 하지만, 명쾌하고 상세한 설명은 다음 글에서 확인할 수 있었다.
https://www.tinystacks.com/blog-post/api-gateway-rest-vs-http-api-what-are-the-differences/

구분하자면, http는 vpc에 의한 private 접근이 안되고, 아마존에서 지원하는 API 방화벽이(WAF) 안되며, canary 와 같은 a/b 테스트가 안되는 등 제약이 많았다. 하지만 비용이 REST 대비 71%정도 저렴하며 속도가 더 빠르다고 한다. 이것만으로도 어딘가에는 채택 사유가 될 수 있지만 다양한 경험을 하기 위한 목적의 본 프로젝트에서는 REST를 도입하기로 한다.조금 당황스러운 것은, ApiGateway 서비스를 구축할 수 있는 리소스 타입만하더라고 이렇게나 된다. '시작하기' 와 자습서 같은 문서를 참고하기엔, 구축하고자 하는 형태의 자습서가 정확히 없을 뿐더러 서로 많은 자습서들이 너무 다르다. 가장 중요한 리소스 하나를 구축하고 그에 필요한 타입을 더 찾아 도입하는 형식으로 구현하고자 한다.

https://github.com/matsev/cloudformation-api-gateway/blob/master/cloudformation.template
예제들을 찾다가 위와 같은 코드를 발견했다. 그리고 resource type을 보고 있자니, 기존 sam에서 사용하던 AWS::Serverless::Function 이 생각났다. cloudformation과 sam에서 사용하는 resource의 형태가 약간 다른 것이었다.
둘 사이의 차이점을 확인하기 위해 구글링을 하였고 아래와 같은 의견을 발견하였다.
sam은 lambda가 출시된 직후 lambda를 배포하는데에 api gateway,lambda,s3와 같은 cloudformation의 작성이 어려웠던 단점이 있었고, 그를 보안하기 위해 serverless 프레임워크가 개발되었다고 한다. sam은 그 후 aws에서 지원하는 serverless 배포 툴이다.
결론적으로 sam으로 AWS::Serverless::* 로 시작되는 리소스들은 (AWS::Serverless::Function) 내부적으로 해당 리소스를 배포하기 위한 여러가지 리소스들을 함께 cloudformation(AWS::Lambda::Function / AWS::Lambda::LayerVersion / AWS::Lambda::Permission 등)으로 설정해주게 되는 것이다.

상세한 명세는 sam template 명세서를 확인하면 될 것이고, 원하는 기능이 없는 경우는 cloudformation의 원본을 적용하는 형식으로 생성할 수 있을 듯 하다.

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-api.html
sam AWS::Serverless::Api 명세를 보면, AWS::Serverless::Function에 의해 명시된 api 리소스들이 자동으로 생성된다고 한다. AWS::Serverless::Function에서 내용을 확인하고 구현해도 괜찮을 듯 하다.

Amazon Lambda

Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스입니다. Lambda는 고가용성 컴퓨팅 인프라에서 코드를 실행하고 서버와 운영 체제 유지 관리, 용량 프로비저닝 및 자동 조정, 코드 및 보안 패치 배포, 코드 모니터링 및 로깅 등 모든 컴퓨팅 리소스 관리를 수행합니다. Lambda를 사용하면 거의 모든 유형의 애플리케이션 또는 백엔드 서비스에 대한 코드를 실행할 수 있습니다. Lambda가 지원하는 언어 중 하나로 코드를 공급하기만 하면 됩니다.

이 서비스가 sam 환경에서 어떻게 구축되는 지 확인해 보자.
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-generated-resources-function.html#sam-specification-generated-resources-function-autopublishalias
에서는 AWS::Serverless::Function의 옵션에 따라 어떤 리소스가 배포되고 구성되는지에 대해 설명하고 있다.

1. AutoPublishAlias 속성 명시할 시, 다음 리소스 생성

   • AWS::Lambda::Alias -> LogicalId: <function‑LogicalId>Alias<alias‑name>
   • AWS::Lambda::Version -> LogicalId: <function‑LogicalId>Version<sha>

2. Role 속성 명시하지 않을 시, 다음 리소스 생성

   • AWS::IAM::Role -> LogicalId: <function‑LogicalId>Role

3. DeploymentPreference 속성 명시할 시
   DeploymentPreference 속성에 Role 속성이 없으면 AWS::IAM::Role 추가 생성

   • AWS::CodeDeploy::Application -> LogicalId: ServerlessDeploymentApplication
   • AWS::CodeDeploy::DeploymentGroup -> LogicalId: <function‑LogicalId>DeploymentGroup

4. Event 속성 명세와 동작
   AWS::Serverless::Function의 Event 속성이~

   1. Api로 설정되었지만 RestApiId가 명시되지 않았다면,
      • AWS::ApiGateway::RestApi -> LogicalId: ServerlessRestApi
   2. HttpApi로 설정되었지만 ApiId가 명시되지 않았다면,
      • AWS::ApiGatewayV2::Api -> LogicalId: ServerlessHttpApi
   3. Event bridge 혹은 Event bus 타입으로 설정되었을 때
      • AWS::Events::Rule -> LogicalId: <function‑LogicalId><event‑LogicalId>
      • This applies to the following types: EventBridgeRule, Schedule, and CloudWatchEvents.

5. OnSuccess 속성이 명시되었을 시

   AWS::Serverless:Function
   	EventInvokeConfig:
       	DestinationConfig:
           	OnSuccess: #가 명시 되었고 destination type이 sns지만
               		   #destination ARN이 명시되지 않았을 때

   • AWS::Lambda::EventInvokeConfig -> LogicalId: <function‑LogicalId>EventInvokeConfig
   • AWS::SNS::Topic -> LogicalId: <function‑LogicalId>OnSuccessTopic (or <function‑LogicalId>OnFailureTopic)

6. SQS 에 대한 설정도 위와 비슷한 구조로 작성됨.

AWS::Serverless::Function

다음은 AWS::Serverless::Function의 property를 모두 나타낸 것이다.

Type: AWS::Serverless::Function
Properties:
  Architectures: List	
  AssumeRolePolicyDocument: JSON
  AutoPublishAlias: String
  AutoPublishCodeSha256: String
  CodeSigningConfigArn: String
  CodeUri: String | FunctionCode
  DeadLetterQueue: Map | DeadLetterQueue
  DeploymentPreference: DeploymentPreference
  Description: String
  Environment: Environment
  EphemeralStorage: EphemeralStorage
  EventInvokeConfig: EventInvokeConfiguration
  Events: EventSource
  FileSystemConfigs: List
  FunctionName: String
  FunctionUrlConfig: FunctionUrlConfig
  Handler: String
  ImageConfig: ImageConfig
  ImageUri: String
  InlineCode: String
  KmsKeyArn: String
  Layers: List
  MemorySize: Integer
  PackageType: String
  PermissionsBoundary: String	#함수를 실행시킬 수 있는 Role을 정할 수 있다
  Policies: String | List | Map
  ProvisionedConcurrencyConfig: ProvisionedConcurrencyConfig
  ReservedConcurrentExecutions: Integer
  Role: String
  Runtime: String
  Tags: Map
  Timeout: Integer
  Tracing: String
  VersionDescription: String
  VpcConfig: VpcConfig

우리 서비스에서는 각 lambda 함수의 vpc 설정과 layer, api설정이 추가적으로 필요하다.
그리고 필수적으로 (물론 option 자체는 conditional이지만) CodeUri, Handler 등을 명시해주도록 한다.

AWS::Serverless::Function 필요 template

Type: AWS::Serverless::Function
Properties:
  CodeUri: String | FunctionCode
  Events: EventSource
  	ApiEvent:	#logical한 이름으로 명시해주기
      Type: Api
      Properties:
        Auth: ApiFunctionAuth	# 이 Api+Path+Method에 대한 auth 설정. docs에서 제시한 상황아니면 default 사용이 좋을듯.
        Method: String	# 함수를 호출할 HTTP 메서드
        Path: String	# '/' 로 시작하는 함수를 불러올 Uri 경로
        RequestModel: RequestModel	# 함수에 대한 요청 모델
          Model: String	# AWS::Serverless::Api 모델 속성에 정의된 모델 이름
          Required: Boolean
          ValidateBody: Boolean
          ValidateParameters: Boolean
        RequestParameters: String | RequestParameter	# 이 api에 대한 요청 파라미터. method.request로 시작되어야 하며 header,querystring,path 중에 하나이다.
        RestApiId: String	# 이 api의 패스 동작을 포함한 RestApi 리소스의 식별자.
        
  	S3Event:	#logical한 이름으로 명시해주기
      Bucket: String	# S3 버킷 이름. 반드시 이 템플릿에 이 버킷이 존재해야함.
      Events: String | List	# lambda를 invoke할 수 있는 S3 버킷 이벤트 (https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/NotificationHowTo.html#supported-notification-event-types)
      Filter: NotificationFilter	# 어떤 S3 객체가 함수를 invoke할 지에 대한 필터링 규칙
  FunctionName: String	# 함수의 이름. 명시하지 않으면 유니크한 이름이 생성됨.
  Handler: String	#	실행 시 불러지는 코드 내의 함수. PackageType이 Zip 타입일때만 required임.
  Layers: List	# 함수가 사용할 LayerVersion ARN들의 리스트..
  VpcConfig: VpcConfig	# 이 함수가 vpc 내의 private resource에 접근하게 하기 위한 설정
  	SecurityGroupIds: 
      - String	# VPC 보안 그룹의 ID들 (list)
    SubnetIds: 
      - String	# VPC 서브넷 ID들 (list)

그래도 다행히, 이 정도를 살펴보니 lambda 함수에 대한 설정은 확실히 알 수 있었다. 다시 API gateway로 돌아가서, lambda 함수에서 명시할 수 있는 AWS::Serverless::Api를 살펴보기로 한다.

API Gateway(2)

AWS::Serverless::Api

아래는 AWS::Serverless::Api의 템플릿이다.

Type: AWS::Serverless::Api
Properties:
  AccessLogSetting: AccessLogSetting	
  ApiKeySourceType: String	
  Auth: ApiAuth
  BinaryMediaTypes: List
  CacheClusterEnabled: Boolean
  CacheClusterSize: String
  CanarySetting: CanarySetting
  Cors: String | CorsConfiguration
  DefinitionBody: JSON
  DefinitionUri: String | ApiDefinition
  Description: String
  DisableExecuteApiEndpoint: Boolean
  Domain: DomainConfiguration
  EndpointConfiguration: EndpointConfiguration
  GatewayResponses: Map
  MethodSettings: MethodSettings
  MinimumCompressionSize: Integer
  Mode: String
  Models: Map
  Name: String
  OpenApiVersion: String
  StageName: String
  Tags: Map
  TracingEnabled: Boolean
  Variables: Map

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-api.html를 보면, 다양한 경우에서 세팅할 수 있는 AWS::Serverless::Api의 예를 보여준다. 단적으로는

ApiGatewayApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod

정도만 명시해주고 AWS::Serverless::Function에서 Properties:Events:{logicalEventName}:Properties:RestApiId:'Ref: {ApiGatewayApi}' 처럼 서버리스 api의 이름을 명시하면 사용할 수 있다고 한다!
위 링크에 다양한 예제가 있으니 구축 전 다시 확인하기로 한다.

Amplify 는 나중에

Amazon RDS

이전에 겪었던 끔찍한 기억(serverless가 무턱대고 좋을 줄 알고 serverless aurora rds를 열었다가 이틀만에 3만원을 내게 된)을 토대로, DBInstace를 만들기로 한다.
번외로 AWS::Serverless::SimpleTable resource를 사용하면 primary key 하나의 DynamoDB table을 생성할 수 있다. 관련 내용은 https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-simpletable.html
업데이트 중 DB 인스턴스가 삭제되거나 교체되면 cloudformation은 모든 스냅샷을 지운다고 한다... 하지만 수동 DB 스냅샷은 남게 된다. 교체가 필요한 업데이트 시 DB 인스턴스를 교체중에 보존할 수 있는 스택 정책을 적용할 수 있다고 한다. 꼭 명시하도록 하자.

그리고, stack 업데이트를 하기전에 꼭 db의 스냅샷을 따라고 한다. 그렇지 않으면 db instance가 교체되며 데이터를 잃을 수 있다고 한다... 다음 과정을 따라야 한다.
1. db 인스턴스를 사용하는 모든 application 비활성화
2. db 인스턴스 스냅샷 생성.
3. db 스냅샷을 사용하여 인스턴스를 복구하고자 하면, updated 템플릿을 DBSnapshotIdentifier 속성을 추가해준다. 복구 후에는 똑같은 DBSnapshotIdentifier 속성을 db인스턴스의 추후 업데이트에 명시해주어야 한다. 업데이트를 위해 이 속성을 명시하면 db 인스턴스는 db 스냅샷으로부터 복구되지 않으며, database의 데이터가 변하지 않는다. 명시하지 않으면 빈 db 인스턴스가 생성되고 원 db 인스턴스는 삭제된다... 이전 스냅샷과 다른 식별자를 명시하면 새 db 인스턴스가 명시된 식별자로 생성되고 이전 것은 삭제된다.
4. 스택을 업데이트 한다 ^ㅇ^

AWS에서 중요하다고 하는 내용은 다 확인했으니 template를 알아보자.

Type: AWS::RDS::DBInstance
Properties: 
  AllocatedStorage: String
  AllowMajorVersionUpgrade: Boolean
  AssociatedRoles: 
    - DBInstanceRole
  AutoMinorVersionUpgrade: Boolean
  AvailabilityZone: String
  BackupRetentionPeriod: Integer
  CACertificateIdentifier: String
  CharacterSetName: String
  CopyTagsToSnapshot: Boolean
  DBClusterIdentifier: String
  DBInstanceClass: String
  DBInstanceIdentifier: String
  DBName: String
  DBParameterGroupName: String
  DBSecurityGroups: 
    - String
  DBSnapshotIdentifier: String
  DBSubnetGroupName: String
  DeleteAutomatedBackups: Boolean
  DeletionProtection: Boolean
  Domain: String
  DomainIAMRoleName: String
  EnableCloudwatchLogsExports: 
    - String
  EnableIAMDatabaseAuthentication: Boolean
  EnablePerformanceInsights: Boolean
  Engine: String
  EngineVersion: String
  Iops: Integer
  KmsKeyId: String
  LicenseModel: String
  MasterUsername: String
  MasterUserPassword: String
  MaxAllocatedStorage: Integer
  MonitoringInterval: Integer
  MonitoringRoleArn: String
  MultiAZ: Boolean
  OptionGroupName: String
  PerformanceInsightsKMSKeyId: String
  PerformanceInsightsRetentionPeriod: Integer
  Port: String
  PreferredBackupWindow: String
  PreferredMaintenanceWindow: String
  ProcessorFeatures: 
    - ProcessorFeature
  PromotionTier: Integer
  PubliclyAccessible: Boolean
  SourceDBInstanceIdentifier: String
  SourceRegion: String
  StorageEncrypted: Boolean
  StorageType: String
  Tags: 
    - Tag
  Timezone: String
  UseDefaultProcessorFeatures: Boolean
  VPCSecurityGroups: 
    - String

명시할 수 있는 속성이 굉장히 많은 것을 알 수 있다. 이런 경우, AWS에서 제공하는 예시를 참고하거나 그것도 없을 경우 Required + Conditional 옵션을 확인해서 살펴만봐도 접근하는 데는 충분하다고 생각한다. RDS는 템플릿 예시를 포함하고 있으며 예시는 다음과 같다.
https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/quickref-rds.html (또 다른 예시를 포함)

• 더 나은 모니터링이 활성화된 DB 인스턴스 생성
• cross-region의 암호화된 읽기 복제본 생성
• Amazon RDS DB 인스턴스 리소스
• Amazon RDS Oracle Database DB 인스턴스 리소스
• CIDR 범위에 대한 Amazon RDS DBSecurityGroup 리소스
• Amazon EC2 보안 그룹을 포함하는 Amazon RDS DBSecurityGroup
• 여러 VPC 보안 그룹
• VPC 보안 그룹 내 Amazon RDS 데이터베이스 인스턴스

required 속성 명시 중 필요하거나 조건부인 내용들은 아래와 같다.

• DBInstanceClass -> Required:Yes
• AllocatedStorage -> Required:Conditional / 초기화 시 db 인스턴스에 할당할 스토리지 용량 (근데 왜 string인가)
• Engine -> Required:Conditional / 데이터베이스 엔진명 e.g) oracle-se2-cdb
• MasterUsername -> Required:Conditional / 마스터 유저 이름.
• MasterUserPassword -> Required:Conditional / 마스터 유저 패스워드. 특수문자 몇개가 안됨.

나는 가장 기본적인 Amazon RDS DB 인스턴스 리소스 템플릿 예제를 참고하여 만들기로 한다.

MyDB:	# logical한 이름
  Type: AWS::RDS::DBInstance
  Properties:
    DBSecurityGroups:	
    	# DB 인스턴스에 접근하기 위한 DB 보안그룹들. 템플릿에서 생성 혹은 기존 보안그룹을 사용 가능.
    	# DBSecurityGroups를 설정하면, VPCSecurityGroups을 설정하지 않아야 한다. 반대도 마찬가지.
        # 음.. order regions의 backwards compatibility를 위해서 세팅되고 이제는 이 방법으로 보안 정보를 제공하지 않는 걸 추천한다고 한다. 대신 vpc보안 그룹을 사용하라고.. vpc를 사용하는 것이 여러모로 좋을 듯 하다.
    - Ref: MyDbSecurityByEC2SecurityGroup
    - Ref: MyDbSecurityByCIDRIPGroup
    AllocatedStorage: '5'
    DBInstanceClass: db.t2.small
    Engine: MySQL
    MasterUsername: MyName
    MasterUserPassword: MyPassword
  DeletionPolicy: Snapshot	# Delete/Retain/Snapshot 중 선택

실제 템플릿을 만들 때 더 확인하면 될 듯 하다.

Amazon S3

위 AWS::Serverless::Function의 event에서 명시했던 것을 다시 살펴본다.

S3Event:
  Bucket:	# 똑같은 이름으로 같은 템플릿에 존재해야 함
  	Ref: ImagesBucket
  Events: s3:ObjectCreated:* # 함수를 호출할 S3 버킷 이벤트. 예를 들면.. 파일 저장과 같은 로직일 수도.
  Filter: 	# NotificationFilter 타입.
    S3Key:
    	Rules:
          Name: prefix      # or "suffix"
          Value: value      # The value to search for in the S3 object key names

일단, S3 자체를 SAM으로 관리하고자 하기 때문에, 버킷을 생성하는 것은 꼭 포함되어야 할 것이다. template의 문법은 아래와 같다.
AWS::Serverless::에서 제공하는 S3 객체 리소스 템플릿은 존재하지 않았기에 cloudformation의 템플릿 내용을 알아본다.

Type: AWS::S3::Bucket
Properties: 
  AccelerateConfiguration: 
    AccelerateConfiguration
  AccessControl: String
  AnalyticsConfigurations: 
    - AnalyticsConfiguration
  BucketEncryption: 
    BucketEncryption
  BucketName: String
  CorsConfiguration: 
    CorsConfiguration
  IntelligentTieringConfigurations: 
    - IntelligentTieringConfiguration
  InventoryConfigurations: 
    - InventoryConfiguration
  LifecycleConfiguration: 
    LifecycleConfiguration
  LoggingConfiguration: 
    LoggingConfiguration
  MetricsConfigurations: 
    - MetricsConfiguration
  NotificationConfiguration: 
    NotificationConfiguration
  ObjectLockConfiguration: 
    ObjectLockConfiguration
  ObjectLockEnabled: Boolean
  OwnershipControls: 
    OwnershipControls
  PublicAccessBlockConfiguration: 
    PublicAccessBlockConfiguration
  ReplicationConfiguration: 
    ReplicationConfiguration
  Tags: 
    - Tag
  VersioningConfiguration: 
    VersioningConfiguration
  WebsiteConfiguration: 
    WebsiteConfiguration

이번에도 마찬가지로 예시들을 확인해 보았다. https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html 의 아래쪽에 상황별 template이 있으니 확인하고 적용하고자 하는 시나리오에 맞는 템플릿을 적절히 참고한다.

• Create an S3 bucket
  : 기초적인 S3 버킷 생성
• Associate a replication configuration IAM role with an S3 bucket
• Configure a static website with a routing rule
  : Properties:WebsiteConfiguration의 내용에 정적 파일에 대한 라우팅 설정을 명시할 수 있음. Fn::GetAtt(yaml에서 !GetAtt)를 사용하여 output을 제공할 수 있음.
• Enable cross-origin resource sharing
  : Properties:CorsConfiguration을 명시하여 cors 세팅 가능. 요청을 생성하는 단계에서 사용되는 듯 함.
• Manage the lifecycle for S3 objects
  : 생성되는 객체에 prefix를 붙여주면 Glacier에 1일 뒤 옮겨져서 1년 뒤 삭제됨
• Log access requests for a specific S3 bucket
  : 일반 s3를 로깅하는 s3를 만드는 예제.
• Receive S3 bucket notifications to an SNS topic
  : S3에서 복제본을 잃었을 때 설정된 SNS로 알림을 주는 예제
• Enable versioning and replicate objects
  : replication prefix를 명시하여 설정된 destination 버킷에 복제된 객체를 저장
• Specify analytics and inventory configurations for an S3 bucket
  : S3 버킷의 분석 및 목록에 대한 결과를 명시한다.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-s3.html

• Creating an Amazon S3 bucket for website hosting and with a DeletionPolicy
• Creating a static website using a custom domain

S3의 템플릿 예제는 상당히 구체적인 내용이 많았다. 위 목록과 같이 기본적인 s3 구축부터 cors 설정, 정적 웹사이트 라우팅 규칙 설정 등 유용하게 참고할 수 있는 항목들이 많았다. 이것 또한 구축을 통해 적용할 수 있는 옵션에 대해 조금 더 면밀히 분석하는 것이 좋을 듯 하다.

Route 53

SAM의 reference를 검색한 결과 AWS::Serverless::Api의 Domain:Route53을 설정하면 되는 듯 했다.
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-api-route53configuration.html

  DistributionDomainName: String	# default로 api gateway 분산을 사용하지만 명시해준다면 custom 할 수 있음.
  EvaluateTargetHealth: Boolean	# true일 시 참조된 LB와 같은 aws 리소스들의 health를 상속(?? health에 대해 더 알아봐야 함) 
  HostedZoneId: String	# zoneName 혹은 zoneId 중 하나만 명시해야함. AWS::Route53::RecordSetGroup RecordSet 에서 내용 참고
  HostedZoneName: String	# https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-route53-recordset-1.html#cfn-route53-recordset-hostedzoneid
  IpV6: Boolean

각 properties의 설명에서는 값들이 명시 될 때 어떤 cloudformation 서비스와 연결되는 지가 잘 명시되어 있었다.

VPC

vpc는 api 템플릿에서 확인했던 것과 같이, 자동으로 생성되는 설정을 따르기로 한다.