Is your AWS Workload Well-Architected? Part 1 of 2

In February 2019, the Dow Jones company received some unfavorable publicity when it was announced that they had inadvertently exposed 2.4 million records of sensitive information about businesses and individuals. The data was stored in a search database that was incorrectly configured and therefore publicly accessible in the Dow Jones cloud in Amazon AWS.

Unfortunately, the mistake Dow Jones made is not uncommon. Many organizations have similarly improper configurations in their AWS cloud infrastructure, with a host of potential security incidents looming. Other common security mistakes organizations make include:

• Access credentials of employees not disabled when access no longer needed.
• Security keys stored unencrypted in application code or on disk.
• Network ports open unnecessarily to the public Internet.
• Insecure protocols used in the transmission of sensitive data.
• Servers improperly placed in public subnets.

Security Matters & More

The reasons behind the security mistakes are often the organization taking shortcuts without fully realizing the security threat potential or the organization simply not completely understanding how to properly architect their infrastructures in the public cloud. The latter reason is understandable given both the newness of the public cloud and the differences between on-premise architectures and cloud architectures. What worked on-premise might not be appropriate in the public cloud.

 

Add to this the fact that AWS is evolving at a furious rate. In 2008, AWS introduced 24 new features to their cloud offering. In 2019, AWS introduced over 1800 new features. The pace of innovation is staggering, and it can be difficult for organizations to keep up with new capabilities in AWS. This is unfortunate since many of the new features are actually designed to help organizations avoid making costly mistakes. In the area of security, AWS Macie and AWS GuardDuty are a couple of recent new services that could help detect potential security threats to a system implemented in AWS.

 

Cloud architecture and implementation missteps made by organizations are not just security related. An organization may be significantly overpaying for their AWS resources by over-provisioning resources beyond necessary capacity. System outages occur (or could potentially occur) due to the architecture not being able to scale quickly enough in response to sudden increases in demand. Application performance may be suffering needlessly due to not taking advantage of appropriate AWS services.

 

You Only Know What You Know

In many cases, organizations are unaware of the lurking problems in their architecture or simply do not know how to appropriately address the issues. Organizations are strapped for time and personnel to keep up with new features. But more critically, designing cloud-native architecture requires adopting new design paradigms and processes.

 

Read how one organization migrated to AWS Cloud Infrastructure

 

Fortunately, AWS has extensive experience in architecting secure, cost-efficient, performant, reliable workloads. AWS solution architects have helped numerous customers improve their workload architectures. Over the years, these solution architects gathered, documented and shared best practices and good design principles critical to ensuring a well-architected workload.

 

The Well-Architected Framework

Those best practices and design principles have been codified into the AWS Well-Architected Framework. The framework provides prescriptive advice on how to build and operate cloud architectures, with 34 design principles and over 200 best practices. The guidance is applicable to cloud architectures in general as well as to AWS in particular.

 

The framework organizes the design principles and best practices into what are called “pillars”. Five pillars represent major areas of concern in designing and maintaining an architecture:

• Security – Protecting information and systems.
• Reliability – Avoiding and quickly recovering from failures.
• Cost – Avoiding unnecessary costs.
• Performance Efficiency – Using resources and services efficiently.
• Operational Excellence – Managing systems to deliver business value

 

Not all pillars are of equal importance to an organization. Each organization will have its own priorities that usually resonate most with one or two of the pillars. If an organization moved to AWS primarily to save on costs, then that pillar may be of particular concern. For other organizations, maintaining uptime is most important since any unprocessed request represents lost revenue.

 

Many of the best practices described in the Well-Architected Framework are fairly obvious, such as “Rotate credentials regularly” or “Load test the workload”. And yet, even those practices are often not followed. Things slip through the cracks, projects take shortcuts to get out the door quickly—real-life collides with best intentions.

 

Benefits of Being Well-Architected and Beyond

The benefits of being well-architected go beyond just avoiding costly mistakes. Organizations can also achieve greater internal efficiency and garner happier customers.

• Deployments to production can be automated easier with fewer errors, resulting in getting features out to customers faster.
• Monitoring and logging provide faster response time in detecting and responding to incidents, and in some cases even self-healing an issue before it impacts customers.
• DevOps staff can spend more time adding value to the system and processes rather than fighting fires.

 

AWS has produced numerous resources to educate its customers about the Well-Architected Framework. There are several whitepapers, an AWS training course, and a plethora of re:Invent and Summit talks available on YouTube.

 

But here’s the rub: Simply knowing what it means to be “Well-Architected” is not the same as actually being well-architected. Reading through all the whitepapers might cause you to have some concerns about your current architecture, and you most certainly will nod your head in agreement with much of the prescriptive advice. So how do you put the Well-Architected Framework into actual practice to ensure your own architecture is well-architected? That’s the topic for the next blog.