Migrate from Vercel to AWS
This is NOT a necessary step. Please skip this page if you are just reading all the Starter Kit documents.
Vercel should satisfy our needs in most cases. Please only read when you are actually blocked by Vercel and are thinking about moving out.
Common reasons to migrate away from Vercel
Datadog APM
- Datadog APM is not possible in Vercel at the moment
Static IPs
- Egress: Vercel does offer static IPs, for their Enterprise plan only, read more here. Needing static egress IPs alone does not mean you should migrate to AWS.
- Ingress: Vercel can NOT offer static IPs for ingress. It might just be that it is not supported even on an AWS API gateway. This is a valid reason for the migration.
Other AWS services
Please try to use equivalent SaaS alternatives first, e.g.:
- RDS: CockroachDB or Neon
- Redis/Kafka/Message queue: Upstash
- SES: Postman (Legacy)
Potential valid reasons:
- ElasticSearch (please try Elastic's SaaS first if billing is not an issue)
- Need GPU equipped compute to train AI models
Heightened concern about security and maintenance
The SaaS products are quite easy to use. However, since they are inevitably open to the public network, there is an increased risk of DDoSing and brute-force attacks on the data infrastructure themselves. It is valid to move to AWS to conceal everything within private subnets thus mitigating the aforementioned risks if your service contains highly sensitive data (e.g. medical records).
Cost
Vercel and Serverless in general cost very little to start with. However, it can cost quite a lot more at scale. If your monthly running cost is in the high 3 digits or more, moving to AWS might help cut it down. Make sure to do your calculations first!
Common reasons NOT to migrate (since AWS is NOT a silver bullet)
- AWS: Infrastructure as a Service (IaaS)
- Vercel/CockroachDB/Upstash: Platform as a Service (PaaS)
Migrating to AWS means that you are going one layer lower in abstraction, which means there will be a lot more details to manage, e.g.:
- VPC (think of routing tables, security group rules etc.)
- ECS + ELB (think of auto scaling strategies, health checks etc.)
- RDS (think of replicas, failovers, instance upgrades etc.)
- IAM (everything about access management can be a pain)
There are tools like pulumi-components (and the below CLI) to help reduce the "AWS tax". However, it still requires YOU to understand everything that is happening inside to operate your infrastructure confidently.
How to migrate to AWS
CLI
The tooling team provides an internal CLI package (repo) to generate the necessary infrastructure code to deploy Starter Kit to AWS.
We recommend you read the README thoroughly before continuing.
Also ensure you have the following credentials ready for the CLI run:
- Postman API key (to send emails)
- Session secret (to protect session identifiers) [optional, can be autogenerated by the CLI]
- Datadog API key (for Datadog linkage) [optional]
- Datadog application key (for Datadog linkage) [optional]
Ensure your
.npmrc
is set up correctly to point the@opengovsg
scope to our internal GitHub registry.
Run the following command in your terminal to start the CLI:
npx -p @opengovsg/create-ogp-infra create-ogp-infra
Example repositories generated from the CLI
- Generated infra: https://github.com/opengovsg/starter-kit-example-infra
- App repo with generated deployment Github Action: https://github.com/opengovsg/starter-kit-example
These are private repositories. Please log in to GitHub to access them.
Example repositories if writing from scratch and not using the CLI
If you have used Pulumi and ECS before: reference the following repositories/PRs:
If there is any doubts with Pulumi or ECS: give us a ping on #tooling-team, especially @Blake. We are more than happy to pair with you and help sort out any issues regarding Vercel/AWS!