Cloud & Infrastructure · Sensei

The Backend You Did Not Write and Still Have to Run

AWS Amplify, read as what it actually is: a code generator bolted to a deployment pipeline.

Technical poster: Amplify declares a model, generates CloudFormation, provisions AppSync, DynamoDB, Cognito, S3 and CloudFront.

Declaration → generated template → ordinary AWS resources, with your name on them.

Core Concept

Amplify is not one service, and there is no Amplify runtime hiding underneath. It is a code generator plus a deployment pipeline sitting over ordinary AWS parts.

You declare what you want — a data model, authentication, a hosted front end — and it provisions the real underlying resources, all described as CloudFormation. The generated client library then talks to those endpoints. The pipeline is doing what a platform team would otherwise do by hand.

Which means the output is standard infrastructure you now own and operate. You did not write that backend. You still have to run it.

What Actually Gets Provisioned

AppSync + DynamoDB

Data

A GraphQL interface sitting in front of DynamoDB tables. Priced per request — and the generator, not you, picks the table keys.

Cognito User Pool

Identity

The auth you declared becomes a real user pool. Priced per user, which is a very different curve from per request.

S3 + CloudFront

Storage & Delivery

S3 buckets for uploads, CloudFront in front of the static assets of your hosted front end.

CloudFormation

The Receipt

Every one of the above is described as a CloudFormation stack. That template is the honest inventory of what you now own.

How It Works

You declare intentA data model, an auth requirement, a hosted front end. Short, declarative, no infrastructure written by hand.
The generator emits a templateYour declaration is compiled into CloudFormation — the full description of the resources needed to satisfy it.
CloudFormation provisions real AWS partsAppSync over DynamoDB, a Cognito pool, S3, CloudFront. Nothing proprietary appears; these are the same services you would have created yourself.
A client library is generated to matchYour app talks to those endpoints through generated code, which is why it feels like one integrated product rather than five services.
You operate the resultThe pipeline stops after provisioning. Scaling, cost, key design and eventual migration are yours from that moment on.

Where the Abstraction Leaks

The generator chose your DynamoDB keys. An access pattern it did not anticipate becomes a table scan you did not choose — a design decision made on your behalf, billed to you later.
Escape is adoption, not deletion. Because everything is a CloudFormation stack, leaving the tool means taking ownership of resources you did not design.
The bill is the other tell. A per-request GraphQL interface plus per-user identity is cheap at demo scale and behaves very differently at real traffic. Two different pricing shapes, one invoice.

How to falsify it: open the generated CloudFormation template and read what was actually created — before you build anything on top of it.

Where This Shows Up

Hackathon app that survived into production Mobile app with sign-in, shipped by a front-end team Internal tool with no platform team behind it Startup MVP whose bill jumped at first real traffic Any migration off a generated stack

Checkpoint — answer before you move on

If there is no Amplify runtime underneath, what exactly is running your backend after deployment? Name the concrete services, and say who owns them now.
Why can an access pattern the generator did not anticipate turn into a table scan? Think about which decision was made for you, and when it becomes visible.
Why does the cost profile change shape between demo scale and real traffic? Two of the provisioned parts are priced on different units.