Ten lessons from twelve years of AWS
#10 — Learn from others.

Learning from others is the single most important thing I have learned. And I have to admit, sometimes I still have to remind myself to shut up and listen.

There is always someone in the room that knows more than you do. That person is just not necessarily broadcasting it.

Be open and ready to be challenged and change opinion.

Share your ideas with others, challenge them and especially let others do so.

Fortunately, there are myriads ways to do this — participating in this community is, of course, one of them.

A few weeks ago, while preparing for this talk, I asked the developer advocate team to share with me their lessons — and few of them kindly answered.

But as I didn’t really know what I was going to talk about a few weeks ago, I asked my question with a heavy bias towards getting technical answers — so despite my first lesson not to focus on technology, the following is mainly about technology — but I am the one to blame for that :)

Javier Ramirez:

Don’t use the AWS as a traditional Data Center. Have a consistent naming/tagging strategy early on. Especially for everything that has unique names (s3 buckets, for example).

Alex Casalboni:

Learn IAM before you do anything serious. Master Infrastructure as Code (IaC), either CloudFormation or Terraform. Use the management console only to build prototypes, or the first time you try out a new service, switch to IaC for anything else.

Boaz Ziniman:

Account security — don’t use the root account. Always enable MFA. Set IAM users for every developer, with different roles. Tag everything!

Enrique Duvos:

Security, Security, Security.

Dennis Traub:

Turn on CloudTrail. Turn on Guard Duty. Don’t assume that development teams will consider security when building on AWS. So, I’m with Enrique here —think security.

Marcia Villalba:

Try to see if there is a managed service before building it yourself.

Danilo Poccia:

Adopt the right mindset: With on-prem virtualization and hosting, you have a finite set of resources where you try to squeeze as many things as possible. With the cloud, you have access to a virtually unlimited set of resources, and you should use the minimum you need at any point in time.

Sebastien Stormacq:

Use EC2 only if you have exhausted all other possibilities. This is not because of EC2, but because no machine to manage is better than one machine to manage. So, go serverless as much as possible. And serverless is not only Lambda, but it is also RDS, Cognito, S3, API Gateway, etc.

Ricardo Sueiras:

Shift the conversation around AWS from technology to business outcomes (Agility, etc.). It will help you get the exec sponsor/support required for success. From a technical point of view, bet on automation. Resist being obsessed with the console.

Isabel Huerga Ayza:

Governance — everything that is not clearly defined will be done by no one. Or best case it will be, but not consistently. Goes to accountability and ownership, which is not good to leave to good faith when what is at risk is your business. Don’t wait until a production disruption to enable support. Setup budget alerts!

Steven Bryen:

My advice is to think differently about things like the dynamic allocation of resources. An example would be security groups. You can create a rule referencing another security group, which means new instances automatically match the rule and have access as they scale. It is very different from the traditional on-prem mindset but is so valuable.

Cobus Bernard:

Read the pricing page for a service and set up billing alerts.
['Adrian Hornsby']
['Technology', 'Community', 'AWS', 'Lessons Learned', 'Keynote']