devopsy.kinsta.cloud

Tag: AWS

Mission Makes AWS Expertise Available for Free

Mission, a provider of managed services for the Amazon Web Services (AWS) cloud, this week announced it will make its cloud optimization expertise available free of charge for any IT organization that acquires AWS licenses through it.

Alex Beal, director of product for Mission, said as cloud sprawl continues to be an issue, many internal IT teams simply don’t have the expertise required to rein in those costs. However, rather than charge extra for the expertise Mission will now make its tools and consultants available for free under the auspices of the Mission Cloud Foundation service to any organization that employs Mission to acquire AWS licenses, he said, noting every Cloud Foundation customer will get access to a designated Mission Cloud Analyst who will provide regular account reviews and guidance on implementing best practices.

Mission can provide the free service because it acquires licenses from AWS at a lower cost. Effectively, AWS is paying for the services being provided by Mission, said Beal.

As more workloads move into the public cloud, IT teams are struggling to navigate a complex mix of service levels from AWS that range from spot pricing options to reserved instances that can be licensed for specific periods of time at a deep discount. However, determining which workloads lend themselves best to various AWS pricing options can be challenging to determine, especially for developers who spin up virtual machines without consulting with internal IT teams. Collectively, organizations are wasting millions of dollars each year because of suboptimal usage of public cloud resources. Beal estimated that the average IT organization is wasting about $5,000 a year on cloud infrastructure resources that could be better allocated to other IT initiatives.

Beal said Mission will work with those internal IT teams to identify unused resources and rightsizing candidates, set up budget alerts and recommend better options for specific types of workloads using a combination of monitoring tools from third parties such as CloudHealth and one developed by Mission. Those monitoring tools are also employed to enforce budget constraints and run security checks.

Mission Cloud Foundation also includes tools to reallocate charges, reference purchase order numbers and set up automated custom reports.

Most IT organizations could develop much of this expertise on their own. However, Beal said most IT teams also have better things to do with their time that add more value to their organization. Instead of acquiring licenses direct from AWS, Mission is making a case for an alternative approach that provides a level of service and support that AWS generally only provides to Global 2000 customers.

Other managed services providers (MSPs) may or may not also provide tools and expertise free of charge. Savvy IT teams, however, may soon force the issue. After all, while public cloud represents the most widely employed form of IT infrastructure as code, from a cost perspective it’s also clear public clouds can also quite easily become too much of a good thing.

— Mike Vizard

March 5, 2020
Does the Empire Strike Back When We Learn What Happens to the $10 Billion JEDI Contract?

Microsoft scored a huge victory by sweeping in and taking the $10 billion dollar, multi-year JEDI contract for military IT services from AWS (owned and operated by amazon.com, its parent company). The backstory on this is that James “Mad Dog” Mattis, then Secretary of Defense, met with Jeff Bezos who tweeted about it on August 10, 2017 and it appears that Mattis decided to structure a request for IT services (now known as the JEDI contract) that all but led to AWS being crowned the winner by the way the bid was structured.

However, this was not to be. Not only was Mattis gone by January of 2019, but President Trump and Jeff Bezos were having public squabbling matches regarding coverage of the Trump administration in the Washington Post (which Jeff Bezos had purchased in 2013). So tenuous is their relationship that Trump mocked Bezos on Twitter regarding his divorce which was precipitated by the leaked private messages and pictures between Mr. Bezos and his mistress.

What does this all have to do with JEDI? Quite a bit, actually. Amazon has won a perhaps Pyrrhic victory by getting an injunction and getting any work to stop on the process of implementing the JEDI contract on Microsoft’s cloud. Amazon is posting a $42 million bond to cover any costs the government or Microsoft might incur if it turns out that this stoppage is unjustified—not small beans, but not a lot of money to either of these tech titans.

Which way does this jump ball go now? It seems like Microsoft would still have the upper hand, because they as well as the U.S. government would have contemplated this outcome when they decided to switch to a Microsoft solution at what seems like the last minute.

Amazon makes a compelling case as well: Because of the public animosity between two feuding billionaires, one a president, and one the richest man in America, government officials would be afraid to award a contract to Amazon’s AWS because they would suffer the wrath of Trump and his officials. The Trump administration has made it no secret that there is a revolving door for people who don’t get with the Trump administration and its policies. Sounds like a win for Amazon, right?

At the same time, Jeff Bezos’s leaked text and pictures between his mistress bring up a larger question: How can the U.S. government trust some of its most precious data when the CEO not only leaks such personal information, but it is so public that Mr. Bezos himself discussed what he considered ransom demands from a tabloid that threatened to cover it on a blog post on Twitter. Even worse, supposedly the pictures and texts were obtained by the leader of Saudi Arabia, a foreign country, through a bug in WhatsApp that allowed installation of malware on Jeff’s phone that allowed all the data from his phone to be siphoned off to a foreign entity. It’s difficult for AWS to say they are the best solution when their own CEO admits that his most personal data (a secret affair with his mistress) was stolen. What would happen to real military secrets if Amazon’s CEO can’t protect his own?

