superwerker: a best-practice AWS foundation, installed by a template

The problem, and the shape of the answer

The project's own summary is that it helps you get started with the cloud quickly without investing in consultants or devoting time to extensive research, and that it is a free, open source solution that sets up an environment following best practices for security and efficiency so that you can focus on your core business.

The phrase in the middle is the whole product. Every organisation that moves to a cloud faces the same sequence of decisions, and none of them is interesting: do you use one account or several, how do you federate your existing identity, how do you stop a root user from doing something careless, which detection services do you turn on, how do you find out what the thing costs you. The answers are well understood, they are written down, and the work is in applying them consistently, which is the work nobody wants to do and everybody has to do.

The tool is built by two companies, both described as advanced partners, and the readme says what they are: an organisation that automates the setup with prescriptive best practices, enabling small companies to focus on their core business by saving setup and maintenance time and money.

So it is a piece of institutional knowledge, packaged as a template. The knowledge is not neutral, and the project does not pretend otherwise. The word prescriptive is in the readme, and the FAQ's rule of thumb is that the tool is ideal for getting started with preconceived decisions based on years of experience. Somebody decided what a well-architected foundation looks like, and the tool applies that decision for you.

That framing also explains the two things the project is good at and the one it is not. It is good at the first ninety minutes of a cloud account, because that is exactly the set of decisions it encodes. It is good at being adapted, because the code is open and the decisions are visible. And it is not a substitute for a cloud team, because a company that outgrows the preset needs a different conversation.

The licence is the permissive MIT one, the project is published through the cloud provider's own quick start catalogue as well as through its own releases, and the documentation lives on a separate workshop site rather than in the repository.

What the setup actually turns on

The technical inventory is ten items, and reading it in order tells you the architecture.

The first item is the foundation: the organisation's control tower service together with the single sign-on service, described as the basis for a future-proof multi-account setup. Everything else in the list hangs off that pair. A multi-account environment with centralised identity is the shape the tool is building, and it is the shape the account structure of the rest assumes.

The second and third are the detection pair: a managed threat detection service for automatic detection of possible breaches, and a security posture service to ensure established security standards. Two services rather than one because they answer different questions: one tells you about an active attempt, the other tells you about a configuration that drifts from the standard. A deployment that has the second and not the first is a deployment that knows it is misconfigured; one with the first and not the second is one that knows it is under attack but not that its rules have drifted.

The fourth is backup, for automated creation of backups. The readme's plain-language section is more specific about the scope: backups enabled for all database and file systems, not just the ones somebody remembered.

The fifth is a budget service that auto-adjusts for cost control, and the plain-language version adds budget alarms, and a single consolidated bill with credits applied across all accounts. That last clause is not obvious and matters more than it sounds: without credit distribution, a company with a dozen accounts has a dozen bills and a procurement department that cannot use any of them.

The sixth is service control policies to protect the infrastructure from intentional or unintentional mistakes. That is a blunt instrument by design, and the phrase intentional matters: the policies are there to stop somebody, including an administrator, from doing something the organisation has decided should not be possible.

The seventh is the systems manager service, used for its operations centre and items features, for notification aggregation and incident response handling. The eighth is secure mailboxes and service catalogue aliases for all root accounts, which is a small line in the list and a large one in practice: a root account that receives mail about its own activity is a root account you can audit.

The ninth is a dashboard with deep links to resources, and the readme names the three things it links to: setting up single sign-on with existing identity providers, the detection and posture dashboards, and account setup. A dashboard whose links go to the page where you would have to do the work is a dashboard, and one whose links go to the work is a console.

And the tenth is billing: PDF invoices, credit sharing, and tax inheritance, which are the three settings a company needs before it can give an invoice to a customer in another country.

So the list is not a shopping list. It is a sequence: accounts and identity, then detection and posture, then the services that protect and cost, then the notification and audit layer, then the commercial paperwork.

The plain-language section, and what it reveals

The readme has a section headed with a question, and it is the same list restated for somebody who does not know what a control tower is. The framing sentence is the good one: the cloud provider gives you all the building blocks, and this tool adds the wiring and the instructions so that you can start ahead rather than at the beginning.

That distinction is the product. Every one of those services can be turned on by hand, and each takes an afternoon of decisions that a person will get slightly differently from the next person. The wiring is the parts that are not obvious: which identity provider goes where, which account owns which service, what the budget threshold should be before the alarm, which policies apply to the logging accounts and which to the workload accounts.

Four of the eight points are about the experience rather than about the configuration, and they are the ones that reveal the design intent.

The first is that you sign in to your accounts with your existing login provider, usually an office suite or a workspace account. So there is no second identity system to run, and no second set of credentials for an administrator to hold.

The second is that superuser access to the accounts is protected, which in the technical list is the pair of control tower and single sign-on, and in the plain version is the sentence that the root account is not where you do your work.

