👋 I'm Ross Wickman.

A "Certified" Cloud Architect, Site Reliability Engineer, and AWS Community Builder responsible for deploying and managing multiple AWS Organizations.

I've spent the last 6+ years working in AWS and the only Workloads, Applications, or Services I've really built are my own half-assed ideas. Prior to being paid to work in AWS, I was building my 'next big thing' in Azure with Web Services, Blobs, and MSSQL DBs.

Every role I've taken relative to AWS has revolved primarily around infrastructure management, security, compliance, and the enablement of engineering teams to do the work they were hired to do. This frees them from worrying about complying with security frameworks (NIST, FedRAMP, CIS, etc.), access issues, automation, and account sprawl.

Please don't get the wrong idea. I've managed plenty of applications and workloads such as:

• deploying ECR images to ECS (Fargate) with EFS and RDS backends

• configure and link up EC2s -> TGs/ASGs -> ALBs -> CloudFront/WAF -> Route53

• manage Transit Gateway and Shared or Peered VPCs

• configured SFTP, Storage Gateway, Directory Services, and more

I surely haven't done it all, but I've done enough to know what management and governance need to look like to support the majority of workloads. I've deployed, monitored, maintained, STIG'd, and DR'd some of the most highly trafficked public-facing websites in the DOD.

About this Newsletter

In this newsletter, I plan to provide and share no-bullshit solutions for helping AWS Architects manage their environments. As a subscriber, you will get a look into how I have deployed and maintained AWS Accounts & Organizations for Federal customers such as the Department of Defense (DOD) and the Department of Interior (DOI) as well as lessons learned from deploying baselined and templated AWS Organizations as a Managed Service Provider (MSP) AWS Partner.

What this newsletter is not

One of my biggest pet peeves is architects taking AWS service or feature announcement blogs, completing the step-by-step tutorial, re-writing the same post, pasting a couple of screenshots, and dropping it on https://dev.to.

I'm part of a few communities online where that is the majority of content being peddled about. This newsletter isn't going to be that. If it becomes that, please call me out.

What this newsletter will be

A unique perspective and sometimes edge-case deployment solutions. If you wanted to deploy a solution just as it is written for the lowest common denominator, you wouldn't be looking any further than the AWS Service announcements and documentation.

My hope is for this to be a weekly newsletter to help support technical managers and AWS Architects alike design and build for large-scale AWS infrastructures. This newsletter is a trusted source for sharing solutions around AWS governance, access, and compliance that can scale through automation.

The goal is to provide autonomy and latitude to development teams or individual engineers to do the work they were hired to do without worrying about all the other details of maintaining cloud infrastructure.

We’re going to build cloud architectures that don’t suck the life out of you and allow you to actually take some Unlimited Leave.

Moving forward together

This is my first attempt at a newsletter with purpose and a large community being supported by it. Your feedback and patronage are very much appreciated. Please send any criticism, feedback, or frustrations to [email protected].

Let me know what you would (or would not) like to see in this newsletter to better support you and your teams. If I misrepresent something, if you have a different or better way of doing something, please do not hesitate to inform me. We’re all learning this stuff together.

Finally. In full transparency… I’m human. I have a young family. I’m employed full-time. This newsletter is not my primary purpose in life or source of any income (at the moment). I don’t plan to miss a week, but it is bound to happen.

It’s called Unlimited Leave for a reason.

Post Format

The following is a brief example of what a typical post will be formatted like.

This week's topics

• A few

• Top-level bullets

• about the topics and resources

• being shared in the current issue

• to save you valuable time and effort upfront if you see nothing of value

{ Featured Post or Topic }

This may include a recent post or tutorial that I have written or that I found value in provided by someone else.

{ Announcement(s) }

These will be recent announcements of service releases or service features that I find could use additional review to support compliance, governance, scalability, or automation.

{ Tool or Resource }

May include a free or inexpensive tool or resource that can help you in your cloud governance journey. This might include items like:

• VSCode Extensions

• 3rd Party Applications

• Git Lab/Hub code repositories

• CloudFormation and/or Terraform Templates

• potentially sponsored content at some point

• etc.

{ Pain Point(s) }

A frustrating item, bug, neglected feature or service functionality that I or someone else has recently come across.

{ Upcoming Post }

A small blurb and detail about an upcoming post I am either considering or activity working on. A reply to the weeks issue is an opportunity to contribute or request specific information be included in the post

{ Recurring or Ongoing }

Any follow-up information or details related to an ongoing post or topic.

{ An Obligatory Disclaimer }

And finally, a reminder to you that using any of these tips, resources, solutions, and processes is done at your own risk and to never deploy anything into a production environment without first testing and vetting through your Infosec team.