My AWS Rocks!

There is always a huge debate on which certificates and skills are required for which role, or which certification someone should do next. So I thought I'd pitch in with my view on the matter. Please note the following is based on planning at the beginning of your cloud career. If you are changing roles later in your career the order and certifications could change drastically. For me there are three categories of AWS roles; Architect, Engineer and Specialist. Bear in mind roles will always have overlaps and depending on the company there will be nuances. In addition, as you move up from an entry level role to a lead role it is normally expected that your depth in knowledge increases.

In this post we will look at the basics of CloudFormation, what you need to know and how to get started in writing templates. So you may be asking why I am writing a post about template basics when I have said I'll try not repeat information available on AWS. Two reasons. Primarily to demystify the template and secondly to provide pointers to resources you might find useful as you improve your CloudFormation knowledge.

Following on from the foundational architecture post I thought I'd give a dive into security of the AWS cloud. For me this is the most important element to understand before even creating an AWS account as if you get this wrong it can be costly in more ways than one. There are a few items that need to be looked at when considering security. These include, but are not limited to:

This is the final part in a three part series on the AWS Well-Architected Framework. It is based on my presentation at the AWS Thames Valley user group "How to design well when there is no rule book". In this part we will look at how to use the Well-Architected Framework and also some resources to help you further understand the framework and review process. Firstly I think we should look at how not to use the framework and review as often I see people getting dishearten or resenting the review because it is used in the wrong way.

This is the second in a three part series on the AWS Well-Architected Framework. It is based on my presentation at the AWS Thames Valley user group "How to design well when there is no rule book". In the first part of this series I looked at what the Well-Architected Framework is. In this part we will look at why you should use the Well-Architected Framework. I split the what of the framework into 3 categories; Cloud Roadmap, Design Principle; Cloud Assessment. For the reasons as to why use the framework I am also splitting it into 3 area; Promote discussion, Plan for Progress, and AWS best practices.