This is actually a problem whether you're using continuous deployment or not. You need to put a release out, which you have done some testing for, but you know that only real production traffic can shake out certain types of problems.

You don't have to have all three servers getting the same amount of traffic, and you don't have to have a single copy of your service on each server. So, you could reduce the weight of a single server that does canary traffic to reduce the pain, or you could run two copies of your service on a server, and have the canary copy get a trickle of traffic.

Another approach is to use shadow traffic - instead of handling the requests on the canary host, you handle it on the production host _and_ the canary host. You'd need to ensure the canary can't adjust the production database, for example - or maybe you only shadow read requests. If you don't get any errors, or you're able to prove to yourself that they function the same, you can then move to a more traditional canary.

You definitely need to adjust your continuous deployment implementation to your environment, whatever it is.

Could you add a 4th (maybe even smaller) server, and configure your load balancer to only route 5% of traffic to this server? We have the same problem, continuously enough requests to implement a system like this, but we only run on a small number of production servers. We've recently added a canary server into the pool, which does increase costs a little, but we made it a small instance, and route only a small amount of traffic to it.

If you paying by the 10 minute increment or less, you just have a 4th server for a few minutes. Something like:

1) Add 4th server at new version

2) Drop 1 old version

3) Launch 1 more new version

4) Drop 1 old version

5) Launch 1 more new version

6) Drop 1 old version

This way you never have less than 3 servers serving requests, but you never pay for more than 4. Should only cost a few cents for most cloud providers for this temp server.