Skip to main content

Author: Jenny Quillian

Adding BA value to your AWS cloud project

This article is intended for Business Analysts who are about to embark on a project that will use Amazon Web Services (AWS)

instead of on-premise servers to host a web application or other software service.

An understanding of the common AWS concepts and terms are helpful in two aspects of the BA role in the cloud project – Communication and Cost Analysis. AWS terms and product offerings can seem like a new language to the uninitiated. Adding these to your project vocabulary will enhance your standing and increase your contribution to the success of the project.


We are called “Business” Analysts because we are the conduit between the technology teams and the business they are supporting. We bring to the project team an understanding of the user needs and of management’s expectations of how the technology product / output will benefit their organization. We translate technology-speak into business-speak to explain both limitations of the technical solution and opportunities that the technology has opened up that the business had not considered. This is especially important in the esoteric world of cloud computing.

Technical limitations in today’s cloud platforms do not generally impact the business, but business related limitations are presented in some of the pricing models. The section below explains some cloud cost concepts. Sizing, data usage and growth estimates are key non-functional requirements for cloud projects in order to get optimal balance between the high availability features of AWS and the pay-as you go pricing structure.

The business analyst can align their knowledge of cloud features with their understanding of the business to identify those features which may provide additional benefit to the business. In this role the BA acts as an advocate for the opportunities that new cloud technology can bring to the business. For example, how can the AWS data analytics tools help the business?

An effective Business Analyst does not have to be a Subject Matter Expert in cloud-speak or in the user’s business domain- but they should appear knowledgeable to the respective teams. They must have or learn sufficient subject matter knowledge of the business and the cloud technology to be an effective liaison between the customer and the developers. In the BA task of translator between business and technology you will be engaging with software engineers who are highly skilled and immersed in the cloud world. It helps to know what they are talking about. The sections below cover some of the key AWS concepts.

  • EC2 is the first term to understand. This stands for “Elastic Compute Cloud”, and is the Amazon equivalent of the on-premise servers or VMs. Amazon provides space on their server hardware, and services associated. “Elastic” in EC2 refers to the ability to scale your infrastructure. But see discussion later on costs.
  • Containers are self contained packages of code, configurations and libraries which are installed on the EC2 server. ECS is the AWS Elastic Container Service. Docker is a tool that packages software into containers. A Cluster is a group of containers.
  • S3 stands for Simple Storage Services, just one of the storage options in AWS.
  • RDS is the Relational Database Service, which manages any of the relational database products that AWS offers.
  • AWS has a broad product offering of their own tools such as Athena for SQL queries, Redshift for data warehousing, and QuickSight for data analytics.

Note: Some information in this article is taken directly from to ensure that I am using the correct terminology and phrasing. AWS online help is extensive and I encourage you to familiarize yourself with this before and during your project.


Cloud Costs

Two important concepts in cloud hosting costs are the payment grids and service sizing.

“Elastic” in EC2 refers to the ability to scale your infrastructure and also to the payment rate chart. The rate for a small pilot app with 16 GB memory could be 20 cents an hour per GB used, but the production installation with high usage and multi-gigabyte storage could be double the cost for the same transaction result because of the increasing complexity of the services needed to successfully and securely run the app.

EC2 pricing is based on instance type (standard, high cpu, high I/O). For example, an “a1.xlarge” provides 4 CPU’s and 8 Gig memory with low I/O while the “c4.xlarge” delivers 4 CPU’s and 3.75 Gig with high I/O. The hourly on-demand cost jumps from 10 cents to 20 cents. Storage sizing is another important second sizing and data input/output have an impact on the total cost of AWS.

Architectural sizing decisions are the responsibility of the project SA or SE, but are made based on forecasts of volume and usage from the business or app owners. A successful BA can help gather and interpret this valuable input for the team. Requirements should include data and usage patterns and estimates over time, not just the final max estimates.

The selection of best sizing is also dependent on the granularity of the system/app that is being built. Apps that are made up of small micro services are more cost effective in the cloud than those made of large complex services. The BA can support this in the use case analysis. A use case may begin as a high level story, which the BA can help break down into smaller services for the app team to develop. For example: The business use case may be “As a bank cardholder, I can insert my debit card into an ATM machine to get my account balance”. The micro services behind that request could include:

  1. As a card reader service I can read the account number from a debit card …
  2. As a PIN reader service I can collect PIN numbers for validation…
  3. As a PIN validation service I can validate a PIN value against an account number …
  4. As an account balance service, I can provide the current balance of an account …

These services are granular and reusable. The use case or user story template for a cloud project should provide the ability to cross reference reusable services between use cases / user stories.

A second cost consideration is the multitude of add-on services that the AWS platform provides. Many of these are deceptively easy to initiate, with the cost not apparent until the monthly charges are reviewed. I know of a case where a cloud engineer with developer rights signed up for an annual data warehousing license from the AWS Marketplace. The cost was significant. Cost management is generally not part of the BA role, but on a cloud project the BA can help their Finance partners by gaining a knowledge of the services on the monthly – or daily – cost reports to assist in recognizing and questioning cloud services that have been incurred that were not part of the original plan.


The Business Analyst can add value to their cloud project by learning and understanding the concepts of cloud architecture and the services their cloud provider offers, so that they can enhance communication with the business and financial partners.