Skip to content
SST
Blog Docs Console Examples
22K

Migrate From v2

SST v2 앱을 v3로 마이그레이션하기

v2에서 v3로 마이그레이션

이 가이드는 여러분의 SST v2 앱을 v3로 마이그레이션하는 데 도움을 줍니다. 아래에서 v2와 v3의 주요 차이점을 살펴보겠습니다. 빠르게 소개를 보려면 SST란 무엇인가와 워크플로우 문서를 읽어보는 것을 추천합니다.

그런 다음 여러분이 사용할 수 있는 마이그레이션 계획을 살펴보겠습니다. 이 계획의 세부 사항은 팀마다 리소스와 다운타임 민감도에 따라 다를 수 있습니다.

도움 받기

SST v3는 몇 달 동안 운영되었으며, Discord에 상당히 큰 커뮤니티가 형성되어 있습니다. 마이그레이션을 원하는 분들을 위한 채널을 만들었습니다.

Discord의 #migrate-from-v2 채널에 참여하세요.

지원되지 않는 기능

v3의 목표는 v2의 대부분 기능을 지원하는 것이지만, 아직 지원되지 않는 몇 가지 기능이 있습니다. 또한 현재 베타 버전으로 제공 중이며 가까운 시일 내에 출시될 예정인 기능들도 있습니다.

기능GitHub 이슈
Auth베타 버전
Script#811
EventBus#67
RDS MySQL#812
Function 비 Node.js 런타임Python, Container, Custom

이 기능들이 여러분에게 중요한 문제라면, 링크된 GitHub 이슈를 통해 알려주세요. 이를 통해 우선순위를 정하는 데 도움이 됩니다.

주요 변경 사항

SST v2에서 v3로 넘어오는 경우, v2와 v3 사이의 주요 차이점부터 살펴보는 것이 좋습니다. 이는 마이그레이션 과정에서 필요한 변경 사항을 이해하는 데 도움이 됩니다.

CloudFormation 없음

가장 먼저 눈에 띄는 점은 SST v3가 CloudFormation과 CDK에서 벗어났다는 것입니다. 이 결정을 내린 이유에 대해 자세히 설명한 글을 참고하세요.

CloudFormation이 없다는 것은 몇 가지 의미를 가집니다:

  1. 스택이 없습니다. 모든 리소스는 sst.config.ts 파일 내의 동일한 함수를 통해 정의됩니다.
  2. 컨스트럭트 또는 컴포넌트의 출력이 다릅니다. 이전에는 배포 시 토큰으로 대체되었지만, 이제는 **Outputs**라는 것으로 대체됩니다.
  3. 앱의 상태는 로컬에 저장되고 S3에 백업됩니다. State에 대해 더 알아보세요.

CDK 없음

CDK에서 벗어나면 다음과 같은 의미가 있습니다:

  1. SST에서 지원하지 않는 기능이 있을 때 CDK 구성을 사용할 수 없습니다. 대신 Terraform 기반의 AWS 프로바이더가 있습니다. 또한 150개 이상의 다른 프로바이더를 통해 어떤 클라우드에서도 구축할 수 있습니다. 디렉토리를 확인해 보세요.

    v2 앱에서 고수준 CDK 구성을 많이 사용하고 있다면, v3로 마이그레이션하는 것이 매우 어려울 수 있습니다. Pulumi/Terraform 생태계는 상당히 완전하지만 주로 저수준 리소스로 구성되어 있습니다. CDK 구성에 대한 대체재가 없을 수 있습니다.

  2. 구성 또는 _컴포넌트_가 더 이상 CDK 기반으로 구축되지 않기 때문에 cdk 속성이 없습니다. 대신, 컴포넌트가 기본 리소스에 전달하는 속성을 수정할 수 있는 transform 속성이 있습니다. transform 속성에 대해 더 알아보세요.

sst.config.ts

sst.config.ts는 v3에서도 비슷하지만 몇 가지 변경 사항이 있습니다. 일반적인 구조를 비교해 보겠습니다. 이에 대한 자세한 내용은 아래 섹션에서 다룹니다.

sst.config.ts
export default $config({
  // 앱 설정
  app(input) {
    return {
      name: "my-sst-app",
      home: "aws"
    };
  },
  // 앱 리소스
  async run() { }
});

새로운 sst.config.ts에 대해 더 알아보세요.