The fallout from all this is what you’d expect. More arm waving, conjecture and confusion. The reality is this opens up the field to other players such as Google and Oracle. At the same time, there are hundreds of other clouds that may be able to make a case that they are a best fit for certain applications since they may specialize in specific compliances, such as SOX, PCI or HIPAA.

Ultimately, this calls into question whether the government should be putting all its cloud eggs in one basket. The longer-term solution is that the government needs to dictate a series of APIs that its developers and contractors use, and that all compliant clouds would be required to support. This would alleviate the problem of centralizing resources on a single vendor’s solution.

In the medium term, lots of fireworks, lots of drama and most likely Microsoft, the original software empire, striking back and keeping the JEDI contract—one that was Amazon’s to lose. But the story isn’t written so we all need to keep watching for the return of the JEDI to see where this finally ends up.

— Marty Puranik

February 20, 2020
Datadog Sees Spike in AWS Lambda Serverless Adoption

Datadog published a report that shows nearly half of organizations using the company’s IT monitoring platform have embraced the AWS Lambda serverless computing framework.

Stephen Pinkerton, a product manager for Datadog, said that number shows serverless computing frameworks are being employed by mainstream IT organizations far more widely than initially might be thought, given the relative age of serverless computing frameworks.

The report finds the median Lambda function invoked by Datadog customers runs for about 800 milliseconds. Nearly one-fifth of functions execute within 100 milliseconds, while about one-third execute within 400 milliseconds. One-quarter of Lambda functions have an average execution time of more than three seconds, while 12% require 10 seconds or more. The duration of Lambda functions is notable because serverless latency impacts not just application performance but also costs. Lambda pricing is based on “GB-seconds” of compute time, which is the memory allocated to your function multiplied by the duration of its invocations.

Not surprisingly, the report notes 47% of functions are configured to run with the minimum memory setting of 128MB. By contrast, only 14% of functions have a memory allocation greater than 512MB, even though AWS will allow up to 3,008MB per function.

As part of an effort to further limit costs, most organizations are not employing a function to call another function and then waiting for a response, which would incur billable invocation time. Rather, serverless functions are making asynchronous calls via a message queue. Functions that are stateless most often read from or write to a separate persistent data store.

Amazon DynamoDB, a document database based on a key-value store architecture, is the most widely used persistent form of storage accessed, followed by an instance of the SQL databases provided by AWS as a service, and then the Amazon S3 cloud storage service.

The Amazon Simple Queue Service (SQS) is the top choice for a message queue for Lambda requests, followed by Amazon Kinesis and Amazon Simple Notification Service (SNS).

The report also notes each Lambda function has a configurable timeout setting, ranging from 1 second to 15 minutes. Two-thirds of configured timeouts are 60 seconds or less. By default, Lambda customers are also limited to 1,000 concurrent executions of all functions in any given region. Only 4.2% of all functions have a configured concurrency limit. A total of 88.6% of companies running Lambda make use of concurrency limits for at least one function in their environment.

In terms of programming languages employed, Python and JavaScript in the form of Node.js are the most widely used on Lambda, the report finds. Nearly half of Datadog customers running Lambda (47%) employ Python, while 39% run Node.js. Python 3 outweighs Python 2, which has reached end of life, by a factor of two to one.

Finally, the report notes there is a high correlation between organizations that have adopted containers and those employing serverless computing frameworks. Nearly 80% of organizations in AWS that are running containers have adopted Lambda. However, Pinkerton says that correlation at this point has more to do with the willingness of organizations to employ leading-edge technologies than it does any effort to weave together containers and serverless computing frameworks.

Pinkerton also surmises the primary reason organizations are employing Lambda is to accelerate application performance. However, it’s also worth noting serverless computing frameworks also tend to reduce to the size of an application by relying on external functions to run code that is not frequently invoked outside the core application.

Datadog plans to evaluate usage of serverless computing frameworks on other cloud platforms once they achieve enough critical mass. In the meantime, it’s clear serverless computing frameworks are rapidly becoming an extension of any DevOps pipeline.

— Mike Vizard

February 3, 2020
SIOS Technology Automates Rebooting of AWS EC2 VM Instances

SIOS Technology Corp. this week launched SIOS AppKeeper, a tool that automatically reboots instances of EC2 virtual machines anytime they fail.

Michael Bilancieri, senior vice president of products and marketing for SIOS, said SIOS AppKeeper is an extension of the work SIOS has historically done to enable servers and clusters to failover. However, many organizations don’t require that level of availability, so SIOS developed AppKeeper to provide a way to automate the process of restarting virtual machines in the cloud, said Bilancieri.

SIOS AppKeeper also provides a dashboard through which DevOps teams can centrally manage the stream of alerts that are generated when there is an EC2 issue, he said. SIOS AppKeeper is a software-as-a-service (SaaS) application so there is no software to be installed. Instead, organizations log into their AWS account and select which instances and services to monitor and the level of protection they want SIOS AppKeeper to provide.

