Covered in this first ever edition of AWS at Scale

• Introduction

• More about me.

• What i’ll be posting to your inbox.

• What does AWS at scale mean?

• Wrapping it Up

Reading time: 3 Minutes 🚀

This post is part of a series

Part 1: What does AWS at Scale even mean?

The article you are reading.

Part 2: Backing from the Board

Introduction

Howdy 🙌 this is my first ever post on AWS at Scale.

I’m starting AWS at Scale to share strategies, skills and tips on how to build your AWS career, what to focus on to stay relevant, how to make an impact, and where to focus your time & energy in a large corporate enterprise.

I’m Lee and I’ve spent my entire career working at scale in some of the world’s largest corporations.

I’ll be your host, or your coach (if that’s a cool thing to say these days). I currently work for Informa PLC where we connect fellow humans through intelligence, academic publishing, knowledge and events. It’s a great place to work and we’re all in on AWS, we have no data centres, and for a enterprise that’s north of $3b, that’s some achievement! 🌟

More about me.

Here’s my professional bio if you want to learn more about what I do within my role at Informa as an senior architect - my primary focus being AWS and cloud (at scale).

Informa is where I get to design stuff like this (more on how we built this in future posts):

I also try my best to be funny (it doesn’t always work):

What i’ll be posting to your inbox.

This will be the first post of many on AWS at Scale, all of which aim to cover the following topics as part of series of posts that aim to be enablers to establishing yourself as an AWS professional who can design and advise on adopting AWS / cloud at Scale within a large corporate enterprise.

In future posts I aim to cover:

• Is there backing from the board? Why it’s important, and how to check for it.

• Finding the mechanism for change.

• Building and engaging with your stakeholders.

• Defining and aligning your standards.

• Aligning your standards with enterprise level principles.

• Your primary cloud vs other clouds (how to manage strategy and adoption).

• Defining and building your communication strategy.

• Building a provider / consumer model.

  • Reusable Infrastructure as Code modules.

  • Reusable CI/CD pipelines.

  • Reusable design patterns and reference architectures.

• Designing the core foundations, landing zone & control plane.

  • An SDLC mindset

    • At core landing zone level

      • Dev LZ

      • Consumer LZs

    • At AWS account level

      • Dev, Test & Prod

      • Standalone

      • Sandbox

  • Segregation

    • At account level (dev, stage production)

    • Throughout the core network

      • East west inspection VPCs

      • Centralised egress inspection VPCs

    • Removing VPC peering

• Implementing a privileged access model (PAM) for:

  • Request & approval for time bound AWS console/cli based access.

  • Identifying roles for:

    • Break fix

    • View Only

    • Read Only

    • Session Manager

    • Secrets Manager

  • Building a multi stage approval MFA based process for root IAM account access.

  • Removing local IAM accounts

• Designing reference VPC architecture for automated vending, standardisation and reusability.

  • Industrialised for management at scale.

  • Fit for the future of microservices and serverless

• Defining tiering (and ultimately designing for it).

  • Uptime, RTO & RPO objectives.

• Defining a mandatory tagging taxonomy from sources of truth.

• FinOps

  • Discovering and setting estimated AWS account level budgets during the engagement process.

  • Automated AWS account spend dashboards and identifying trends.

  • Visualising and approving budget changes when commits are made to the infrastructure as code pipeline / repo.

  • Automated enrolment of AWS accounts into an AWS Private Marketplace.

  • Implementing an AWS Private Marketplace request and approval process.

  • Ensuring all non prod compute runs on spot.

  • Ensuring all non prod storage is tiered as required.

• Identifying early adopters.

• Build the advocates.

• Defining an architectural engagement process.

  • Data gathering for.

    • Requirements.

      • Non function.

      • Functional.

      • Vending

    • Outputs

      • Early stakeholders comms.

      • Schematics.

      • Enablement guides.

  • Why it’s important to be

    • Opinionated.

    • Decisive.

    • Confident.

  • How to reduce the amount of snowflakes by building cattle and not pets.

    • Microservices and Serverless by default.

    • EC2 by exception.

    • Implement cattle not pets.

• Changing behaviour and ways of working.

  • Stop perceiving AWS as a data centre.

  • Building an ‘everything as code’ approach.

  • Driving changes through the CI/CD pipeline (and not the console).

• Tips on getting hired as an AWS professional within a large corporate enterprise.

  • Interview techniques.

  • Dos and Don’ts.

  • What the hiring manager is looking for.

  • Tools and preparation.

I’ll also be publishing animations and other visuals that will help you understand important AWS / cloud concepts.

If any of this future content interests you then you’re going to want to hit that subscribe button.

What does AWS at scale mean?

Or more specifically, what does AWS at Scale mean to me?

For me ‘AWS at Scale’ means consistent governance, compliance, FinOps practices and common developer and DevOps experiences are delivered through automation and vending. It means the ability to provide this as a service to your project/workload/builder teams through an architectural engagement and ITSM process that provides cover for all the thing your community of builders maybe haven’t considered as it’s not part of their overall domain of responsibility.

Your consumers may not see the bigger picture at play. They just need to focus on building.

AWS at Scale is also about bootstrapping your community of builders. At the point of which AWS accounts, VPCs (if required) along with automated governance and compliance are vended, you’re also vending a CI/CD pipeline and Infrastructure as Code modules out of the box,

This gets developers and DevOps teams building within minutes, and provides a consistent DevOps experience from product to product.

Wrapping it Up

As if you don’t know already, AWS is an awesome community to be involved in, it’s also a primary skillset that is high in demand, it opens doors to all sorts of opportunities, interesting challenges and lifestyle benefits.

In a large corporate enterprise you’ll get to travel, enjoy really nerdy conferences (especially AWS re:Invent) meet like minded people from all over the globe, help others, share knowledge and continuously grow.

There’s a never ending supply of new things to learn to feed your curious nerdy mind. You’ll never stop learning. You’ll earn a good salary (and in some cases a very good salary) and the skills you’ll learn are beyond portable, every business is consuming AWS either directly, or indirectly, like EVERYONE.

Repeat after me…

It’s ubiquitous, like photons 💡 and yes it can be a steep learning curve, but the juice 🍊 is worth the squeeze 🥤, and anyway - you’ll learn from someone that isn’t just reading and learning from documentation and labs, I’ve spent my entire career working at scale in some of the world’s largest corporations.

If you’re already on your AWS journey, it’s time to level up.

Many thanks for reading and i’ll be posting again soo, Lee ✌️