og-aws keeps fifty AWS services inside one README, and several of the cells are empty

The whole guide lives in README.md, with no per-service files

The top level of the repository holds README.md, AUTHORS.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, LICENSE.txt, .travis.yml and .github/, plus three directories named admin/, figures/ and translations/. There is no docs/, no services/ and no per-service markdown, so every service chapter, from the ALB section through VPCs, Network Security, and Security Groups, is a heading inside one file. The consequence is for anyone who wants to track a change. There is no way to diff one service's guidance without diffing the entire guide, so the history of advice about ALB is entangled with the history of advice about Route 53. Finding one service means scrolling a table of contents roughly fifty rows long, and the repository's own structure offers no index beyond that table.

Kinesis Firehose has a gotchas entry and nothing else

The service table is built on three columns, Basics, Tips and Gotchas, and nearly every row fills all three. Kinesis Firehose is the exception: its Basics and Tips cells are empty, and the only link in that row is the gotchas anchor, `#kinesis-firehose-gotchas-and-limitations`. That is a real gap for a reader, and it is the worst-shaped gap in the table. You can read what people regret about Firehose, but the guide supplies no primer and no set of operational tips, so the entry cannot be used to learn the service, only to check someone who already knows it. A reader scanning the table specifically for warnings finds one here, then has to go outside the repository for everything that would have come before the warning.

Batch, DirectConnect and ECS have no gotchas, and three rows skip Tips

Three more rows are short at the right-hand end. DirectConnect and ECS show Basics and Tips with an empty third cell, and the Batch row stops after two links with no gotchas cell at all. Going the other way, Fargate, Glacier and Quicksight each offer Basics and Gotchas with the Tips column left blank. The point for a reader is that a three-column grid looks uniform right up until you need the cell that is missing. An empty gotchas cell reads like a service with no known traps, when the honest reading is that nobody wrote that section. Batch is the row where the absence is most likely to matter, and the guide offers no warning for it at all.

Load balancing gets three rows and no note on which one to read

ALB, CLB (ELB) and Load Balancers each have their own row, their own three anchors, and their own link target: `#alb-basics`, `#clb-basics`, `#load-balancer-basics`. The database side repeats the pattern, where RDS sits alongside RDS Aurora, RDS Aurora MySQL, RDS Aurora PostgreSQL, RDS MySQL and MariaDB, RDS PostgreSQL and RDS SQL Server. Nothing in the table says which of the three load balancing entries is current, whether one supersedes another, or whether they cover the same ground. A reader who opens the wrong one gets no signal that they are reading redundant material, and a reader who wants the full picture has to read all three. Splitting one topic across sibling rows also means an edit to one entry leaves the other two looking equally authoritative.

Heading names and link targets drift apart, so deep links break quietly

The row labels are written for humans and the fragments are not derived from them, and the two disagree in several places. Quicksight is spelled that way in the label where the service name is written QuickSight elsewhere, the Route 53 row points at `#route-53-basics` with a space in the fragment, and the Load Balancers row resolves to the singular `#load-balancer-basics` while the RDS Aurora PostgreSQL row resolves to `#rds-aurora-postgresql`. The consequence is concrete for anyone who links into the guide. A markdown table is not validated against its targets, so an anchor written by hand against a heading that later gets renamed becomes a dead link and nothing reports it. A URL pasted from a chat or an issue should therefore be treated as a hint, and the README searched for the heading instead.

Three special topics hold everything that is not a service chapter

Around the service table the guide has a Purpose section with Why an Open Guide, Scope and Legend, an AWS in General section with General Information, Learning and Career Development, Managing AWS and Managing Servers and Applications, and three Special Topics: High Availability, Billing and Cost Management, and Further Reading. A Legal section with a Disclaimer follows. Everything about cost therefore lives in one chapter, because the service rows offer only Basics, Tips and Gotchas and no price column. A reader asking what a service will cost has a single place to go, while a reader asking what will break has three columns but no cost column anywhere. The Legend chapter is the one place the three-column scheme itself is explained.

No releases, a master branch, and a last push dated 2024-08-16

The repository has no GitHub releases, so there is nothing to pin. The default branch is master rather than main, and the last push is dated 2024-08-16, which for AWS content means the service names, console wording and default values in the text have had more than two years to age. Nothing in the structure separates a section that was revisited from one that was left as written, so a correct section and a stale one look identical on the page. The consequence is that this cannot be treated as a versioned reference. If you need a citable snapshot you have to record a commit hash yourself, and if you need to know whether a specific limit still holds, the guide cannot be your only source.

CC-BY-4.0 makes reuse easy, and the absence of releases makes versioning hard

The content is prose under a Creative Commons CC-BY-4.0 license recorded in LICENSE.txt, with AUTHORS.md for credits and CONTRIBUTING.md for how to contribute, alongside a CODE_OF_CONDUCT.md and .travis.yml. Reuse is straightforward: the license permits redistribution and translation with attribution, and the translations/ directory shows the community already treats the text as translatable, with figures/ holding the images. The limitation is versioning, not permission. With no releases, a fork has no published point to merge from, and two sites that copy the guide at different moments will hold different text with no way to compare them except by diffing prose. If accuracy over time matters to you, keep your own dated copy and re-read master yourself.

Editorial conclusion

og-aws works as an orientation map for AWS, as a checklist of the services worth knowing about and a set of warnings to read before you rely on a service. It does not work as a reference you can quote, because it lives in a single README, has no releases, has no per-service files and was last pushed 2024-08-16. Use it to find out what exists, then verify the specifics against current AWS documentation. Before you depend on it, check whether the service you care about actually has a gotchas entry, since Batch, DirectConnect and ECS do not, and record a commit hash if you plan to cite it. The CC-BY-4.0 license makes the text reusable and translatable with attribution, so version control is your problem, not the license's.

Frequently asked questions

Official sources

1. Official README
2. Project repository