Pricing for SIOS AppKeeper starts at $40 per EC2 instance. Monitoring and alert capabilities are provided by default. Restart services, reboot instances and reboot instances only if a restart of services fails are all options. Organizations can opt to access SIOS AppKeeper either via the graphical user interface provided or via an application programming interface (API), Bilanieri said.

Previously, SIOS AppKeeper was only available in Japan. Based on data from those customers, the average customer with only three AWS EC2 instances experienced downtime at least once a month. With SIOS AppKeeper, customers were able to reduce downtime by 90%, Bilancieri noted.

SIOS will consider adding support for other public clouds based on customer demand, he said.

Cloud service providers, in keeping with the “pets versus cattle” ethos, tend to view virtual machines as being disposable. However, whenever there is an issue someone on the IT team still needs to take the time to restart a virtual machine, Bilancieri said.

Despite the drive to ruthlessly automate in the management of IT in the age of DevOps, there are still many tasks being performed manually. As the number of workloads in cloud computing environments continue to increase, those tasks conspire to slow IT operations. There are, of course, many ways to automate IT processes in the cloud. SIOS is making a case for a simpler approach to managing EC2 instances that doesn’t require IT teams to set up an entire IT automation framework.

Many IT teams will opt to create their own scripts to manage EC2 instances. However, it’s all too often the case that those scripts are poorly documented and don’t scale especially well over time. In addition, each time the IT professional who wrote a script that the organization depends on leaves the organization, there is no one left to update and maintain the script and new members of the IT team wind up writing yet another script to perform the same function.

There will always be some type of script floating around the IT environment. However, in the age of DevOps, the time to start reducing the number of those scripts that need to be supported might be at hand.

— Mike Vizard

January 30, 2020
Earning an AWS Developer Associate Certification

Studying for an AWS Certification may seem like an arduous task, especially if one isn’t expecting to take any more tests now that college is finally over. However, the certification doesn’t have to be long and tedious—it can be accomplished in as little as three months or less.

I had started working in the middle of August as a DevOps engineer at a major financial services regulatory firm, and at the suggestion of my peer mentor, pursued the Developer certification—which I earned by the second week of November.

Having recently graduated from college, I had no exposure to cloud computing, let alone Amazon Web Services (AWS). However having ventured into a DevOps role, I quickly realized that in order to contribute to my job, I needed to gain a solid understanding of AWS—preferably as fast as possible. My studying time was a mixture of evenings at home, daily commutes on the train and spare time at work. In total, I would estimate a total study time of 40-60 hours. I believe that by allocating the time and following the procedure listed, anyone can accomplish a similar feat.

I would break the procedure down into three separate stages: broad overview, documentation and exam specific details. After all, in order to learn any subject well, a broad solid foundation is essential before narrowing down to the minute details.

Broad Overview

As someone who was starting with almost no understanding of anything related to AWS, I needed a way to pick up as many of the different services as possible and understand how they relate. Thankfully, my company offered an online teaching environment called Linux Academy that included a course on the Associate Developer Certificate. At this point it may be tempting to assume that I passed the exam simply by following the course. However, I personally believe that although the course helped provide a foundation, it was nowhere near sufficient in covering the full material required.

The course (approximately 12 hours including some basic labs) provided me with an overview of the major services related to the exam as well as the connection between different components. The course also came with practice quizzes and a final exam, that although were helpful, were not at the level of the AWS exam. The only questions I felt were incredibly helpful were in regards to Read and Write Capacity for RDS. There are four combinations: Read with Eventual Consistency, Write With Eventual Consistency, Read with Strong Consistency and Write with Strong Consistency. Each had a slightly different computation and I would recommend looking up example questions even if you do not use the course.

Since the course was used more as an overview than to teach everything on the exam, it may be possible to skip this section if you already know some of the material or do not want to pay for any online courses. Simple YouTube videos may be able to provide a similar level of detail.

Documentation

This is the core of the studying and the most annoying but inevitable. From my personal experience, the exam is not passable without reading the white pages. Each certification has a list of suggested white pages to review on the AWS’s provided exam guide. I recommend starting with the one titled AWS Overview, the ordering of the rest is less consequential. Although I did not have the time to, I would recommend going over each white page twice. The Basic Overview is particularly important because it describes more services than what was introduced in Linux Academy and also goes into detail on services. It also helps to differentiate between the Amazon Kinesis services.

Knowing the Exam

Finally, after gaining a pretty good foundation and understanding of the services it is important to focus on our objective—tailoring our studying for the AWS exam. “Well, what was everything above this for?” While it is true that it is important to understand the different services that AWS offers, the key to passing the exam is to answer the questions correctly.

As with any exam, knowing the proper format and types of questions is important. It is important to figure out what level of detail the AWS certification expects as well as what topics are most likely to be emphasized. The easiest way to do this is to take the practice exam offered by AWS. Because the sample exam is offered by AWS itself, it is much more similar question-wise to the actual exam than Linux Academy or other sites I had looked up on the internet. For $20, it provides information that is hard to find otherwise. Furthermore, those questions make it easier to look online and find study guides with questions that will actually resemble the certification and provide answers.

