Managing Services on AWS

[vsmithy]

trafficstars

Improve documentation

Describe the problem

I am trying to get an idea of the general workflow when everything is serverless with aurora and fargate.

• Do we need to login to a supabase.com account, or do we just need to supabase link to connect the remote?
• What is the suggested approach for starting/stopping the AWS services (supabase start/stop)?
• Info on pushing local migrations to remote db? Is it just supabase db push --db-url 'add-url-here'?
• Is there a suggested approach for managing dev/staging/prod environments? Do we deploy a separate stack or each?
• There was a note in the readme about managing the amount of resources. This looks like it will end up costing $150-$300 per month USD - is that expected?

Describe the improvement

A clear and concise set of descriptions on the items listed above.

Additional context

This is a beast of a community offerring. The stack builds and deploys using the CDK (you have to synth and bootstrap first) but it is a massive amount of AWS resources and whenever we run into issues, there is little to no documentation on using this.

[mattrigg9]

@vsmithy Commenting to share my findings from my own experience:

• Do we need to login to a supabase.com account, or do we just need to supabase link to connect the remote?

• There is no association with supabase.com with the AWS deployment. The API itself is exposed via a CloudFront endpoint that your end clients can point to. For access to the Supabase studio (what you typically see on supabase.com), refer to the amplify link that's shared as an output from the Cloudformation stack. Note that it's very important to lock down the amplify site as soon as you launch it, otherwise full access to your Supabase instance is exposed to the world.

• What is the suggested approach for starting/stopping the AWS services (supabase start/stop)?

• There's no simple command to stop it, but it's not too difficult to script if you need to turn it on and off frequently. To shut it down manually, First go to ECS, and update each service to set the Desired Tasks to 0. Then go to RDS and select your DB cluster, then click Actions, choose Stop temporarily. Note that you can stop a DB cluster for up to seven days. If you don't manually start your DB cluster after seven days, your DB cluster is automatically started. This is a requirement imposed by AWS.

• Info on pushing local migrations to remote db? Is it just supabase db push --db-url 'add-url-here'?

• You can't use the CLI commands on your local instance unfortunately, as the DB is not exposed to the public internet. There are two ways you can do this. Either run the migration manually in the Amplify studio, or launch a bastion EC2 instance in the same VPC that was created for Supabase. Then update the database security groups so the instance has access to the DB. Then you can access the DB directly using the psql CLI.

• Is there a suggested approach for managing dev/staging/prod environments? Do we deploy a separate stack or each?

• You could either deploy a new stack in the same account, or deploy a separate stack to a separate account (it is generally considered best practice to have separate accounts for each stage for security and separation of concerns)

• There was a note in the readme about managing the amount of resources. This looks like it will end up costing $150-$300 per month USD - is that expected?

• This is highly dependent on the size of ECS instances and RDS capacity you provision, but this seems to be a roughly accurate cost for a smaller-sized deployment from what I've seen.

Hope this helps!