The third is the gradual roll-out: features can be enabled or disabled individually. That is also in the frequently asked questions, where the answer is that it enables a gradual roll-out and also facilitates installation into an existing setup. The second half of that sentence is the important one. A tool that can only create a new account structure is a tool for new companies, and a tool that can be installed into an existing setup is a tool for the rest of the market, which is a much larger one.

The fourth is the cost claim, that the total cost of ownership is low because native and maintenance-free services are used and no third-party tooling is required. Every service in the list is a managed one, so the thing you are paying for is usage rather than a licence, and the only software you operate is the template.

And the last point is the living dashboard with a status overview, showing which features are active, and with links to the notification centre or to your security findings. The phrase living is doing work: the dashboard is not a picture of the state at installation time, it reports the state now, which is the only version of that information worth having.

Installing, updating, and the rule of thumb

There are two ways to install the tool, and the readme tells you which to use.

The first is the release in the project's own repository, described as the latest stable release and marked as recommended. The second is the cloud provider's quick start catalogue entry, and the difference between them is stated plainly: the quick start has a currently slower release frequency.

That parenthetical is the most useful sentence in the installation section. It tells you that the two channels are the same artefact published in two places, and that they drift, and which one is more current. A reader who picks the catalogue entry for convenience is accepting a version that is a few weeks behind, and the readme does not pretend otherwise.

The prerequisites are short and both of them are decisions rather than downloads. You need a dedicated account with administrative access, which is the first thing the template itself creates, so the account you point it at becomes the root of the new structure. And you need a domain with manageable name resolution, because the single sign-on setup and the service catalogue aliases both hang off a name, and because a company that plans to send mail from its root accounts needs a domain it controls.

The installation itself is done with the cloud provider's infrastructure as code service, and the instructions live on a separate workshop site rather than in the readme. That is a sensible choice for a template this size, and it also means the documentation is a living thing that can be revised without a release.

The update procedure is where the design shows again. A release is published, the update is applied through the current template, and the steps given are: open the console, go to the infrastructure service, choose the stack, choose to update, choose to replace the current template, and paste the link to the newest version from the object store.

Replacing the template rather than applying a change set is the right choice for this kind of stack, and it has a consequence worth naming: the template owns the resources it created, so a new template version can restructure them. That is what makes the per-feature switches and the gradual roll-out possible, and it is also why the tool has a cleanup directory: a stack that has to be able to change shape has to be able to be taken apart.

And the rule of thumb from the frequently asked questions is the sentence I would put on the front page: if you have no dedicated cloud team or centre of excellence in-house, you should use it. The same section says large companies can use it as a basis, since the code is open and can be tailored.

The cost answer is equally direct: the tool itself is free and open source under the MIT licence, the costs are the cloud services you turn on, and smaller setups and test setups cost less than ten dollars a month. That last figure is the kind of number that makes a decision easy, and it is also the number to check against your own requirements, because it describes a small footprint and the detection and posture services are priced per account and per workload.

The repository, and what the file names say

The top level of the repository is short, and it is the shape of an infrastructure as code project that generates a template.

There is a directory for the application code, written in TypeScript against the cloud provider's infrastructure development kit, and a directory for the templates that the code generates. That split is the whole build: the code is the source, and the templates are what gets deployed. A reader who wants to know what the tool actually creates looks in the templates; a reader who wants to change it looks in the code.

There is a cleanup directory, which is the teardown, and it is the counterpart of a tool that can restructure a stack. There is a scripts directory for the supporting commands, a docs directory for the documentation, and a tests directory.

And there is a configuration file for a template testing tool, which is the cloud provider's own harness for running infrastructure as code templates through a deployment and checking the result. That is a significant inclusion: it means the project tests the thing that is actually deployed, rather than testing the code that generates it, and a template test is slow and awkward in a way a unit test is not.

There is a release configuration file, which is the conventional name for the tool that generates a release from the commit history, and it pairs with the repository's own releases being the recommended install route. The pre-commit configuration does the same for the checks.

Then there is a submodules file, which tells you the repository pulls in something from elsewhere, most likely the templates themselves if the code is generated from a different project. There is a glossary at the root, which is a surprisingly good sign: a project that has to explain what the cloud's own product names mean in practice has a reader who is new to the vocabulary, and a glossary is where you help them.

And there is the governance material. A development document, a security policy, a code of conduct, and a licence file. The security policy in a project that creates accounts and sets policies is not paperwork, it is the thing that tells a user where to report a problem with a template that gives them more access than they expected.

Finally there is an editor settings directory and a continuous integration directory, which is the standard set for a project that wants contributions and runs checks on them.

Editorial conclusion

superwerker fits a small company that has no cloud team and no appetite to research landing zones, and fits a larger one that wants a known-good baseline to start from and adjust. It does not fit an organisation whose cloud footprint is already large and bespoke, or one that wants the individual decisions rather than the preset. Verify first which of the features you will use and which you will leave off, since the whole design assumes you can adopt them gradually, what the running cost of the enabled services is, because the software is free and the services are not, and that the template you install is the version you intend to keep, since the project publishes through two channels with different release frequencies.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. superwerker/superwerker on GitHub