Thread by @aeduhm

I built a startup on AWS and have advised dozens of startups doing the same.

This is a practical thread with advice I wish I'd been given early in my startup journey.

"😩 But, MVP and market fit and AWS-is-too-complex-for-early-stage-startups and you-should-Heroku and..."

Yeah, this thread isn't for you. 😅

This thread is aimed at folks who are already convinced that building on AWS is best for their startup.

1. Leverage infrastructure-as-code (IaC)

You should define all of your AWS infrastructure with some form of IaC.

There are myriad benefits covered in countless articles on the web, and I won't rehash those here.

Aside from the primary value prop of IaC, there's a supremely practical benefit:

It's much more productive. And I don't need to tell you that startups need to be productive.

Building out your infra in the AWS console is painful (and slow).

That's not necessarily an indictment on AWS and their console team(s). The console serves a purpose, and serves it (mostly) well.

The main issue with the console is that you're navigating around to pages that are focused on a single service, for the most part.

If you're building anything worth building, you're going to be tying multiple services together.

That's much easier to do with IaC.

There are exceptions to this "single service" paradigm in the console, and I know we'll continue to see progress made to support common use cases and related services.

But, you're still going to be better off building with IaC.

There are so many IaC options today.

1st Party (AWS):
• CloudFormation (JSON, YAML)
• CDK (TypeScript, Python, Java, C#, Go)
• SAM (JSON, YAML)

3rd Party:
• Terraform (@HashiCorp)
• Pulumi (@PulumiCorp)
• Serverless (@goserverless)
• Architect (arc.codes)

If your team already has experience with an IaC solution, that's probably your best bet.

Otherwise, I prefer (and recommend) the first party options.

2. Segregate your workloads into multiple accounts

Once you have your infra defined in IaC, you should be able to quickly stand up new environments for dev/test/stage/prod/etc. 🐄

Put these environments into separate AWS accounts.

It's far too easy to inadvertently modify production resources when you're slinging everything into a single AWS account.

There is some overhead involved with managing multiple AWS accounts, but it's worth the trouble.

In fact, the "trouble" is a feature, not a bug.

To ease the administrative burden, setup an AWS Organization and add new accounts through the Organizations console.

You'll need a unique email address for each account; I typically follow a pattern like:

aws@... (root account)
aws+prod@... (prod)
aws+test@... (test)
etc.

Root account should be free from any application resources.

You'll manage billing here (configure consolidated billing on the child accounts), and maybe DNS (Route53) depending on your setup.

You should also setup AWS SSO in the root account; it's super helpful for managing your team's access to the various child accounts.

Your team members will thank you.

3. Setup CI/CD

Every startup wants to continuously deliver value to its customers, but CI/CD can be quite complex (and daunting).

AWS has an excellent suite of services for managing this complexity, highlighted by CodeBuild and CodePipeline.

GitHub Actions are another option.

Before you invest in either of these solutions, be sure you're writing automated tests that give you the confidence to ship frequent changes.

There's no shortcut here.

If you're defining your infra with the CDK, CDK Pipelines allow you to define your CI/CD pipeline alongside your CDK infra stack(s).

It's still in developer preview, but I've been using it a ton and love it.

docs.aws.amazon.com/cdk/api/latest…

4. Use "cloud-native" services

This is admittedly much easier in the early stages of building, but you'll gain a lot when building with "cloud-native" services.

"how can we use AWS/GCP in ways that we couldn't possibly do better ourselves? This is called 'servicefull' architecture – using your provider's cloud-native services to replace server code." @zachkanter

Full thread that covers this and more in-depth:

https://twitter.com/zackkanter/status/1399013516107948037?s=20

Another gem from that thread:

"If you're using AWS/GCP to run vanilla servers, you're building software to work the same way it did when companies ran servers in their office 15 yrs ago. That should be a wake up call about your technology choices..."

This might require learning new skills and practices—it's an entirely different way of architecting and building your application—but, for those that make the plunge, there are huge advantages.

"😩 something something, vendor lock-in!"

https://twitter.com/mjasay/status/1399737989538869249?s=20

It's (lock-in) also not a Thing™.

https://twitter.com/brianleroux/status/1399739598796845056?s=20

5. Get help

AWS expertise *is* a Thing™, and there's no shame in seeking outside help as you navigate its complexities.

AWS IQ is a service that allows AWS customers to hire third-party experts for any number of projects.

iq.aws.amazon.com