Things we are trying to keep in mind:

1. Since we are managing our own cluster (via kops) there is the risk that it could get broken in a way that we don't know how to fix. We should design our deployment such that re-deploying the cluster from scratch is not costly.
2. We should avoid coupling ourselves tightly to a specific cloud provider. Today we have AWS credits, but in the future we have a reasons to want Google, Azure, some university-affiliated resources, etc.
3. One big reason for creating Scanner was to save on costs. If we aren't careful about the AWS resources we use, running Scanner may be no cheaper than the old system.

We have two kinds of state:

• Postgres database
• Redis cache

For the database, we currently use RDS. This satisfies (1) because it is outside the cluster, and it satisfies (2) because although RDS is proprietary, postgres itself is an open standard available anywhere. For the cache, we use a Redis image deployed inside the cluster. This violates (1). We could instead use Elasticache, which meets (1) and (2) -- analogous to our use of RDS. However, this strategy is not optimal with respect to (3): both RDS and Elasticache are more expensive that hand-deployed postgres and Redis.

My personal opinion is that we are more crunched for developer-time than AWS credit at this moment, so we should use RDS and Elasticache for now and keep an eye on the operating costs. We know it is technically straightforward to hand-deploy postgres and Redis on EC2 instances outside the cluster. Once we have a good handle on the operating costs, we can judge whether it is worth the potential cost savings to do so.

Thoughts?