It is noteworthy to mention that the AWS practice exam only provides guidelines on percent correct for each category but does not return the correct answers. After seeing the results, I recommend focusing on the area that is weakest if only one or two categories are lagging behind. However, if all of the scores are relatively close, I would recommend focusing on the highest one, because it is the subject you most likely have the easiest time understanding. Obviously, if all scores are incredibly high then any remaining studying is your prerogative and if they are all low, then it may be necessary to go over the material again.

Miscellaneous

One advantage I had while studying for the exam is that my work was related to learning AWS and I gained exposure to ECS, EC2, Lambas, Step Functions and the AWS CLI. However, although this experience provided me with a little more familiarity with the products, I would not consider this crucial to my passing the exam.

There are questions about the correct API calls and I had an incredibly difficult time finding the APIs even on Google—the API calls are located in the documentation under actions. Also, since there are so many API actions, I would advise finding general rules and using those on the test—for example, most calls seem to be singular except list actions which are plural.

From what I can recall, at the time of November 2019, it seemed that the questions I faced had an emphasis on serverless services such as Kinesis, Lambda, API gateway and much less on IAM which the Linux Academy Course seemed to focus one.

Conclusion

Final thoughts include: from what I have seen online, on average, a 70% is required to pass the exam but can oscillate according to the difficulty. If you want, it may also be good to start by taking the practice exam to provide a direction for the rest of the studying. White page reading is monotonous but critical to learning all the information required. However, thankfully the writers were quite proficient and presented the information as efficiently and casually as possible.

Although the steps provided were the ones I used to pass the AWS Associate Developer, I use a similar series of steps on other exams, whether AWS or not. Start by skimming the entire material in order to warm your brain up to the information, effectively providing it with some reference material and footholds for in depth studying. The inevitable part of studying is the reading of denser material. Admittedly, not everyone learns best through reading but it provides a much faster and more efficient way of learning than auditory, which can take much longer. As you read the material more thoroughly, try to map out connections between different aspects and services. Also, try to find any interesting information that comes across, sometimes the examiner will also find the same information interesting and therefore it is more likely to appear. Lastly, it is important to take advantage of any practice material from the source. Even if they do not contain answers, you can probably search them and potentially learn an answer that may reappear on the exam. Furthermore, it allows you to find similar problems and helps you accustom yourself to the format and questing style of the exam.

— Jintao Hang

January 29, 2020
DevOps at Longtail UX

Longtail UX is an Australian SaaS startup that boosts traffic to e-commerce sites by automating the selection of relevant long-tail search terms and the creation of custom landing pages for each of those terms.

The company has fully embraced the Infrastructure-as-Code approach, according to Troy Jendra, senior systems architect at Longtail UX.

By using Terraform and Ansible for automation, “we can release whenever we want,” said Jendra. In practice, that can be at intervals between two minutes and as long as necessary at the other extreme.

Jendra said he had not used Ansible before joining Longtail UX. He used Puppet in a previous role, but found it “painful.”

“Ansible was a breath of fresh air,” confessed Jendra. It makes it easier to write configurations, and uses fewer CPU cycles because it does not need to run continuously. He explained that Terraform’s role is to spin up sufficient infrastructure so Ansible can run.

A recent project added support for CJK (Chinese, Japanese, Korean) characters to Longtail UX as part of a push into the Asia market, and that made it necessary to clone part of the infrastructure. Thanks to Ansible and Terraform, that task was easy to perform and completed in just half an hour. Thus, Longtail UX brought the new capability to market more quickly than would otherwise have been possible.

Ansible and Terraform together form “a cornerstone of our disaster recovery plans,” said Jendra. Fully automating recovery to improve on the current worst-case time of a few hours would take more time and effort than justified.

Apart from that, “it’s important to automate as much as we can,” said Andreas Dzumla, Longtail UX co-founder and CEO.

Avoiding Vendor Dependence

Even though Longtail UX runs on AWS, a deliberate decision was taken to avoid the vendor-dependency that would come from using AWS-specific services, such as AWS CloudFormation, in place of Terraform.

For the same reason, the company keeps things as simple as possible and sticks to AWS basics, such as EC2. It has recently started using Spot Instances to reduce the cost of running certain batch processes.

Jendra keeps a watching brief on AWS Lambda, and while the company does not currently have a use case he does see a time when it will jump from EC2 to Lambda.

“We’re pretty locked into AWS,” he admitted. However, the company uses AWS-specific services only where the benefits clearly outweigh the lack of portability. He likened the situation to 1990s attitudes toward using Microsoft-specific technologies.

Growth

The adoption of Kubernetes is not on the cards due to the relatively small size of Longtail UX’s DevOps team.

“We’ve doubled the size of our development team in the last six months,” said Jendra. It now comprises seven developers, a project manager and himself.

Dzumla expects it will double again in the next 12 months.

Jendra predicts that improvements to Longtail UX’s development stack will make it easier to on-board new hires.

