# Allgemeine Richtlinien für die Größe von AWS-Instanztypen
**URL:** https://meta.discourse.org/t/general-guidelines-for-size-of-aws-instance-types/85953
**Category:** Self-hosting
**Tags:** hosting
**Created:** [23. April 2018 um 09:10 UTC](https://meta.discourse.org/t/general-guidelines-for-size-of-aws-instance-types/85953 "2018-04-23T09:10:12Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Ave](https://meta.discourse.org/u/Ave)
#### Post date: [23. April 2018 um 09:10 UTC](https://meta.discourse.org/t/general-guidelines-for-size-of-aws-instance-types/85953/1 "2018-04-23T09:10:12Z")
Leute, ich versuche herauszufinden, welche Instanztypen bei AWS für etwa 200 Benutzer pro Monat geeignet sind, die die Plattform jeweils etwa zweimal täglich nutzen. Gibt es eine Faustregel, der ich folgen kann, um zu ermitteln, welche Instanzgröße ich benötige, um die Benutzer zu unterstützen?
Die Zahl scheint ziemlich gering zu sein, daher denke ich, dass ich mit einer mittleren Instanz auskommen kann, aber ich möchte wissen, ob es Skalierungseigenschaften gibt, die ich berücksichtigen sollte.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [23. April 2018 um 09:16 UTC](https://meta.discourse.org/t/general-guidelines-for-size-of-aws-instance-types/85953/2 "2018-04-23T09:16:21Z")
The best rule of thumb is “try it, and if you need more resources, get bigger instances, and if the instance is basically idle, get smaller instances”. Users is a _terrible_ metric for sizing, BTW; page views is much better, particularly absolute peak page views per second. If you’re using auto-scaling you can cheat a bit and just use lots of little instances and have them appear and disappear, but that’s a _lot_ more work (by like a couple of orders of magnitude) than just spinning up an instance per AZ and heading off to the pub.
---
### Author:  [@Ave](https://meta.discourse.org/u/Ave)
#### Post date: [23. April 2018 um 09:28 UTC](https://meta.discourse.org/t/general-guidelines-for-size-of-aws-instance-types/85953/3 "2018-04-23T09:28:28Z")
Wouldn’t spinning up an instance per AZ be of a similar complexity as the autoscaling option?
Only difference being that I’d have to add a bunch of rules on when to autoscale? (or is the autoscaling part of this the portion where the complexity increase tremendously?)
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [23. April 2018 um 09:39 UTC](https://meta.discourse.org/t/general-guidelines-for-size-of-aws-instance-types/85953/4 "2018-04-23T09:39:21Z")
Static-machine-per-AZ is trickier than one machine for everything (separate database/redis, need to transport containers around on rebuild, etc), but that’s just the cost of doing business in AWS, where there are no guarantees about the longevity of anything running in a single AZ. Autoscaling, on the other hand, requires automating a whoooooooole pile of stuff (like central container build, pulling down the container image from somewhere, ensuring the app.yml is available, dealing with in-progress rebuilds, and a bunch of other stuff), and then on top of that, automating it _quickly enough_ that the autoscaling is actually useful (no point taking 20 minutes to do all that stuff because by then the load spike’s probably gone because everyone’s left because your site was down), so you’re probably going to have to automate the build of the entire AMI on rebuild, which is another layer of entertaining complexity. Don’t forget the fiddling required to gracefully transition between launch configs when you roll your new AMI – and somewhere in there you need to run database migrations…
AWS is not simple, and anyone who says differently is selling something. Probably AWS.
---
### Author:  [@Maisy](https://meta.discourse.org/u/Maisy)
#### Post date: [23. April 2018 um 14:36 UTC](https://meta.discourse.org/t/general-guidelines-for-size-of-aws-instance-types/85953/5 "2018-04-23T14:36:14Z")
I’m currently undergoing this exercise myself - we want to host on AWS, but aren’t sure how we’d set up Discourse for “higher availability” without a lot of faff.
The way I’d see it, you’d need to do something like this:
- RDS to host Postgres (with multi-AZ enabled - this allows configuration changes including changing the size of the RDS instance without downtime, and gives you automatic failover if the DB seizes-up)
- EC2 r4.large instance for Redis (or ElastiCache Redis, but beware of vendor lock-in)
- EC2 m5.large or any appropriate size for the actual Discourse instances
- Classic ELB to load-balance traffic between the Discourse “web workers”
- S3 for upload storage
As you can see, the majority of it involves breaking the Discourse stack up into its individual components and putting them onto separate machines. That obviously doesn’t give you automatic scaling (you’d need AMIs, a Launch Config and ASGs for that), and you’d obviously still have the issue with managing upgrades on all instances plus any DB migrations that are needed along with it.
Perhaps in the future, there could be a Cloudformation script for AWS, or Packer script (for all providers) that does all this for you.
After you’ve gone through all that, you wonder if it’d just be easier to have a single AWS instance of the right size with daily backups going into S3. It’s not high availability, but it should suffice for all but the largest communities.
What I haven’t investigated yet (but will get to) is the possibility of using Kubernetes to provision/deploy Discourse. That way, in theory, you could set up a Kubernetes cluster on AWS with _kops_ or something similar, and delegate responsibility for the docker containers to Kubernetes. [This might be worth reading](https://medium.freecodecamp.org/how-to-set-up-an-internal-team-forum-in-half-a-day-using-discourse-b13588d907fe).
If I make any progress, I’ll get back to you!
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [23. April 2018 um 21:50 UTC](https://meta.discourse.org/t/general-guidelines-for-size-of-aws-instance-types/85953/6 "2018-04-23T21:50:56Z")
> [@mpalmer](#):
>
> BTW; page views is much better, particularly absolute peak page views per second
Also very helpful, even critical, to know: **what percent of your pageviews are anonymous versus logged in?**