Hey! Welcome back. It's Unlimited Leave. The mostly weekly newsletter that reminds you if only you knew then what you know now, your AWS architecture would be way different. By different, we all know that means better. But don't fret.

First, it's not your fault. AWS is great at releasing new services or service features at the most inopportune time. If we could turn back time... amirite?

Second, we're in this together. It's not too late to make some changes.

That's why I'll still run this poll for a couple more weeks. If you haven't responded yet please do.

I'm fine with whichever way the results land, but the outcome may change a few things about the newsletter itself.

This week's topics

The calm before the storm. It was a pretty quiet week from AWS in the land of governance and compliance. More on that further down. Let's dig in.

• Monitor & remediate resources from a single account

• re:Invent Sessions worth favoriting

• The Case for Multi-Org (continued)

• Predictions for re:Invent

Monitor & remediate resources issue from a single account

Oh, look. Another service is delegated to a "central account."

Do you need to investigate an instance not responding or review recent changes without bouncing around 2-dozen AWS accounts?

OpsCenter delegation of OpsItems is your answer. 

The key feature here...

Think lower-tier support teams responding to canned issues via pre-deployed runbooks in all accounts.

Need to quickly respond to an incident and expand an EBS volume size on an EC2 for a critical workload?

Your Tier 1 can now do that without needing access to the production account. Just have the pre-defined runbook in place and no more after-hours calls to the product development team that has access to the account.

re:Invent Sessions worth favoriting

My session calendar that the moment is a complete mess. As I wrote in a previous issue, my focus at re:Invent this year is going to be deep dives and connecting with individuals in the management and governance space. Both at AWS as well as private companies.

The following sessions are the ones I'm going to be paying attention to. Rather I make it to any sessions other than workshops and chalk talks, these I will be giving an extra look at in the following weeks via YouTube.

Monday

• COP306: Cloud compliance and auditing best practices on AWS

• DOP314: Governance and security with infrastructure as code

• ARC205: Establishing your cloud foundation on AWS—beyond your landing zone

Tuesday

• DOP402-R: Implementing DevSecOps pipelines with compliance in mind

• DOP201: AWS infrastructure as code: A year in review

• DOP404-R: Proactive security and compliance for infrastructure-as-code resources

Wednesday

• WPS308-R: Use AWS GovCloud (US) to create resilient multi-Region architectures

• DOP302: How to reuse patterns when developing infrastructure as code

• COP311: Simplify and automate continuous compliance with AWS

Thursday

• SUP311: Design with operations in mind

• COP204: Proactive governance and compliance for AWS workloads

• SUP308: Optimize your AWS workloads with best-practice guidance

• COP313: Goldman Sachs: Using policy as code to deploy new applications in minutes

*Don't plan on looking for me at any of these. Lots of factors are at play. Not to mention some of them are all the way at the other end of the strip with 10 minutes in between.

If you'd maybe like to link up for a chat sometime during the week, you can message me in the AWS re:Invent 2022 Slack.

The Case for Multi-Org (continued)

I'm still polishing up the full post to share in next weeks Issue.

As the poll has stated so far, most of you are looking to get long-form explanatory articles with walk-throughs and/or videos. This might change the dynamic of the newsletter a little bit.

Pending the final results of the poll but maybe it will look more like every other week releasing an issue like this with a deep dive post in between weeks.

Anyway, here are some thoughts to bake your noodle over the weekend.

My reasons for using multiple AWS Organizations can be broken down into the following buckets:

Access Control

• You really should have an account just for accessing other accounts. In a multi-org model, your first order of business is an Identity Center (break glass in case of emergency) configuration for assuming into all other accounts across all other organizations. This is a lot simpler than it sounds.

• Inadvertent access assignments related to the complexities of Identity Center Permission Sets and Groups

• More easily restrict access to AWS services and/or regions

Product, Service, or Department Segmentation

• Business units within your company operate differently or have different teams

• Think product or business unit acquisition

• Abandonment of an entire product or service altogether

• Reduce global configuration blast radius

Compliance

• More reliable view of compliance status

• Increased discoverability of critical vulnerabilities

• Segment off data access and compliance restrictions

Billing & Cost Allocation

• dedicated billing

• inherited cost allocation

• easy abandonment of rogue resources

• enablement of faster and more careless R&D

Enablement

The driving factor behind all of these options is enablement.

How can you get the biggest bang for your buck from a management standpoint where you don't have to constantly be correcting mismanaged or mistagged resources?

What is the least common denominator where a set of accounts belong together?

Where can I reduce risk and increase autonomy by letting the platform do my job for me?

Predictions for re:Invent

I've been working on a list of predictions to re:Invent. 

It's fun every year to see all the announcements and releases leading up to the week of the conference.

Even more fun is looking back and seeing how everything over the last year built up to the announcements for the week-long event.

I've collected some thoughts on the following:

• Managing and customization of Accounts at and after deployment

• More service Administration Delegation and functionality of delegated services

• Automated deployment

Stay tuned for next week's issue as I more deeply describe my predictions. 

Help us grow

You can't go back in time to warn yourself, but maybe you can stop someone else from making the same mistakes you did.

Forward them this email or tell them to subscribe 👇

Review past issues HERE

Disclaimer: The resources and topics shared within this newsletter are for informational use only. Any resources deployed or tools implemented are done so at your own risk. Do your own research and testing prior to the implementation of any resource or service deployed for any workload.