“We currently utilize a Vagrant/VirtualBox dev stack (hooked into the aforementioned Ansible configuration), but find that very rough around the edges, and I only see it get worse as more attention is focused on Docker,” said Jendra.

DevOps is a philosophy, not a role, he emphasized. “Either everyone is doing DevOps or it doesn’t work.”

Fortunately, that understanding goes to the top of the company.

“Everyone needs to pitch in,” said Dzumla. “We do a lot of things that haven’t been done before, so we need senior people who don’t merely expect to do what they’re told.”

— Stephen Withers

December 20, 2019
Waging a Winning WAR in AWS
Above all other security advice for enterprises working with Amazon Web Services (AWS), there is one resounding war cry: “Go to WAR.” WAR is an acronym meaning Well-Architected Review. It’s a powerful and proactive way to mitigate real risk with the AWS team and its partners. If you’re using AWS (or thinking about it) consider adding WAR to your security arsenal. It’s a well-kept secret starting to proliferate in the cloud industry for reasons you will find obvious after reading this article.

AWS Promotes a Shared Responsibility Model

When it comes to cloud environments, a common term that is often heard and used across all cloud service providers (CSPs) is “shared responsibility model.” This model most often dictates terms of Master Service Agreement with any potential CSP, be it a Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) model. The goal is to clearly identify and establish the security responsibilities that are shared between a CSP and cloud consumer.

As security experts, Wallarm advocates for the shared responsibility model. It is impossible for a cloud provider to provide 100% security for you, like in securing your customer’s data and access (you can see this in the AWS shared security model below). There are also enormous benefits to application and API security to having both the CSP and cloud consumer putting up a strong defense. All customers on AWS and other cloud infrastructures should be proactive agents in their cloud security. (See Securing Apps on AWS with Wallarm.)

This visual image depicts how shared responsibility is distributed:

It Starts with Well-Architected Frameworks for AWS Cloud Architects

AWS Developed the Well-Architected Framework to help cloud architects build secure, high-performing, resilient and efficient infrastructure for their applications. Based on five pillars—operational excellence, security, reliability, performance efficiency and cost optimization—the framework provides a consistent approach for customers and partners to evaluate architectures and implement designs that will scale over time.

AWS’s Well-Architected Framework approach is built on the shared responsibility model that helps consumers and providers truly understand their portion of responsibilities, as outlined in the figure below.

The framework was intended to be far more than an architected tool for AWS. It was designed as a sort of way of life and method of looking at your architecture to ensure resilient and consistent outcomes.

The Well-Architected Framework is a living set of best practices that AWS continuously updates. Every time you think about starting something new or changing something, use the five pillars to evaluate what you are proposing. This is where WAR comes in.

Approaching the WAR of Cloud Security

The WAR is a systematic approach to review your architecture—whether already in AWS, on-prem or even in other cloud providers. WAR is currently a set of 46 questions, which could shift in number since this is a living methodology. It is aligned to the five pillars mentioned:
- Security.
- Reliability.
- Performance efficiency.
- Cost optimization.
- Operational excellence.
Answering WAR questions helps identify which areas fall into three categories:
- Well-Architected.
- Need Improvement.
- Critical Issues.
Critical issues should be remediated immediately. These are things such as not using multi-factor for your accounts or exposing data to the public. Need Improvement items should be looked at over a three to six month time period.

AWS recommends that you perform these reviews periodically (at least every six to 12 months) on each critical workload. Even items that are deemed Well-Architected today can change due to changes in your environment or new options that replace the way you are doing things today.

How to Go About a WAR for AWS

There are two key factors that must be considered before you think about conducting WAR on AWS:
1. Architecture Complexity.
2. Skill Level.
We are going to look at some example cases on what combination of factors should encourage you to wage WAR, or not.

Case 1: Highly complex architecture and expert skill set.

If you have a highly complex architecture and an expert skill set, a hybrid approach is recommended.

Meeting with an AWS representative at least once can be very helpful to pinpoint small, important things that are easily overlooked. For example, a focus on the business logic based infrastructure might obscure your view of a Critical Issue.

After the initial WAR exercise and importing the results within the AWS console, you could get away with repeating the same process internally with your highly skilled staff. Frequency of WARs depend on what you discover and the amount of resources available to you internally.

Case 2: Highly complex architecture and novice skill set.

When you are handling a highly complex architecture and do not have the bandwidth to understand the different pillars of the Well-Architected Framework, look for external help. Negotiating a good price with an AWS partner, is the best approach.

Cost concerns shouldn’t stop you from a WAR. The cost savings coming from a Well-Architected Review may justify the additional costs involved in engaging with an AWS partner consultant.

Case 3: Less complex architecture and novice skill set.

If you are fairly new to AWS and the complexity of your architecture is not too high, it is recommended to engage directly with AWS team. A WAR will help you understand how to handle disaster recovery, redundancy, failovers, etc. that are usually not taken into account with new teams.

Case 4: Less complex architecture and expert skill set.

