The superwerker open source solution by AWS Advanced Partners kreuzwerker and superluminar automates the setup of an AWS Cloud environment with prescriptive best practices. It enables startups and SMBs to focus on their core business - by saving setup and maintenance time and money.
There are two ways to install superwerker:
(the latest stable release - recommended)
(currently slower release frequency)
- A dedicated AWS Account with administrative access (sign up here)
- A domain and manageable DNS settings (You can register domains with Amazon Route53)
Installations instructions are available in the superwerker guide.
Superwerker configures the following AWS services and features in a fully automated way:
- AWS Control Tower and AWS Single Sign-On as the basis for a future-proof multi-account setup
- Amazon GuardDuty for automatic detection of possible threats breaches
- AWS Security Hub to ensure established security standards
- AWS Backup for automated creation of backups
- AWS Budget that is auto-adjusting for cost control
- Service control policies to protect the infrastructure from intentional or unintentional mistakes
- AWS Systems Manager OpsCenter/Items notification aggregation and incident response handling
- Secure mailboxes and service catalogue aliases for all root accounts
- A dashboard with more information and deep-links to resources, e.g. setting up SSO with existing identity providers, GuardDuty/Security Hub dashboards, AWS account setup
- Billing setup to enable PDF invoices, Credit Sharing and Tax inheritance.
AWS provides all the building blocks. superwerker adds the wiring and how to so you can start right ahead with a well-architected AWS foundation:
- Manage multiple AWS accounts and perform access management
- Sign in to your AWS accounts with your existing login provider (usually your email infrastructure provider, e.g. Office 365 or Google Workspace)
- Security built-in:
- Protect superuser (
root) access to your AWS accounts - Scanning for best practise violations and active threats against your infrastructure
- Backups enabled for all database and file systems
- Protect superuser (
- Billing best practices built-in: Automatic cost control, budget alarms and configuration for enhanced usability (PDF invoices as well as one single AWS bill and credits applied across all accounts)
- Low total cost of ownership: native and maintenance-free AWS service are used (no third-party tooling required)
- Notification centre: aggregates notifications from several services in a single place
- Gradual roll-out: features can be enabled/disabled individually
- Living quickstart dashboard with status overview (which features are active?) and actionable links to e.g. the notification center, or your security findings
- If you encounter problems using superwerker dont hesitate to create an issue
- Chat with us on the #superwerker channel in the OG-AWS Slack (invite link).
superwerker is ideal for quickly getting started with the AWS Cloud with preconceived decisions based on years of experience. Start-ups and small to medium-sized companies, where time-to-market and financial aspects play an especially important role, can benefit in particular.
As a rule of thumb: if you have no dedicated AWS team or cloud centre of excellence in-house, you should use superwerker.
But also large companies can use superwerker as a basis. Since superwerker is open source, it can also be tailored to individual needs.
superwerker itself is free and open source under an MIT licence. Costs may be incurred by the AWS services you set up. Smaller set-ups and test set-ups cost less than $10/month.
You can find more information about the costs on the detailed pricing pages for the services used, e.g. Control Tower, Security Hub, GuardDuty, AWS Backup
superwerker uses the proven infrastructure-as-code service AWS CloudFormation for installation. Please have a look at the installation section.
superwerker features can be activated individually. This enables a gradual roll-out and also facilitates installation into an existing AWS set-up.
We plan to roll-out releases via GitHub releases. The update is then deployed via the current CloudFormation template. You can then perform the update according to the instructions below:
- Go to the AWS Console
- Navigate to the CloudFormation service
- Choose the superwerker stack
- Choose
Update - Choose
Replace current template - For
Amazon S3 URL, copy the link to the latest version of the template e.g. "https://superwerker-releases.s3.amazonaws.com/0.13.0/templates/superwerker.template.yaml", the latest version number can be found here: Github Releases - Click
Next - Click
Next - Click
Nextagain - Tick the boxes acknowledging that CloudFormation might create IAM resources such as Roles and Policies
After completion of the stack update, navigate to the superwerker living documentation dashboard for more information.
superwerker is primarily designed for new AWS set-ups and can be used if AWS Control Tower is available in the respective region. superwerker will then try to set up services including Security Hub and GuardDuty. Depending on whether you already have them, you may need to clear the set-up accordingly beforehand.
Since superwerker uses AWS Control Tower as a basis, it is available in all regions where Control Tower is supported. Regions that are not enabled by default are currently not supported.
AWS Control Tower and Landing Zone also use AWS fundamentally, but leave a lot of free scope. Building on AWS Control Tower, superwerker provides further guide rails and facilitates a quick-start with AWS even further.
superwerker deliberately offers few parameters for adjustment. It has been designed to coexist with solutions like AWS Control Tower (+ Customizations) or with CloudFormation StackSets. These can be used to further customise the AWS set-up.
superwerker uses AWS CloudFormation for installation and updates. If the CloudFormation stack is deleted, the superwerker templates will also be deleted. This can negatively affect the running AWS set-up.
It’s complementary. You can consider superwerker a “well set-up”. At the same time, the underlying design decisions take into account the pillars of WAF. superwerker pushes the workloads into the Well-Architected direction using certain guardrails.
No, superwerker runs exclusively in your AWS account and does not communicate with the internet.
superwerker always aims to build on AWS services and features. If a superwerker feature becomes obsolete because AWS releases it as a service or feature itself, we will adapt superwerker.
Some of the infrastructure that superwerker sets up carries out changes to existing set-ups, for example Control Tower and Service Control Policies, which restrict services and regions. For this reason, we cannot rule out the possibility of impacting existing workloads. We will be happy to help you when evaluating this issue.
They are only used for the RootMail feature. These values have no relevance for the domains of your final applications and workloads.
In most cases the domain will be example.com and the subdomain aws.
You must have the possibility to add an NS entry for aws.example.com in your domain registrar console, otherwise the superwerker installation will not succeed.
At the moment, those are notifications about new OpsItems. Those OpsItems are created from the RootMail feature. So these notifications are about new created AWS accounts or requested password resets.
As soon as AWS releases a feature/service which makes parts of superwerker obsolete, we will adopt. In an ideal world this project would not have to exist.
- use native AWS services when possible
- use functionless / managed runtimes when possible
- whenever the cost of a service or option (e.g. logging to S3 as opposed to logging to CloudWatch Logs) is negligible it will be added without opt-out
Preferred services: CloudFormation, Systems Manager, Parameter Store, Lambda, CodePipeline / Build
All features need to have tests. We prefer integration tests which tests the correct end state. This usually results in the use of real AWS APIs for tests and no mocks.
All code has to be idempotent so we ensure that tasks can be re-run without breaking and without changing the result. All code has to be convergent so we ensure that tasks which have been interrupted formerly can re-run and converge to the final state.
We use CloudWatch Events where possible in order to decouple architecture. We acknowledge this decision makes end-to-end testing harder sometimes.