Destroy resources created via Serverless without destroying Lambda endpoints

Joseph Astrahan picture Joseph Astrahan · Nov 20, 2017 · Viewed 10.7k times · Source

I have the following resource defined in my serverless.yml file. Its working great to create the resource for all my different stages of development.

resources:
  Resources:
    uploadBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:service}-${self:custom.stage}-uploads
    visitsTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${self:custom.visitsTable}
        AttributeDefinitions:
          - AttributeName: userId
            AttributeType: S
          - AttributeName: visitId
            AttributeType: S
        KeySchema:
          - AttributeName: userId
            KeyType: HASH
          - AttributeName: visitId
            KeyType: RANGE
        ProvisionedThroughput:
            ReadCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.stage}}
            WriteCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.stage}}

Problem is... if I do sls remove while deleting the database it made it also deletes everything else including the lambda functions and their api gateway endpoints which I need to stay around since I have policies explicitly set for them. How do I tell serverless I want to delete just the database or S3 or whatever it is and not the rest?

Things I've Tried:

I deleted manually on AWS, but if you do this and do sls deploy it does not create the database again! So not sure best way to do this...

Entire Serverless.yml file

service: mydomain-api

# Use serverless-webpack plugin to transpile ES6/ES7
plugins:
  - serverless-webpack
  - serverless-domain-manager

custom:
  webpackIncludeModules: true
  stage: ${opt:stage, self:provider.stage}
  visitsTable: "${self:service}-visits-${self:custom.stage}"
  domains:
    prod: api.mydomain.com
    staging: staging-api.mydomain.com
    dev: dev-api.mydomain.com
  dynamoDbCapacityUnits:
    prod: 5
    staging: 2
    dev: 2
  customDomain:
    basePath: ""
    domainName: ${self:custom.domains.${self:custom.stage}}
    stage: "${self:custom.stage}"
    certificateName: "mydomain.com"
    createRoute53Record: true

provider:
  name: aws
  runtime: nodejs6.10
  stage: prod
  region: us-east-1
  environment:
    VISITS_TABLE: ${self:custom.visitsTable}

  # 'iamRoleStatement' defines the permission policy for the Lambda function.
  # In this case Lambda functions are granted with permissions to access DynamoDB.
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:DescribeTable
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
      Resource: "arn:aws:dynamodb:us-east-1:*:*"

functions:
  create:
    handler: src/visits/create.main
    events:
      - http:
          path: visits
          method: post
          cors: true
          authorizer: aws_iam
  get:
    handler: src/visits/get.main
    events:
      - http:
          path: visits/{id}
          method: get
          cors: true
          authorizer: aws_iam
  list:
    handler: src/visits/list.main
    events:
      - http:
          path: visits
          method: get
          cors: true
          authorizer: aws_iam
  update:
    handler: src/visits/update.main
    events:
      - http:
          path: visits/{id}
          method: put
          cors: true
          authorizer: aws_iam
  delete:
    handler: src/visits/delete.main
    events:
      - http:
          path: visits/{id}
          method: delete
          cors: true
          authorizer: aws_iam

resources:
  Resources:
    uploadBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:service}-${self:custom.stage}-uploads
    visitsTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${self:custom.visitsTable}
        AttributeDefinitions:
          - AttributeName: userId
            AttributeType: S
          - AttributeName: visitId
            AttributeType: S
        KeySchema:
          - AttributeName: userId
            KeyType: HASH
          - AttributeName: visitId
            KeyType: RANGE
        ProvisionedThroughput:
            ReadCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.stage}}
            WriteCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.stage}}

Answer

dom picture dom · Sep 6, 2018

The Serverless Framework documentation says the following about sls remove:

The sls remove command will remove the deployed service, defined in your current working directory, from the provider.

So sls remove is not the way to go. Just remove the visitsTable resource from your serverless.yaml and run sls deploy again. The Serverless Framework uses AWS CloudFormation under the hood. So deleting things manually is no good idea. Just keep in mind: Resources created as part of an AWS CloudFormation stack must be managed and modified through stack updates. Maybe this is a good read: https://virtualbonzo.com/2017/12/11/did-you-manually-delete-a-resource-created-by-aws-cloudformation/