I'm building an early-stage startup project with several containers: an API, two frontends, background workers, Dagster, Elasticsearch, and PostgreSQL. Everything currently runs on a VPS, but I'm considering moving to AWS because I already use S3 there. I want to keep infrastructure costs low and deploy automatically through GitHub Actions. I'll also need access to a GPU or another practical way to run an AI model. What AWS services or service combinations would make sense for this kind of MVP without paying for unnecessary high-availability or enterprise features?
4 Answers
For the AI workload, first identify whether you actually need a dedicated GPU running continuously. If the model can be accessed through a managed inference service, pay-per-use access may be much cheaper than keeping a GPU EC2 instance online. If you do need your own model, consider starting it only for jobs or scheduled workloads rather than leaving it running 24/7. Also check GPU availability and quotas before designing the deployment around one specific instance type.
For an MVP, I’d seriously consider staying on the VPS until real traffic or operational requirements justify moving. AWS can be expensive for services that sit idle. If you do migrate, look into AWS Activate credits first. A relatively simple setup could use App Runner or another managed container service for the API, frontends, and workers, a small RDS PostgreSQL instance, and a small EC2 instance for Elasticsearch if you’re comfortable managing it yourself. Avoid automatically adopting multi-node RDS or search architectures designed for large production workloads when a single small instance is sufficient.
Be careful with Elasticsearch in particular—it can become one of the most expensive parts of this stack on AWS. Managed search is convenient, but the recommended configurations often assume high availability, scaling, and heavy traffic. For a proof of concept, a small self-managed instance may be cheaper, though you’ll be responsible for backups, upgrades, monitoring, and recovery. The same principle applies to PostgreSQL: start with a modest single instance and scale only when the workload requires it.
Before deploying anything, set up MFA, a budget, billing alerts, and Cost Explorer. New cloud accounts can accumulate surprisingly large charges through GPU instances, managed databases, search clusters, or forgotten resources. Also configure GitHub Actions to use AWS OIDC and short-lived IAM roles instead of storing long-lived AWS access keys in a repository. If the account is new, GPU quotas may start at zero, so you may need to request an increase. Access to some managed AI models can require a separate approval as well.
I’m not completely new to AWS—I’ve used it for Next.js projects—but this is my first larger containerized deployment. I currently use Infisical for secrets, and I’ll look into the security and quota setup first.
The right choice depends heavily on the model and how often it runs. A small, occasional batch workload and a low-latency always-on endpoint will need very different infrastructure, so I’d measure that before selecting a GPU service.