The only case when a do-it-yourself (DIY) approach is viable (yet optional) is when you have a low level or architectural complexity and expert level skill.

For a DIY WAR, you can use the AWS Well-Architected Tool, released in November of 2018, along with a user guide. Review the Well Architected Framework whitepaper and refer to the questions and best practices to conduct the review yourself.

The Well-Architected Tool is already part of your AWS Console. It’s incredibly easy to use. There are great instructions and videos for each question.

Getting to know all the pillars by navigating the AWS resources is highly recommended.

The Process of WAR

The process of WAR is simple and not as tedious as you may worry. It starts with a questionnaire-based review. The review usually takes a couple of hours and is relatively painless. Whether you do it yourself, appoint an AWS partner or engage directly with the AWS team of experts, you will use the Well-Architected Tool to go through the 46 questions. At the end of the initial session, you can expect to gain a decent understanding of your current architecture and a very detailed report breaking down the Critical Issues and Need Improvement areas into actionable steps for improvement. Outside a DIY approach, you are likely to receive a detailed report identifying the gaps in all five pillars of WAR.

Amazon is known for its fundamental principle of customer delight. This philosophy really comes alive with WAR as AWS representatives work with customers to help mitigate findings after a WAR. Often times, companies can obtain credit from AWS to fix critical issues identified during WAR. War can be done in multiple iterations, especially if several critical workloads are identified and taken into the scope of WAR.

What Is a Critical Workload?

Each customer knows their business and what’s critical to their operations. That might be your customer portal processing all your orders. It might be the supply chain system driving your manufacturing processes. It might be your case management system used to ensure client work gets completed on time. The critical workload is what you identify as most critical to your operations for running, changing or growing your business.

Various Lenses for a Stronger WAR-Time Vision

AWS means it when they say “put on various lenses.” The WAR process is an ever-evolving process. AWS has expanded the WAR for some very specific use cases. AWS calls these “lenses”:
Each lens area is changing quickly and has different architecture best practices. This is a strong reason why relying exclusively on a CSP for cloud security is never a good idea. A constantly evolving threat landscape makes it critical to understand the necessity of shared responsibilities and what is at stake.

For the sake of understanding, let’s focus on one of the lenses: serverless.

Serverless computing assumes the provider runs the code provided by the customer while completely taking care of the infrastructure and the environment itself. Serverless providers offer what is known as function as a service (FaaS) platforms. FaaS platforms execute code for the application logic, but remain completely stateless themselves, meaning they do not store data. AWS Lambda is the oldest and the most popular public cloud infrastructure serverless computing offering.

Serverless lens reduces the attack surface. Because AWS takes the infrastructure concerns on itself in their entirety, there is no need to harden EC2 operating systems and configuring container. Also, because there are no data or state exposure to the data, compromise is limited.

What still need securing are the APIs to and from the functional computing and access control, including authentication. To secure these vulnerable areas, runtime tools—such as Wallarm’s AI-powered solutions—can enable serverless API security and apply the well-known Defense in Depth strategy.

To augment WAR process with actionable application security steps and strong granular authentication practices, we recommend:
1. Applying auto-configured, run-time API security for Defense in Depth.
2. Integrating automated security testing into your build or continuous integration process.
DAST: Dynamic Application Security Testing. DEV: Developer.

WAF: Web Application Firewall. SEC: Security.

FAST: Framework for Application Security Testing. OPS: Operations.

CI/CD: Continuous Integration/Continuous Testing.

Conclusion

The AWS Well-Architected Framework will provide strategies to help you compare your workload against the best practices recommended in this article. It can also help you get guidance on producing stable and efficient systems, so you can focus on functional requirements and overall business.

Start learning about WAR by downloading the AWS Well-Architected Framework whitepaper. If there is one thing you must do to best understand and operationalize your shared responsibility with your CSP, is to perform a WAR.

— Kavya Pearlman
December 17, 2019
AWS Applies Machine Learning to Optimize Cloud Deployments

Amazon Web Services (AWS) this week at its re:Invent 2019 conference unfurled two tools based on machine learning algorithms to optimize cloud application deployments.

Amazon CodeGuru is a service available as a preview, through which the cloud service provider will inspect application code using machine learning algorithms to profile the code and then identify bottlenecks and what part of that code is the most expensive to run on the AWS cloud.

AWS Compute Optimizer, meanwhile, identifies optimal Amazon EC2 instance types, including those that are a part of Auto Scaling groups, for specific types of workloads. It analyzes the configuration and resource utilization of a workload, including historical metrics, to identify dozens of characteristics to recommend optimal AWS compute resources. AWS Compute Optimizer is accessed via the AWS Management Console. Rather than rely on humans to optimize cloud platforms, AWS is making a case for reducing the time and effort required to determine which of dozens of instance types will deliver the highest performance at the lowest cost possible.

Amazon CloudGuru can pull code from either GitHub or CodeCommit repositories, with support for other repositories planned. It requires developers to insert agent software developed by AWS into their code. Once a pull request is made, Amazon CodeGuru will automatically start evaluating the code using trained artificial intelligence (AI) models that AWS developed using data gathered from thousands of different open source software projects by AWS and its parent company.

