Infrastructure as Code on AWS: From Snowflake Servers to Reproducible Stacks — Highlights from “Infrastructure as Code” by Martin Sereinig (Usersnap GmbH)

Why this session matters to engineering teams

Turning infrastructure into code is no longer optional if you run serious workloads on AWS. In “Infrastructure as Code,” Martin Sereinig, CTO at Usersnap GmbH, walks through the journey from single servers to cloud-native, containerized systems — and why Infrastructure as Code (IaC) is the linchpin for building reliable, repeatable, versioned environments. Usersnap operates a self-service SaaS entirely on AWS, and the talk distills what it takes to keep that landscape under control: requirements, tooling (CloudFormation, AWS CDK, Troposphere), and pitfalls — with concrete lessons teams can adopt.

A short history: from single servers to cloud platforms

The early days were all about individual servers: web, database, mail — sometimes separated, but all managed at the machine level. In some contexts this is still fine (e.g., a university WordPress). Yet the drawbacks are well-known:

• Snowflake machines: ad-hoc tweaks accumulate (“can you add this one thing?”), and after a couple of years nobody remembers what’s running.
• Horizontal scaling is hard: cloning three truly identical boxes is tedious if configurations aren’t deterministically captured.
• Implicit knowledge traps: if you don’t know Apache was used instead of Nginx, you don’t even know where to look.

Shell scripts and tools like Ansible mitigated some of this, but the big shift came with two revolutions: cloud computing and containerization.

Revolution 1: Cloud computing as an infrastructure commodity

Cloud computing turned heavyweight infrastructure into off-the-shelf building blocks. Pre-cloud, a load balancer meant a server, Nginx setup, reverse proxies, firewall rules — all manual toil. Today on AWS, you click, choose, and pay. It also unlocked capabilities that were simply out of reach for most teams before — like running a CDN.

The outcome: infrastructure becomes consumable primitives. But complexity moves from machine innards to cloud resources and their relationships.

Revolution 2: Containerization and the “dumb Docker machines”

Containerization transformed the application side. A Rails app generating PNGs once meant managing language versions and native libraries on a host. Today the application ships with a Dockerfile that encapsulates all system dependencies. Ops no longer curates those libraries on servers; developers define them in the image build.

• No more snowflake machines: runtime nodes are “dumb Docker machines.”
• Explicit knowledge: the Dockerfile records infra needs of the app.
• Scaling: replicating containers is trivial — the challenge shifts to how cloud services fit together.

Same problems, new layer: snowflake infrastructure

The server-level snowflake is now an AWS-level snowflake: ad-hoc clicks in the console — a load balancer here, a Route 53 record there — pile up over years. Without documentation, you inherit an opaque setup. Regions amplify confusion: open the EC2 dashboard in the wrong region and your instances “disappear.” Reproducing the same stack for staging becomes painful without a faithful description of the entire system.

The remedy is to apply the same discipline that containers brought to apps — now for infrastructure.

What modern infrastructure tooling must deliver

Sereinig lays out crisp criteria for IaC tools:

• Compatible with cloud provider APIs: yesterday’s bash setup scripts are obsolete; IaC should talk to the provider directly.
• Declarative, not imperative: specify “what,” not “how.” You want to say, “I want a CDN,” not encode step-by-step instructions.
• Idempotent: applying the definition multiple times yields the same state.
• Customizable: parameters let you adapt details (e.g., a different domain for staging).
• Non-black-box result: the output should be normal provider resources you can inspect and manage — not opaque artifacts.
• Drift detection and handling: when actual state diverges from desired state, you need to know and reconcile.
• Versionable: infrastructure changes should live in version control with meaningful commit history.

These are the Dockerfile virtues, transposed to infrastructure: machine-readable, repeatable, auditable.

Tools in scope: multi-cloud to AWS-native

Sereinig references three approaches:

• Multi-provider tools: “Terraform, NCP Chef” — a good call for consultancies or agencies serving multiple clouds without re-learning per platform.
• AWS CloudFormation: Usersnap’s choice — large YAML templates describing the entire infrastructure.
• AWS Cloud Development Kit (CDK): a TypeScript DSL that synthesizes CloudFormation templates — essentially “a front end to CloudFormation.”

Why Usersnap chose CloudFormation

• Product company posture: Usersnap can go “all in on AWS,” with no need to switch providers. Native tooling fits.
• Timing: their platform predates the CDK. If rebuilt today, Sereinig would choose CDK.

Minimum viable CloudFormation template — as a mental model

The minimal useful template has three parts:

1. Description: human-readable metadata (e.g., “hello world”).
2. Parameters: values you enter via the AWS console when applying the template — the mechanism for customization (e.g., domains for staging).
3. Resources: declarative definitions (e.g., a VPC with specific properties).

Key points: resources reference parameters (“Ref”); stack-provided values are also available. Crucially, you declare the desired state, not the execution steps.

Real-world scale at Usersnap: multiple stacks, many resources

Numbers from the talk paint the production reality:

