These are the rules this site holds itself to. They exist because the audience is technical and will notice the moment they are broken.
Claims and figures
- A specific figure — a service quota, a price, a performance characteristic, a failover time — is either stated with the date it was last checked, or it is left out. Where a number drives the recommendation, this site tells you to confirm it against current AWS documentation rather than relying on us: these figures move, and a dated claim on a web page is not a substitute for the source of truth. Approximations are labelled as approximations.
- No benchmarks are published that were not actually run. No performance claim is made from inference.
- Where AWS documentation and observed behaviour disagree, both are reported.
Trade-offs
- Every architectural recommendation names the condition under which it is right, and the condition under which it is wrong.
- Where another cloud or an on-premises arrangement is genuinely the better answer, this site says so. Pretending otherwise would cost more credibility than it gains.
- Cost guidance describes what drives cost rather than quoting prices, because prices change and regional variation makes a single figure misleading.
Corrections
Technical errors are defects. When one is identified, the page is corrected and the correction is noted rather than quietly overwritten. Material that has gone stale enough to mislead is either refreshed or withdrawn.
Independence
Nothing on this site is sponsored, and no placement is sold. Where a link points to a commercial service, it is because a reader at that point in the page would be helped by it — not because of a relationship.
On generated content
Material here is written to be read by a practitioner making a decision. The test applied before anything is published is whether it tells a competent engineer something they did not already know, or merely rearranges what they did. Material that only does the second is not worth publishing.