The Biggest AWS Mistakes to Avoid

Jason McKay, CTO, Logicworks

678

1136

237

Join CIOReview Contributor Network

Jason McKay, CTO, Logicworks

It is no secret that managing enterprise AWS systems is complex. With hundreds of services and new process definitions, it is easy to forget important details amidst the urgency of digital transformations.

As adoption of the AWS platform accelerates in the enterprise, best practices are rapidly emerging to help guide IT teams overcome common obstacles. The security, performance, and organizational practices on AWS can help CIOs avoid easy mistakes and focus on developing the important tools and skillsets.

“As adoption of the AWS platform accelerates in the enterprise, best practices are rapidly emerging to help guide IT teams overcome common obstacles”

Here are four common mistakes made by enterprise cloud teams:

Trying to Build a “Perfect Point-in-Time” Custom AWS Environment

Exhaustive planning is ingrained in traditional IT. The end-goal of any procurement project in the old world was a custom, perfect set of machines to support applications that rarely changed. In a world where the goals of agility and customer centricity are transforming application development lifecycles, getting it “right” is not just about meeting today’s needs but making your environment flexible enough to meet future needs.

This is certainly not to suggest that CIOs should not plan ahead. The more planning you can do, the better. The key is to make sure you do not value today’s custom configurations over long-term manageability. CIOs do not need to develop a complex, multi-cloud, microservices-style AWS environment on Day 1. Instead, they should focus on processes that will help them adapt to future needs, like cloud automation and improve the ability of the system to change.

Cloud automation is the set of templates, bootstrapping scripts and workflows that build repeatable cloud resources. As a practical example, automation could be a script that builds an environment that meets your basic security requirements, such as your basic network, IAM and security group configurations.

Over time, your team will build bootstrapping scripts, likely with configuration management tools that customize these templates per environment. The key is that embracing rules-based, automated and repeatable systems is just as valuable as upfront work to get to the cloud.

Overestimating AWS Responsibility and Support

Many CIOs believe that once they migrate to AWS, they will reduce common system engineering tasks and reduce overall maintenance. In fact, this is a very well publicized benefit of the cloud. Unfortunately, most are confusing cloud-based PaaS systems, where the software company takes care of orchestrating and maintaining cloud resources and IaaS platforms like AWS.

If an instance fails at 3:00 am, AWS will not replace it. And also they will not reimburse you for service disruption. AWS provides services like Auto Scaling Groups to help your engineers react to these incidents more quickly and custom infrastructure automation will even enable you to replace this instance without human intervention but AWS will not maintain your cloud.

AWS maintenance takes time and effort. Many enterprises start by handling these types of maintenance requests on their own but find that outsourcing this work to a third-party is both more cost-efficient and delivers higher guaranteed SLAs.

Applying Traditional and Manual Security Practices

Human error is the biggest security threat in the enterprise. This is even truer in AWS, where a single click of a button can expose your environment to unauthorized traffic.

AWS presents enterprises with an opportunity to approach traditional security controls in new ways. The same principles and often the same tools can be used in AWS environments -- WAFs, network controls, encryption, least privilege -- but can now be enforced programmatically.

These tools monitor instances for their adherence to standard configurations, alerting engineers to resources that fail to meet basic security guidelines.

Maintaining Poor Cost Data Feedback Loops Between IT and Business

Companies do not typically develop strategies for ongoing cost optimization before moving to AWS. In order for business to direct IT staff and resources, it needs appropriate data on what teams or projects are spending. IT needs information on where it can cut waste. The ability for both business and IT to manage costs begins with understanding where costs originate and which resources should be allocated to which projects or products.

It is widely acknowledged that AWS bills do not supply the detailed project-specific resource usage information that CIOs need. The most common solution is third party cost tracking and monitoring tools which may provide greater visibility into costs but are not broken down by project, team or budget.

In order for cost monitoring tools to be effective, engineers need to tag AWS resources with meaningful categories. First the team needs to determined about cost allocation needs, then it can set up and automate tagging. You can always add more dimensions later; just remember that tags are not retroactive, so the data associated with those tags will only be available from the day that resources were tagged.

Tagging is the foundation of any well-organized AWS system but it is something engineers rarely do without enforcement. Again, the importance of automation figures are large. If an AWS environment is already built with AWS CloudFormation templates and a configuration management tool, programmatically assigning tags is simple. The finance team can also automate user-specific reporting through the AWS billing portal.

An enterprise IT team’s first weeks and months on AWS is an exciting but often precarious time. As the role of the CIO transitions from IT manager to the chief digital transformation officer, it is crucial that the right focus is placed on cloud automation as the foundation of agility, security, and cost transparency in the cloud. Whether these skills are developed in-house or outsourced, established on Day 1 or Day 600, an investment in IT automation will yield immediate, outcome-defining the results. Any single step along this journey will be worth three steps tomorrow.