Once the analysis is completed, Amazon CodeGuru will generate a “flame graph” showing, for example, latency issues and CPU utilization rates alongside human-readable recommendations to surface specific issues and recommended remediations that include example code and links to relevant documentation for any line of code. Amazon CodeGuru can observe application runtimes and profile application code every five minutes.

AWS CEO Andy Jassy told conference attendees that Amazon is already employing Amazon CodeGuru across 80,000 applications, which has resulted in increases in infrastructure utilization rates that have reached 325% in some cases.

While machine learning algorithms have a clear role to play in terms of enabling DevOps teams to build and deploy more efficient code, it’s not clear to what degree DevOps teams will want to give AWS that level of access to what are often highly proprietary applications. Many DevOps teams may prefer to employ machine learning algorithms within the context of a continuous integration/continuous deployment (CI/CD) environment to drive code to multiple cloud computing platforms. Whatever the approach pursued, it’s clear machine learning algorithms are about to play a much larger role in DevOps. In fact, Jassy this week made it clear AWS will be applying machine learning algorithms broadly to enhance everything from enterprise search to identifying potential fraud.

What is less clear is how best DevOps practices will need to evolve to account for machine learning algorithms. Many of the processes that make up a DevOps toolchain are increasingly being automated. That doesn’t eliminate the need for the toolchain, but it will sharply reduce the amount of time and effort required to build and optimally deploy applications.

— Mike Vizard

December 4, 2019
Why AWS Cost Optimization Is About More than Saving Money

Why is it important to track and monitor cloud costs? The obvious answer is it helps you save money—and everyone wants to save money.

Yet, cost plays a much larger role in your cloud journey. If you think about cost only in terms of how much you are paying and what you are getting in return, then you’re missing much of the value that careful cloud cost control can provide.

Let’s take a look at all of the reasons why monitoring and optimizing costs is critical for a successful AWS strategy.

What Is Cost Optimization?

In AWS and other clouds, cost optimization is the art and science of identifying and addressing inefficiencies in the way you are using resources.

Those inefficiencies come in many forms. They could be an EC2 instance that offers more resources than you need for a given workload, which could therefore be replaced by a different, less costly instance.

They could be a result of using one type of application architecture, like workloads running directly on virtual machines, when another, such as serverless or containers, would deliver the same performance for less overall cost.

They could be caused by failing to take advantage of the best opportunities available for hosting a given workload. For example, you might be using S3 Standard for storage when S3 Glacier would meet your needs just as well, at a lower cost.

By identifying these sorts of problems, you can take steps to spend less while maintaining the same level of performance for your cloud workloads. A basic best practice is to use tools such as AWS Trusted Advisor to help ensure that your infrastructure is set up in a cost-efficient way from the start.

Cost Optimization Insights

These tools only go so far, and they are not the be-all, end-all of cost optimization. They are designed simply to help choose the right type of configuration for a given workload. However, cost monitoring as a whole goes further, and delivers several other important types of insight into your AWS workloads and strategy.

Rogue Infrastructure

By its nature, rogue infrastructure—meaning use of infrastructure for purposes not officially authorized by your organization—is hard to detect. If it wasn’t, it wouldn’t be very good at being rogue.

If you monitor cloud costs carefully, however, rogue infrastructure will have a hard time hiding. If employees spin up a virtual server in the cloud for personal use, or create storage buckets for organizational data that is not supposed to exist in the cloud, you are likely to discover it when you perform cost optimization operations designed to help identify workloads that should not be running.

Having a strong IT governance policy in place that requires all cloud-based resources to be tagged is another way to help prevent the creation of rogue infrastructure, and to make unauthorized resources easy to detect. When possible, tagging should be automated to ensure the fastest and most consistent results.

Security Risks

Although cost optimization is certainly not the only tool you should use to help identify security issues in your cloud workloads, it provides some useful insight that other tools might lack.

For example, if you notice that your bills for a certain application or service have increased due to heavier usage without a corresponding increase in legitimate requests, it could be a sign of brute-force attacks or other unauthorized access attempts.

Neglected Projects

When was the last time you evaluated each of your applications to ensure it was running as efficiently and securely as possible?

If you don’t know because you don’t regularly do this, cost optimization can help ensure that you do recognize workloads that could stand to be reconfigured. If you discover that you are paying more than you expect for a given workload, or that one workload’s costs are rising more quickly than those of others without a clear reason, it’s probably time to take a look at that workload and assess whether it should be scaled up or down, migrated to a different type of service, or otherwise adjusted to operate more efficiently.

Operational Inefficiencies

Finally, cost optimization can help you identify inefficiencies in the way your organization is run. That is because fees charged by AWS that you could have avoided but didn’t might reflect larger inefficiencies within the organization.

For instance, consider AWS data storage costs. If your AWS cost analysis shows you are paying early-deletion fees for data stored in S3 Glacier, you should determine why that is happening. It could be simply because you should be using a different storage class, but it could also be because employees are deleting data sooner than intended.

