Deploy Your Serverless Infrastructure

Link to chapter -

1 Like

After this has been deployed to AWS, is it OK to delete the resources we created manually?

What is the list of services that can be deleted once this step is finished?

Do you mean the services from the first part of the tutorial?

The two parts of the tutorial create complete separate resources. So removing one won’t affect the other.

Ya Jay I mean the services we created manually at the beginning (without CloudFormation). It would just be nice if there was a section that went a bit like this:

Now that we have deployed our resources using CloudFormation, we can go in an delete the ones we created manually: API Gateway, Lambda, Cognito, etc…

Related question – this part of the tutorial create a user pool named generically ‘stage’-user-pool rather than ‘stage’-notes-user-pool. Any reason for this? If we start developing multiple apps we would want these to be more easily recognizable no? And what happens if we forgot about this and made another app with the same user pool naming convention… when we tried serverless deploy would it just fail because there’s already a user pool with that name?

@mperone Yeah that’s a good point. It should be $stage-notes-user-pool or something of the like.

@peetss Yeah we could add a note. But it’s really up to you if you want to keep those around. I know people don’t necessarily go through the advanced part of the tutorial.

Idiot question(s)!

So then, I’ve ran sudo serverless deploy -v. Now my aws site is updated! Huzzah!

But. I don’t THINK my client-side stuff (app-client) is pointing at all that.

Will that be covered in further chapters? (I will be looking into this later, and if I answer my own questions I’ll leave up the answer in an edit)

Yup. In the next few chapters you’ll be asked to update it.

1 Like

When deploying the new CloudFormation template(s), I get the following error:

  Error --------------------------------------------------
  The CloudFormation template is invalid: Template error: instance of Fn::GetAtt references undefined resource NotesTable

For debugging logs, run again after setting the “SLS_DEBUG=*” environment variable.

In my serverless.yml I have the following:

    - Effect: Allow
        - dynamodb:DescribeTable
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
      # Restrict our IAM role permissions to
      # the specific table for the stage
        - "Fn::GetAtt": [ NotesTable, Arn ]
1 Like

So I just cloned the backend api from github, and now I gets another error:

  An error occurred while provisioning your stack: ListLambdaFunction - Value of property Variables must be an object with String (or simple type) properties.

I was missing the env.yml file. Apparently its not part of the official github repo?

Yeah that file isn’t meant to be checked in since it contains sensitive information. I’ll add a note to the repo so it’s not confusing.

Or maybe just include the file in the repo, but give the strings a value like “REPLACE THIS WITH YOUR STRIPE KEY”?

Sorta, we just don’t want to give the impression that the file should be in your Git repo.

I totally understand that.

1 Like

Hi @jayair - When I tried to deploy, I get the following cloud formation error:

    Error --------------------------------------------------
    The CloudFormation template is invalid: Template format error: Unrecognized resource types [AWS::Cognito::UserPool, AWS::Cognito::IdentityPoolRoleAttachment, AWS::Cognito::UserPoolClient, AWS::Cognito::IdentityPool]

     For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.

Any tips on what I can try next? I validated that those are indeed CloudFormation resource types:

1 Like

@kpathakota I am having the same problem. In my case is because my default region does not support Cognito. You can fix that by running sls deploy -v --region us-east-1

What I am really trying to figure out is how to leave my whole stack as sa-east-1 (does not support cognito) and have cognito on the us-east-1 region. @jayair or anyone else - could you help me? Thanks in advance

I haven’t tried it but conceptually it should be possible?

What’s the issue you are running into?

Btw, @kpathakota did @leogonzalez’s tip work for you?

1 Like

@jayair - yes, worked! @leogonzalez - thanks! That was exactly it. Makes sense that the region did not understand that particular CloudFormation template if it’s not available.


Thanks @jayair - I want to run my entire stack in Sao Paulo (sa-east-1) since response times are better (90% better than us-east-1 for me) except cognito (us-east-1) since the service is not available here.

running sls deploy -v --region sa-east-1 throws the error since cognito is not available, so I was wondering how can I override the region for a specific service (Cognito) within my YML file.