When I try to implement the <SST WebSocket example...
# sst
c
When I try to implement the SST WebSocket example I receive a logging permission error –
Copy code
CREATE_FAILED | AWS::ApiGatewayV2::Stage | ApiStage4697DF29 CloudWatch Logs role ARN must be set in account settings to enable logging (Service: AmazonApiGatewayV2; Status Code: 400; Error Code: BadRequestException; Request ID: d4c744ab-4f22-41fc-91dc-f9e4101fa39c; Proxy: null)
I can resolve this if I add
accessLog: false
to the WebSocket construct, but am wondering - • what’s the consequence of disabling these logs?  • is this just a mismatch between the IAM user policies SST has you create initially and what this construct expects/needs by default?
t
I'm not too sure what's behind this
I think the logs disable standard http access logs
Follow the “Enable API Gateway CloudWatch Logs” section to setup an IAM user for API Gateway.
Let us know if it works for you.
c
Thanks @Frank. Creating the new role and adding its ARN to the settings for WebSocket’s API Gateway seemed to resolve things. I can now run the construct w/o having to add
accessLog: false
without any errors. I haven’t enabled and viewed the logs in the console for this yet (beyond adding role ARN). I wanted to finish going through the SST & Seed notes on this to make sure I wasn’t turning anything that would blow up usage. There are a few things that were odd in the current console compared to the SST docs linked above - • in API Gateway there’s no longer an option to add the CloudWatch Role ARN as a top level setting (there is no settings link is shown at this level.) • you have to select a specific API first and can then add or view the CloudWatch ARN in its settings • for WebSocket APIs you have to manually add the ARN; for HTTP APIs the CloudWatch ARN is already set • since you may have multiple WebSocket APIs for the same functionality across multiple stages its a bit confusing if you’d need to manually update each of these, or if you’d need to manually keep them up to date as stages change or new ones are added for things like PRs I wonder if – • it’d be helpful to move / link the idea of creating this CloudWatch role earlier in the guide, or with the initial IAM role creation, to avoid it being unavailable when constructs expect it • there is a way to do any of this manual WebSocket API ARN assignment programmatically outside of the console to help manage things across multiple or ephemeral stages Thanks again for the quick help in getting me back on my feet with this.
Current API Gateway dashboard in console w/o top-level settings
Logging settings for an HTTP API, with CloudWatch role ARN preset
Logging settings for a Websocket API that requires manual CloudWatch ARN input
f
@Clayton Thanks for the details! Let me take a look at the console and get back to you.