Conclusion

Saving money by being cost-efficient should always be one of your goals. But running your overall business in an efficient, transparent manner is another. AWS cost optimization can help you achieve all of this.

This sponsored article was written on behalf of Eplexity.

— Chris Tozzi

December 3, 2019
Optimizing AWS Performance Over the Long Term
Ask most folks how to optimize performance on AWS, and they’ll talk about things such as autoscaling and rightsizing.

Those tools are certainly part of an effective AWS performance optimization strategy. On their own, however, they are not enough to guarantee performance and reliability over the long haul.

That’s because tools and processes such as autoscaling and rightsizing only help you optimize the performance of applications that are running currently, or are about to be deployed. They do little to ensure that performance remains optimal—especially as cloud services, cost structures and architectures evolve.

With that challenge in mind, let’s discuss how to get the most out of AWS performance over the long term.

What is AWS Performance?

Before delving into long-term AWS performance strategies, let’s make clear what we mean by performance. A high-performing application is one that:
- Meets or exceeds user expectations regarding responsiveness and speed.
- Meets or exceeds SLA requirements for availability.
- Is able to scale seamlessly as performance requirements change.
- Does all of the above in a cost-efficient manner.
These aspects of a high-performing AWS application are important to emphasize because they reflect a holistic approach to performance. Sometimes performance is defined narrowly, in terms of application responsiveness and/or availability. Those are part of the performance equation, but in order to maximize performance over the long term, you need to think about other dimensions of performance, like the role played by scalability and cloud spend.

Long-Term AWS Performance Considerations

To optimize AWS performance over the long term, you must take a variety of factors into consideration.

Handling AWS Service Changes and Upgrades

AWS is constantly evolving. A performance strategy that works well today may not be as effective tomorrow if AWS introduces a new service or changes the features of an existing service.

The challenge here lies not just in updating your app and your cloud configuration as AWS changes how a particular service works. It also requires constantly evaluating whether the service you are using is the best fit for your application.

For example, think back about five years to when AWS Lambda (AWS’s serverless computing service) appeared. At the time, if you were running your apps inside virtual servers, you might have been able to improve overall performance by moving some of the workloads to serverless functions—not because anything in your virtual servers had become less efficient, but because better efficiency opportunities opened up with the addition of a new AWS service.

Thus, being constantly aware of the various services in AWS and the opportunities they offer is key to optimizing long-term performance.

Plan for Changing Cost Structures

AWS not only changes its menu of service offerings frequently, it also updates pricing. Since cost optimization is one key component of performance optimization, you must ensure that your cloud workloads are running in the most cost-efficient way even as cost structures change.

Staying aware of new cloud services (such as lower-cost S3 storage tiers) when they appear is one way to do this. But you also need visibility into the tremendously complex world of AWS pricing in all of its region-specific details.

Plan Long-Term for OSS Dependencies

Open-source software is something else that is constantly changing. If you rely on open source code to help run your AWS applications, you need to stay on top of changes in the projects you depend on.

If you are using the same version of an open-source application or module that you built into your application when you first deployed it, you may be missing out on performance optimization opportunities that have arisen since then.

Here again, constant awareness of and visibility into the complex open-source ecosystem is essential for ensuring that you are not missing out on optimization opportunities.

Application-Specific Performance Monitoring

Every application is a special snowflake and you need to keep that in mind when it comes to the way you track and optimize application performance.

The metrics or KPIs that work for optimizing the performance of one app may not be ideal for another. The pre-deployment testing routines you use for applications might vary, too.

So, make sure to tailor your monitoring strategy to your applications. Doing so is the only way to ensure you have the greatest, most relevant level of visibility into application performance over the long term.

Backup and Disaster Recovery

No matter how well your AWS workloads perform, sooner or later something will go wrong and they will fail. Whether the failure leads to a critical availability disruption or a mere hiccup hinges in large part on whether you have a backup and disaster recovery plan in place beforehand.

For AWS apps, an effective backup and recovery plan entails more than just backing up data to storage buckets and downloading it to rebuild servers. It should also take advantage of opportunities like the ability to create image-level backups of virtual servers and restore them automatically to EC2 if disaster strikes.

And of course, as AWS changes, you’ll need to keep your backup and recovery strategy in sync.

Changing SLA Requirements

Last but not least, keep your SLAs in mind. The SLAs you have to support today could change in the future—and by extension, so will the levels of availability and responsiveness that your users expect.

For this reason, make sure your AWS performance strategy is capable not only of meeting the SLAs you currently have in place, but also adapting and scaling as SLA requirements become more rigid.

Conclusion

Although we tend to think of performance within the context of the present, it’s really a long-tail game. Sure, you can autoscale your workloads or use rightsizing tools to help choose the best type of EC2 instance for right now. But truly maximizing performance requires you to think longer-term and be prepared to react with agility as new performance challenges and opportunities arise.

This sponsored article was written on behalf of Eplexity.

— Chris Tozzi
November 26, 2019