sst dev

sst dev CLI가 완전히 재구성되었습니다. 이제 앱을 배포하고 프론트엔드를 함께 실행하는 _멀티플렉서_를 실행합니다. 따라서 다음 작업이 필요 없습니다:

  • 프론트엔드를 별도로 시작할 필요 없음
  • 프론트엔드 dev 스크립트를 sst bind로 감쌀 필요 없음

sst dev에 대해 더 알아보세요.

sst build

sst build CLI는 존재하지 않습니다. 대신 sst diff를 실행하여 실제 배포 없이 어떤 변경 사항이 배포될지 확인할 수 있습니다.

sst diff에 대해 더 알아보세요.

리소스 바인딩

리소스 바인딩은 이제 리소스 링크(Resource linking)로 불리며, bind prop은 link로 이름이 변경되었습니다. Node.js 클라이언트 또는 _JS SDK_가 재작업되어 모든 링크된 리소스가 이제 Resource 객체를 통해 사용 가능합니다. 이에 대해 아래에서 자세히 살펴보겠습니다.

클라이언트 핸들러와 훅은 아직 지원되지 않습니다.

리소스 링크에 대해 더 알아보세요.

Secrets

Secrets는 SSM에 저장되지 않습니다. 대신 암호화되어 상태 파일에 저장됩니다. 이는 SSM에 저장된 패스프레이즈를 사용해 암호화됩니다.

함수에서 Secrets를 로드할 때 더 이상 최상위 수준의 await가 필요하지 않습니다.

마이그레이션 계획

현재 프로덕션 환경에 배포된 v2 앱이 git 저장소에 있다고 가정해 보겠습니다. 마이그레이션을 진행하는 방법을 설명드리겠습니다.

  1. 아래 단계를 따라 앱을 비프로덕션 스테이지로 마이그레이션합니다. 리소스를 임포트할 필요 없이 새로 생성하면 됩니다.
  2. v3 앱의 비프로덕션 버전을 테스트합니다.
  3. 프로덕션 스테이지에서는 아래 단계를 따라 임포트, 도메인, 구독자 변경 작업을 진행합니다.
  4. v3 앱의 프로덕션 버전이 실행되면 v2 프로덕션 리소스 일부를 정리합니다.

여기서 핵심 아이디어는 v2 앱이 기본 리소스의 제어권을 v3 버전의 앱에 넘겨주는 것입니다.

설정

  1. 먼저 v2 앱에서 프로덕션 단계에 대해 제거 정책을 retain으로 설정합니다. 이렇게 하면 리소스가 실수로 삭제되지 않습니다.

    app.setDefaultRemovalPolicy("retain");

  2. 리포지토리에 새로운 브랜치를 만들어서 변경 사항을 준비합니다.

  3. v3 앱의 프로덕션 버전에서는 다른 스테이지 이름을 선택합니다. 예를 들어 v2에서 프로덕션 스테이지 이름이 production이라면, v3 앱에서는 prod, main, live 등을 사용할 수 있습니다. 반대로 해도 됩니다. 이 작업은 필수는 아니지만, 실수로 잘못된 리소스를 변경하지 않도록 권장합니다.

Init v3

이제 프로젝트 루트에 새로운 v3 앱을 설정해 보겠습니다.

  1. SST를 v3로 업데이트하세요. 또는 package.json에서 수동으로 버전을 설정하세요. 레포지토리의 모든 패키지에서 이 작업을 수행해야 합니다.

    npm update sst

    v3가 설치되었는지 확인하세요.

    npx sst version

  2. v2 설정 파일을 백업하세요.

    mv sst.config.ts sst.config.ts.bk

  3. v3 앱을 초기화하세요.

    npx sst init

  4. 제거 정책을 retain으로 설정하세요. v2의 setDefaultRemovalPolicy와 유사하게, v3에서는 sst.config.ts에서 제거 정책을 설정할 수 있습니다.

    sst.config.ts
    app(input) {
      return {
        name: "my-sst-app",
        removal: input?.stage === "production" ? "retain" : "remove"
      };
    }

    기본적으로 v3는 production 스테이지에 대해 제거 정책을 retain으로, 다른 스테이지에 대해서는 remove로 설정합니다.

  5. 빈 앱을 배포하여 앱이 올바르게 설정되었는지 확인하세요.

    npx sst deploy

  6. 프론트엔드의 개발 스크립트를 업데이트하세요. package.json의 dev 스크립트에서 sst bind를 제거하세요. 예를 들어, Next.js 앱의 경우 다음과 같습니다.

    package.json
    "dev": "sst bind next dev",
    "dev": "next dev",

  7. package.json에서 CDK 관련 패키지를 제거하세요.

