The bold lines fixed the issue for me - ApiId: !Ref ComputeApi Stage: !Ref ComputeApi.Stage

UsagePlan:
   Type: 'AWS::ApiGateway::UsagePlan'
   DependsOn:
     - ComputeApi
   Properties:
     ApiStages:
       - ApiId: !Ref ComputeApi
         Stage: !Ref ComputeApi.Stage
     Description: Customer dubdub usage plan
     Quota:
       Limit: 5000
       Period: MONTH
     Throttle:
       BurstLimit: 200
       RateLimit: 100
     UsagePlanName: Plan_dubdub

So I spend basically the whole day figuring out how to deploy my stack. I found an okay workaround by inspecting the stack log in the CloudFormation console. I noticed that the stage which is associated with the deployment is reliably created last and that this stage always has the name ${AWS::StackName}Stage so that I can reliably use DependsOn with that stage. This of course will only work as long as the naming convention within SAM won’t change. So I hope we can get a fix soon.

This seemed to work for me

Parameters:
    StageName:
    Default: 'dev'
    Type: String

Resources:
  MyLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: mylookupidentity
      CodeUri: my_lambda.zip
      Events:
        APIGateway:
          Type: Api
          Properties:
            Path: /myfn
            Method: post
            RestApiId: !Ref APIGateway
  APIGatewayKey:
    Type: AWS::ApiGateway::ApiKey
    DependsOn:
      - APIGatewayStage #LogicalId for API Gateway + 'Stage'
    Properties:
      Name: myAPI-api-key
      Enabled: true
      StageKeys:
        - RestApiId: !Ref APIGateway
          StageName: !Ref StageName

  APIGateway:
    Type: AWS::Serverless::Api
    Properties:
      Name: myAPI
      StageName: !Ref StageName
      MethodSettings:
      - HttpMethod: "*"
        LoggingLevel: INFO
        ResourcePath: "/*"
      DefinitionBody: 
        Fn::Transform:
          Name: AWS::Include
          Parameters:
            Location: docs/api.yaml

@jfuss for AWS::Serverless::Api resource now supports getting Stage and Deployment using following:

• !Ref: MyApi.Stage
• !Ref: MyApi.Deployment

However, issue still persists as DependsOn attribute doesn’t support usage of an intrinsic function(Ref in our case) for any of its value(s).

Possible approaches towards resolution might include:

1. Let CloudFormation mark Serverless::API complete only if all the associated resources (RestApi,Stage,Deployment) have finished their creation. Not a good approach(even if possible) as AWS::ApiGateway::RestApi resource has it own Lifecycle and CloudFormation actually has nothing to do with Serverless type resources lifecycle but translated/transformed CloudFormation specific resources.
2. Adding support/exception in DependsOn attribute for Serverless type resources so that !Ref can be used to get Stage/Deployment logical Ids.

So, both of these are true. If StageName is a straight up string, then it will be <ID><StageName>Stage. If it is an intrinsic function, it will be <ID>Stage. This is because SAM cannot reliably resolve intrinsic functions. SAM runs outside of CloudFormation where the actual intrinsic function resolution happens.

So just caught up on the complete issue here.

We should support some way to create ApiKeys. I thought this was part of #248 but doesn’t look like it made it there. Maybe it should be?

Maybe another way to help in solving this would be to do something similar to what we did to surface Versions and Aliases for AWS::Serverless::Function (Ref: FucntionLocicalId.Version). I think that would help in being able to make DependsOn for resources we generate but not sure how this really interacts and works outside the the AWS::Serverless::* Types (it’s doable but think there is some additional work to make this supported).

The suggestion you made about relying on the generated LogicalIds is the way to go (at least for now). I know of others that have suggested the same thing on other issues here. We have fully documented the generated resources we create here, so it is safe to depend on these naming conventions. Make sure to follow the docs, the stage logicalId is <AWS::Serverless::Api LogicalId><StageName value>Stage not based on the AWS::StackName. So in your example it would be restApi<whatever Ref: targetStage resolves to>Stage.

Note: AWS::Serverless::API (explicit) and AWS::Serverless::Function with an API Event type have different generates of resources. Please consult the documentation for references.

I have encountered this issue too. It’s very annoying. It’s unfortunate that after a year still the problem. Solution provided by @sanathkr and @jfuss sometimes works and sometimes doesn’t. My workaround was to depends my resource on a function (which is itself dependent on api gatewqay). Here is an example:

  MyACLassociation:
    Type: AWS::WAFRegional::WebACLAssociation
    DependsOn: ALambdaFunctionWhichIsTriggeredByApiGateway
    Properties: 
      ResourceArn: AnaRN
      WebACLId: !Ref MyWebACL

@umaragu how did you come up with Stage: !Ref ComputeApi.Stage? Is the Reference documented anywhere?

Just spent a day trying to understand why my stack kept failing even though I had all the DependsOn identified in the UsagePlan; swapping out the hard coded Stage with the !Ref resolved the issue. Big ol virtual high-five man!

See https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-generated-resources-api.html; it documents which resources are generated and how they’re referenceable.

@azarboon If a resource has a reference to another resource, CFN understands that it depends on that other resource and you don’t need to add the explicit “DependsOn” to it.

Is this issue going to be addressed? It’s been open for almost a year now and it’s a roadblock in using SAM template when you want to secure your API endpoints with Cognito.