Folks who are familiar with CONTAX will know how big of fans we are of AWS. We're an AWS Advanced Consulting partner and solutions provider, but we also practice what we preach. CONTAX has been running our internal SAP workloads on AWS for nearly a decade. When AWS was still in its infancy, Scott, our VP of Innovation and Quality, signed up for an account in order to kick the tires on what he viewed as new and exciting technology. We've been using AWS ever since.

Since those early days, we have built up our AWS consulting practice. We are now one of the top Canadian names when it comes to architecting, implementing, migrating and optimizing SAP workloads on AWS. We've learned a lot and grown our understanding of how cloud-hosted SAP landscapes should be designed.

If Scott had known back when we set up our first AWS account what we know now, he'd have approached it differently. It is sometimes said that an architect has the worst maintained house on the block, well, sometimes the same can be said about an AWS solution architect. It's always easier to spend time improving your clients' systems than it is to work on internal IT projects just like the architect's bathroom remod at home can always wait when they have an exciting customer project to sink their teeth into!

This year CONTAX will finally dedicate the resources to overhauling our internal AWS account structure. We are making ourselves a client. As we do with our clients, we have decided to review our cloud infrastructure. AWS provides a rubric to review your AWS landscape alone, or with the assistance of a partner or the AWS team. The rubric is called the Well Architected Framework Well Architected Review (WAR). It asks a series of leading questions and helps you identify potential improvement opportunities. So we took a look.

The main decision that we made was to address the low hanging fruit that we have been eyeing for years. We will unravel the workloads from our monolithic core AWS account into a series of purpose-focused accounts for our individual lines of business and administer them using AWS Organizations. This will bring us in line with AWS's best practice recommendations that they outline in the Well Architected Framework. It will allow us to more easily manage security and access centrally while making the tracking and allocation of costs a much more straightforward process.

To give ourselves a bit of credit, when we leapt into AWS with both feet, AWS had not yet released their Organizations solution. AWS Organizations makes creating, grouping and administering AWS accounts a straightforward task. While it's possible to view that as a downside of us having been an early adopter, we don't see it that way. AWS Organizations having been released in 2017 is illustrative of the very reason we were eager to use AWS and will continue to host our resources with them. AWS has heard the feedback from its customers and released Organizations to fit the need that we have had, and we have been using it to manage some of our accounts since it launched. As the years have gone on, AWS's offerings have become more robust and feature rich. That has allowed us to pick and choose the services that can help us work more efficiently.

Our migration approach will be simple and methodical. The team will quickly create the additional Organization accounts for our internal business units, and begin migrating workloads. Demo environments, training environments, software development and consolidation instances, they're all going to be moved. Each into its correct account. We won't be the architect with the bad house for much longer.