스택 마이그레이션

구조를 변경하기 전에, 여러분의 sst.config.ts 파일에 스택 코드가 있을 수 있습니다.

아래 목록을 확인하고 해당되는 변경 사항을 적용하세요.

구조 변경

여러분은 더 이상 구성을 임포트할 필요가 없고 스택도 없기 때문에, 구성의 구조를 변경해야 합니다.

예를 들어, 모노레포 노트 앱에서 다음과 같은 변경을 했습니다.

sst.config.ts
export default $config({
  // ...


  async run() {
    await import("./infra/api");
    await import("./infra/storage");
    await import("./infra/frontend");
    const auth = await import("./infra/auth");


    return {
      UserPool: auth.userPool.id,
      Region: aws.getRegionOutput().name,
      IdentityPool: auth.identityPool.id,
      UserPoolClient: auth.userPoolClient.id,
    };
  }
}

v3에서는 인프라 파일을 infra/ 디렉토리에 저장합니다. 데모 노트 앱을 참고하여 이 구조를 확인할 수 있습니다.

런타임 마이그레이션

런타임 코드, 함수, 프론트엔드의 경우 변경 사항이 거의 없습니다. 클라이언트 또는 _JS SDK_가 재구성되었습니다.

이 변경 사항은 지금 적용하거나 각 구성을 마이그레이션할 때 적용할 수 있습니다. 아래 단계를 확인해 보세요.

Constructs 마이그레이션

v2의 constructs는 v3에서 _컴포넌트_로 대응됩니다. Constructs는 크게 다음과 같은 3가지 범주로 나뉩니다:

  1. 일시적(Transient) — Function, Topic, Queue와 같이 데이터를 포함하지 않는 constructs
  2. 데이터(Data) — RDS, Table, Bucket과 같이 애플리케이션 데이터를 포함하는 constructs
  3. 커스텀 도메인(Custom domains) — Api, StaticSite, NextjsSite와 같이 커스텀 도메인이 설정된 constructs
  4. 구독자(Subscribers) — Bucket, Queue, Table 구독자와 같이 다른 constructs를 구독하는 constructs

이제 각 타입을 살펴보고 v2 constructs를 v3 컴포넌트로 복사해 보겠습니다.

임시 구조물(Transient constructs)

Function, Cron, Topic, Queue, KinesisStream과 같은 구조물은 데이터를 포함하지 않습니다. 이들은 v3 앱에서 다시 생성할 수 있습니다.

아래 참조를 사용하여 간단히 복사해 오면 됩니다.

데이터 구조

RDS, Table, Bucket, Cognito와 같은 구조들은 데이터를 포함합니다. 데이터를 유지할 필요가 없다면, 위에서 했던 것처럼 재생성할 수 있습니다. 이는 비프로덕션 단계에서 흔히 사용되는 방법입니다.

하지만 프로덕션 단계에서는 AWS 리소스를 v3 앱으로 가져와야 합니다.

예를 들어, app-prod-MyBucket이라는 이름의 S3 버킷을 가져오는 단계는 다음과 같습니다.

  1. 리소스 가져오기

    버킷이 SST v2에서 정의되어 있고, 버킷 이름이 app-prod-MyBucket이라고 가정해 봅시다.

    v2
    const bucket = new Bucket(stack, "MyBucket");

    import와 transform 속성을 사용하여 가져올 수 있습니다.

    v3
    const bucket = new sst.aws.Bucket("MyBucket", {
      transform: {
        bucket: (args, opts) => {
          args.bucket = "app-prod-MyBucket";
          opts.import = "app-prod-MyBucket";
        },
        cors: (args, opts) => {
          opts.import = "app-prod-MyBucket";
        },
        policy: (args, opts) => {
          opts.import = "app-prod-MyBucket";
        },
        publicAccessBlock: (args, opts) => {
          opts.import = "app-prod-MyBucket";
        }
      }
    });

    가져오기는 이전에 생성된 리소스를 SST 앱으로 불러와서 앞으로 관리할 수 있도록 하는 과정입니다. 리소스 가져오기에 대해 더 알아보세요.

  2. 배포

    코드의 리소스 설정이 AWS 계정의 버킷 설정과 정확히 일치하지 않으면 오류가 발생합니다.

    이는 기존 리소스를 변경하지 않기 위한 좋은 방법입니다.

  3. 속성 업데이트

    오류 메시지에서 변경해야 할 속성을 확인할 수 있습니다. 해당 속성을 transform 블록에 추가하세요.

    그리고 다시 배포하세요.

버킷을 가져온 후에도 v2 앱은 여전히 리소스를 변경할 수 있습니다. v2 앱을 제거하거나 v2 앱에서 버킷을 제거하려고 하면 S3 버킷이 삭제됩니다. 이를 방지하려면 v2 앱에서 제거 정책을 retain으로 설정해야 합니다.

커스텀 도메인이 있는 Constructs

다음과 같은 Constructs는 커스텀 도메인을 가질 수 있습니다.

  • 프론트엔드: StaticSite, NextjsSite, SvelteKitSite, RemixSite, AstroSite, SolidStartSite
  • API: Api, ApiGatewayv1, AppSyncApi, WebSocketApi
  • Service

비프로덕션 단계에서는 단순히 재생성하면 됩니다.

하지만 커스텀 도메인이 있는 경우, 다운타임을 방지하기 위해 단계적으로 배포해야 합니다.

  1. 먼저, 커스텀 도메인 없이 v3에서 리소스를 생성합니다. 예를 들어 Nextjs의 경우:

    sst.config.ts
    new sst.aws.Nextjs("MySite");

  2. v3 앱을 배포합니다.

  3. 준비가 되면 override 속성을 사용하여 도메인을 전환합니다.

    sst.config.ts
    new sst.aws.Nextjs("MySite", {
      domain: {
       name: "domain.com",
       dns: sst.aws.dns({ override: true })
      }
    });

    이렇게 하면 DNS 레코드가 새로운 Next.js 앱을 가리키도록 업데이트됩니다.

그리고 다시 배포합니다.

DNS 레코드가 재정의된 후에도 v2 앱은 여전히 이를 변경할 수 있습니다. v2 앱을 제거하려고 하면 레코드가 제거될 수 있습니다. 이를 방지하려면 v2 앱의 제거 정책을 retain으로 설정해야 합니다.

구독자 구조

많은 구조체에는 비동기 처리를 돕는 구독자가 있습니다. 예를 들어, Queue에는 소비자가 있고, Bucket에는 알림이 있으며, Table 구조체에는 스트림이 있습니다. 여러분은 v3 앱에서 이러한 구조체를 다시 만들 수 있습니다.

하지만 프로덕션 단계에서 가져온 리소스에 대한 구독자를 다시 만드는 것은 간단하지 않습니다:

  • 가져온 Queue에 대한 소비자를 다시 만들면 실패합니다. Queue는 하나의 소비자만 가질 수 있기 때문입니다.
  • 가져온 DynamoDB Table에 대한 소비자를 다시 만들면 이벤트가 v2와 v3 앱에서 모두 처리되는 이중 처리 문제가 발생합니다.

이 문제를 해결하기 위해 다음과 같은 방법을 추천합니다.

  1. 구독자 없이 v3 앱을 배포합니다. .subscribe() 호출을 주석 처리하거나, 구독자 함수에서 일찍 반환하는 방식으로 할 수 있습니다.
  2. 전환할 준비가 되면, v2 앱에서 구독자를 제거하고 배포합니다.
  3. v3 앱에 구독자를 추가하고 배포합니다.

이렇게 하면 동일한 구독자가 하나의 리소스에 한 번만 연결되도록 보장할 수 있습니다.

정리 작업

이제 여러분의 v3 앱이 프로덕션 트래픽을 처리하고 있습니다. 선택적으로 v2 앱에서 몇 가지를 정리할 수 있습니다.

v3에서 재생성된 리소스 중 가져오지 않은 것들은 이제 제거할 수 있습니다. 하지만 v2 앱이 retain으로 설정되어 있기 때문에 이 작업은 수동으로 진행해야 합니다.

CloudFormation 콘솔로 이동하여 v2 앱 스택의 리소스 목록을 확인하고 수동으로 제거할 수 있습니다.

마지막으로 v2 앱에 대해 sst remove를 실행하면 CloudFormation 스택도 함께 제거됩니다.

CI/CD

여러분은 아마도 앱에 _git push to deploy_나 CI/CD를 설정해 놓았을 겁니다. GitHub Actions를 사용 중이라면 v2와 v3 사이에 큰 차이는 없을 것입니다.

Seed를 사용해 v2 앱을 배포 중이라면, SST Console에서 Autodeploy를 사용하도록 마이그레이션해야 합니다. 현재 Seed에서 v3를 지원할 계획이 없습니다.

Console을 통해 Autodeploy를 사용하는 주요 이유는 다음과 같습니다:

  • 빌드가 여러분의 AWS 계정에서 실행됩니다.
  • sst.config.ts를 통해 워크플로우를 구성할 수 있습니다.
  • 배포의 일부로 어떤 리소스가 업데이트되었는지 확인할 수 있습니다.

Console에서 Autodeploy를 활성화하려면 다음 단계를 따르세요:

  1. Console에 새 계정 생성 — console.sst.dev
  2. AWS 계정 연결
  3. 리포지토리 연결
  4. 환경 구성
  5. 그리고 git push

Console과 Autodeploy에 대해 더 알아보세요.

sst.config.ts

아래는 일반적으로 여러분의 sst.config.ts에 적용된 몇 가지 변경 사항입니다.

import 없음

모든 구성 요소나 _컴포넌트_는 전역 컨텍스트에서 사용할 수 있습니다. 따라서 아무것도 import할 필요가 없습니다. 여러분의 앱의 package.json에는 sst 패키지만 있으면 됩니다. 추가적인 CDK나 인프라 관련 패키지는 필요하지 않습니다.

전역 변수

sst.config.ts 파일의 stacks() 메서드에 전달되던 app 인자를 대체하는 몇 가지 전역 변수가 있습니다. 바로 $app과 $dev입니다.

  1. $app.name은 앱의 이름을 제공합니다. 이전에는 app.name을 사용했습니다.
  2. $app.stage는 스테이지 이름을 제공합니다. 이전에는 app.stage를 사용했습니다.
  3. $dev === true는 개발 모드인지 여부를 알려줍니다. 이전에는 app.mode === "dev"를 사용했습니다.
  4. $dev === false는 배포 중인지 여부를 알려줍니다. 이전에는 app.mode === "deploy"를 사용했습니다.
  5. app.mode === remove에 해당하는 대체 기능은 없습니다. sst remove 실행 시 컴포넌트가 평가되지 않기 때문입니다.
  6. app.region은 v3에서 리소스를 다른 리전이나 AWS 프로파일, 또는 _프로바이더_에 배포할 수 있기 때문에 더 이상 사용되지 않습니다. 기본 AWS 프로바이더의 리전을 얻으려면 aws.getRegionOutput().name을 사용할 수 있습니다.

스택 없음

스택이 없기 때문에 스택 함수 내부에서 stack 인자에 접근할 수 없습니다. 또한 stack.addOutputs({}) 메서드도 사용할 수 없습니다.

여전히 파일 안에서 여러분의 구조나 _컴포넌트_를 그룹화할 수 있습니다. 하지만 무언가를 출력하려면 설정의 run 메서드에서 반환해야 합니다.

sst.config.ts
async run() {
  const auth = await import("./infra/auth");


  return {
    UserPool: auth.userPool.id,
    IdentityPool: auth.identityPool.id,
    UserPoolClient: auth.userPoolClient.id
  };
}

기본값 설정

앱 내 모든 함수에 기본값을 적용하는 메서드들(addDefaultFunctionBinding, addDefaultFunctionEnv, addDefaultFunctionPermissions, setDefaultFunctionProps)은 전역 $transform으로 대체할 수 있습니다.

sst.config.ts
$transform(sst.aws.Function, (args, opts) => {
  // 컴포넌트에서 설정되지 않은 경우 기본값 설정
  if (args.runtime === undefined) {
    args.runtime = "nodejs18.x";
  }
})

$transform에 대해 더 알아보세요.

클라이언트

Node.js 클라이언트는 이제 JS SDK로 불리며 몇 가지 사소한 변경 사항이 있습니다.

package.json에서 sst를 최신 버전으로 업데이트하세요. 모노레포를 사용 중이라면 모든 패키지에서 sst를 업데이트해야 합니다.

바인딩

SST v3에서는 Resource 모듈을 통해 모든 바인드 또는 링크된 리소스에 접근할 수 있습니다.

예를 들어, 버킷을 함수에 연결한다고 가정해 보겠습니다.

sst.config.ts
const bucket = new sst.aws.Bucket("MyBucket");


new sst.aws.Function("MyFunction", {
  handler: "src/lambda.handler",
  link: [bucket]
});

함수 내에서 다음과 같이 접근할 수 있습니다.

src/lambda.ts
import { Resource } from "sst";


console.log(Resource.MyBucket.name);

Config

Config에도 동일하게 적용됩니다. 비밀을 살펴보겠습니다.

sst.config.ts
const secret = new sst.Secret("MySecret");


new sst.aws.Function("MyFunction", {
  handler: "src/lambda.handler",
  link: [secret]
});

함수 내에서 동일한 방식으로 접근할 수 있습니다.

src/lambda.ts
import { Resource } from "sst";


console.log(Resource.MySecret.value);

핸들러

v2에서는 Node 클라이언트의 일부 모듈에 핸들러와 훅이 있었습니다.

v2
import { ApiHandler } from "sst/node/api";


export const handler = ApiHandler((event) => { });

이 기능들은 실험적이었으며, 현재 v3에서는 지원되지 않습니다. 이 기능을 계속 사용하려면 먼저 package.json에 추가해야 합니다.

package.json
{
  "sstv2": "npm:sst@^2",
  "sst": "^3"
}

이렇게 하면 프로젝트에 v2와 v3가 모두 설치됩니다. 둘 다 sst 바이너리를 가지고 있으므로, v3가 우선순위를 가지도록 해야 합니다. 따라서 v3는 v2 뒤에 나열되어야 합니다.

그런 다음 sstv2 별칭을 통해 이 기능들을 가져올 수 있습니다.

v3
import { ApiHandler } from "sstv2/node/api";


export const handler = ApiHandler((event) => { });

구조체

아래는 v2 구조체의 v3 컴포넌트 버전을 보여줍니다.

API

sst.config.ts
const api = new sst.aws.ApiGatewayV2("MyApi", {
  domain: "api.example.com"
});


api.route("GET /", "src/get.handler");
api.route("POST /", "src/post.handler");

Job

Job을 대체하는 Task 컴포넌트는 AWS Fargate를 기반으로 합니다. 이는 백그라운드에서 컨테이너 작업을 실행합니다.

sst.config.ts
const cluster = new sst.aws.Cluster("MyCluster", { vpc });


cluster.addTask("MyTask", {
  image: {
    context: "./src",
    dockerfile: "Dockerfile"
  }
});

Job과 Task 사이에는 몇 가지 주요 차이점이 있습니다.

  1. Task는 AWS Fargate를 기반으로 합니다. Job은 AWS CodeBuild와 Lambda를 조합하여 사용했습니다.
  2. Task는 기본적으로 Fargate를 기반으로 하기 때문에, SST SDK가 지원하지 않는 런타임에서도 AWS SDK를 사용하여 상호작용할 수 있습니다.
  3. 개발 모드에서 Task는 Fargate만 사용하는 반면, Job은 Lambda를 사용했습니다.
  4. CodeBuild는 분당 요금이 부과되지만, Fargate는 CodeBuild보다 훨씬 저렴합니다. X86 머신 기준으로 대략 시간당 $0.02 vs 시간당 $0.3입니다.

Task에 대해 더 알아보세요.

RDS

sst.config.ts
new sst.aws.Postgres("MyDatabase", {
  version: "15.5",
  databaseName: "acme"
});

마이그레이션에는 Drizzle Kit을 사용하는 것을 권장합니다. Drizzle 예제를 확인해 보세요.

Cron

sst.config.ts
new sst.aws.Cron("MyCronJob", {
  schedule: "rate(1 minute)",
  function: "src/cron.handler"
});

Table

sst.config.ts
const table = new sst.aws.Dynamo("MyTable", {
  fields: {
    id: "string"
  },
  primaryIndex: { hashKey: "id" }
});


table.subscribe("MySubscriber", "src/subscriber.handler");

주제

sst.config.ts
const topic = new sst.aws.SnsTopic("MyTopic");


topic.subscribe("MySubscriber", "src/subscriber.handler");

큐(Queue)

sst.config.ts
const queue = new sst.aws.Queue("MyQueue");


queue.subscribe("src/subscriber.handler");

Config_WZBYeaceqFWpi8bpye289M

Config 구조체가 이제 Secret 컴포넌트로 분리되었으며, v3에서는 모든 값이나 _파라미터_를 바인딩하는 별도의 방법이 있습니다.

Secret

sst.config.ts
const secret = new sst.Secret("MySecret");

CLI에서 시크릿을 설정하는 방법도 약간 변경되었습니다.

Terminal window
npx sst secret set MySecret sk_test_abc123

Parameter

Linkable 컴포넌트를 사용하면 어떤 값이든 바인딩하거나 _링크_할 수 있습니다.

sst.config.ts
const secret = new sst.Linkable("MyParameter", {
  properties: { version: "1.2.0" }
});

함수 내에서 이 값을 접근하려면 다음과 같이 사용합니다.

src/lambda.ts
import { Resource } from "sst";


console.log(Resource.MyParameter.version);

버킷

sst.config.ts
const bucket = new sst.aws.Bucket("MyBucket");


bucket.subscribe("src/subscriber.handler");

서비스

sst.config.ts
const cluster = new sst.aws.Cluster("MyCluster", {
  vpc: {
    id: "vpc-0d19d2b8ca2b268a1",
    securityGroups: ["sg-0399348378a4c256c"],
    publicSubnets: ["subnet-0b6a2b73896dc8c4c", "subnet-021389ebee680c2f0"],
    privateSubnets: ["subnet-0db7376a7ad4db5fd ", "subnet-06fc7ee8319b2c0ce"]
  }
});


cluster.addService("MyService", {
  loadBalancer: {
    domain: "my-app.com",
    ports: [
      { listen: "80/http" }
    ]
  }
});

Cognito

sst.config.ts
const userPool = new sst.aws.CognitoUserPool("MyUserPool");


const client = userPool.addClient("MyClient");


new sst.aws.CognitoIdentityPool("MyIdentityPool", {
  userPools: [{
    userPool: userPool.id,
    client: client.id
  }]
});

Function

sst.config.ts
new sst.aws.Function("MyFunction", {
  handler: "src/lambda.handler"
});

AstroSite

sst.config.ts
new sst.aws.Astro("MyWeb", {
  domain: "my-app.com"
});

StaticSite

sst.config.ts
new sst.aws.StaticSite("MyWeb", {
  domain: "my-app.com"
});

RemixSite

sst.config.ts
new sst.aws.Remix("MyWeb", {
  domain: "my-app.com"
});

NextjsSite

sst.config.ts
new sst.aws.Nextjs("MyWeb", {
  domain: "my-app.com"
});

AppSyncApi

sst.config.ts
const api = new sst.aws.AppSync("MyApi", {
  schema: "schema.graphql",
  domain: "api.domain.com"
});


const lambdaDS = api.addDataSource({
  name: "lambdaDS",
  lambda: "src/lambda.handler"
});
api.addResolver("Query user", {
  dataSource: lambdaDS.name
});

SvelteKitSite

sst.config.ts
new sst.aws.SvelteKit("MyWeb", {
  domain: "my-app.com"
});

SolidStartSite

sst.config.ts
new sst.aws.SolidStart("MyWeb", {
  domain: "my-app.com"
});

WebSocketApi

sst.config.ts
const api = new sst.aws.ApiGatewayWebSocket("MyApi", {
  domain: "api.example.com"
});


api.route("$connect", "src/connect.handler");
api.route("$disconnect", "src/disconnect.handler");

KinesisStream

sst.config.ts
const stream = new sst.aws.KinesisStream("MyStream");


stream.subscribe("MySubscriber", "src/subscriber.handler");

ApiGatewayV1Api

sst.config.ts
const api = new sst.aws.ApiGatewayV1("MyApi", {
  domain: "api.example.com"
});


api.route("GET /", "src/get.handler");
api.route("POST /", "src/post.handler");
api.deploy();

마이그레이션을 완료하신 것을 축하드립니다.

이 가이드에서 오류를 발견하거나 추가할 내용이 있다면, _이 페이지 편집_을 통해 PR을 제출해 주세요.