• Multiple stacks (e.g., distinct environments)
• 69 parameters
• 85 resources
• Around 2,000 lines of YAML

That’s maintainable with the right tooling, but “hard to maintain” by hand, as Sereinig notes — a strong argument for generating templates instead of editing monolithic YAML freehand.

How CloudFormation rolls out changes: from template to preview

Within the AWS console, you apply a template to an existing stack:

• Either reuse the current template (tweak parameters) or replace it (when adding resources).
• Then you adjust parameters — in their production stack, a sizable list.
• CloudFormation shows a preview of all changes before anything happens. This changeset view anchors safe operations.

A standout feature is CloudFormation’s automatic understanding of dependencies among resources. Sereinig’s example: updating an Elasticsearch domain triggers a Beanstalk environment update, which in turn updates Route 53 records — no custom orchestration required.

Finally, you hit the “big scary button,” and CloudFormation executes. In practice, it “usually does” work out — the preview and dependency handling make the process predictable.

What teams gain

Sereinig highlights the operational benefits his team sees:

• No more snowflakes: neither machines nor infrastructure are one-off mysteries — the CloudFormation template, the Dockerfile, and parameters tell the full story.
• Easy replication: spinning up a new staging environment is straightforward when everything is declarative.
• Pricing: CloudFormation is free; you pay only for underlying AWS resources.

Lessons learned: field notes we’ll apply

These are the most actionable takeaways from Martin Sereinig’s session:

1) Use tooling to generate templates

Editing a 2,000-line YAML by hand invites errors. Usersnap uses Troposphere (because CDK didn’t exist when they started). If doing it today, Sereinig would pick AWS CDK. The message: generate CloudFormation rather than hand-crafting it.

2) Maintain a real staging environment

For infrastructure changes in particular, you “really” want a staging environment to test before touching customer traffic. CloudFormation makes staging vs. production parity feasible, while parameters let you vary specifics like domains.

3) Manual changes are fine sometimes — backed by drift detection

Not every tweak must be automated. You might perform a database version update manually in production and capture the change later in the template. CloudFormation’s drift detection will notice the state already matches your target and won’t attempt a conflicting change.

4) Beware of “Replacement” — it can wipe data

A seemingly innocent change can force a resource replacement. When you see “replacement conditional,” it means an update might discard the old resource — and its data. CloudFormation also deletes the automated backups in such cases. If you miss this signal, you can end up with a “really, really bad day.”

5) Protect critical resources with stack policies

Stack policies let you block deletion or replacement of important resources. Sereinig recommends enabling them to guard against catastrophic mistakes.

Practical waypoints for teams

From an editorial standpoint, here’s how to operationalize the talk’s guidance:

• Parameterize, don’t hardcode: domains, region-specific values, environment names — make them parameters.
• Leverage dependency resolution: trust CloudFormation to order operations correctly; the changeset preview shows the cascade.
• Be region-aware: the AWS console only shows resources for the current region; being in the “wrong” region makes things appear missing.
• Use multiple stacks: split environments across distinct stacks to keep changesets focused and deploys safer.
• Treat infra as code: version control everything and justify changes through commit messages.

These are not abstract best practices; they directly reflect how Sereinig operates in production.

Framing the tool choices from the talk

• Multi-provider tooling (“Terraform, NCP Chef”): well-suited to agencies or teams spanning multiple clouds.
• CloudFormation: a strong default for AWS-only product teams who want first-party primitives.
• AWS CDK: the ergonomic, modern way to author CloudFormation templates today; in Sereinig’s words, they’d pick it if starting now.

More important than the logo is adherence to the core properties: declarative definitions, idempotency, drift detection, versioning, and protective controls.

A mental model: from Dockerfile to stack definition

Sereinig’s parallel is compelling:

• The Dockerfile enumerates everything the app needs at the system level — explicit and reproducible.
• The CloudFormation template enumerates everything the infrastructure should provide — explicit and reproducible.

Together, they reduce implicit knowledge and form a complete, testable spec for running software in the cloud.

Conclusion: IaC as the operating system of your cloud

“Infrastructure as Code” by Martin Sereinig (Usersnap GmbH) is a clear call to treat infrastructure with the same rigor as software. The core messages:

• Cloud computing and containers changed the game — and shifted old problems from servers to platforms.
• IaC brings order: declarative, idempotent, parameterized, drift-aware, and version-controlled.
• CloudFormation (and today, likely CDK as its authoring layer) works in real production — even with dozens of resources and extensive parameter sets — provided you invest in tooling, staging, and guardrails.

Apply these principles, and you’ll replace click-driven archaeology with reproducible, reviewable states. That’s exactly what modern engineering needs in AWS, where one “big scary button” can update a web of resources — and where preparation is the difference between a smooth rollout and a very bad day.

• 

  

  Martin Sereinig, CTO von usersnap

  Der CTO von Usersnap Martin Sereinig spricht im Interview darüber, wie die Devs im Unternehmen die Teamorganisation und das Recruiting gestalten – und was man mit zwei Pizzas machen kann.

  Watch now