Although migrating an enterprise's business processing to the cloud is a huge goal realized, it's just one evolutionary step. Once it's accomplished, IT inherits the major ongoing task of proving the move was—and remains—financially justified.

Moving to a cloud-based business has proven to be a wise strategy for many organizations. It often provides significant benefits, including potential cost savings if the transition process is handled efficiently and with appropriate planning. But what isn't so apparent from the beginning is that calculating future expenses and the value realized by the change becomes a necessary and permanent new effort for IT.

Although overlapping in many respects, calculating the ongoing value of a migration is different from calculating the cost of the migration itself. Once in place, moving to the cloud for many or most business processing functions always raises the question of "Could we be doing this better somehow?" It's a concern that never goes away as technology and the business itself continue to evolve.

The infrastructure for beginning to calculate the ongoing justification of migration can be based on the estimates for the migration itself. The enterprise will have decided on the pricing and cloud infrastructure model it will start out with, the resource costs (hardware, software, services, tools, personnel), and the details of the cloud service provider’s (CSP) contract. There will quickly be cost and income profiles under the new system that can be compared to pre-migration figures. However, after that, a host of new statistics need to be tracked and compared annually, quarterly, monthly, weekly, or even daily. "Set it and forget it" is no longer a valid strategy for monitoring the cloud part of an enterprise budget—the world of "Cloud Economics (EC)" now beckons.

Cloud Economics 101

To begin with, EC needs to become a standard process that perpetually analyzes cloud computing costs to help the enterprise decide whether and how much optimization needs to be added to produce the maximum possible benefits. A constant eye must be kept on calculations such as Total Cost of Ownership (TCO), Return on Investment (ROI), and Cloud Cost Analysis (CCA), which requires monitoring how each specific cloud resource is used and how much each is costing the enterprise.

CCA requires careful tracking of such elements as how much data is being moved across cloud services, whether and how much is charged for both incoming and outgoing data transfers, how much infrastructure costs (based on pricing models in use, number of virtual machines in use, amount of CPU/RAM consumed, the effect of instance- and use-type effects, network components), software licensing costs (affected by consumption, numbers of users, how much in-house software is used versus provider tools and software available), and storage costs (affected by security, deduplication, replication, storage access patterns) are trending. Also vital to track are data egress fees (i.e., charges for data leaving a cloud environment), regulatory requirements, backup and disaster recovery needs, and premium services such as cloud support, operations performed on cloud data, and data transformation. A system of continuous monitoring of all aspects of cloud usage by all enterprise entities must be established, and a full-time person or team must review the results to find inefficiencies and anomalies that require improvement on a real-time basis. Enterprises will need dashboards and other tools to monitor resource use, cost changes, and performance indicators. Numerous software tools can help with these tasks, some of which are built into CSP offerings, and others must be sought from third-party sources or designed from scratch. However, third-party tools may be limited for specific important tasks under some cloud computing platforms, and undergoing a process of finding (or inventing) one that truly suits an enterprise's particular environment and business is imperative.

One example is cloud tagging, the process of assigning metadata to individual cloud resources, which can help enormously with tracking cloud-related expenses under systems such as Azure. Tagging each cloud resource requires such identifiers as a workload's name, a classification of how sensitive its data is, how vital the workload is to the enterprise's business operations, which business entity or unit owns the data, how much operations support is needed for that resource, and what team is responsible for daily operations. It is often helpful to include additional information about the resource, such as the name of the person who approves costs related to that resource, how much money is currently budgeted for it, what cost center pays for it from their budget, what level of disaster recovery applies, and relevant project deployment and end dates. Or is there other information the enterprise requires as well: information about the deployment environment, who "owns" the data, who originally requested the application, the service-level classification of the resource by the CSP, security levels, and any other possible factoid about the resource that happens to be important within the context for the enterprise's type of business?

No third-party tool is likely to do it all; a list of what must be tracked will vary, and this list may easily include requirements no CSP or third-party tool provides. What's covered by cloud tagging in any enterprise will affect how applicable any resource-tracking scheme will ultimately be to informing future resource optimizations, determining cost control or automation improvements, alerting IT to cost overruns, or highlighting areas needing change a year or two down the road. Worst of all, no matter how much data is included in tagging, there will always be more that is potentially useful for someone to know. No tagging scheme, therefore, can ever be complete – it must be constantly modified as business needs change, potentially forever. This is just a critical piece of information that needs to be tracked to keep cloud operations financially efficient.

There will also need to be a system for keeping an eye on costs for support functions like changes to licensing and service costs, networking expenses, storage charges, and alerting someone to underused resources the enterprise continues to pay for, or for changes made by CSPs because some system actions have malfunctioned and been automatically replaced by a new version that may have unpredictable consequences in an enterprise's particular case.

Suffice it to say, there are many aspects of a cloud system that must attract an inquiring eye, in addition to those that need to be tracked before a cloud migration. Proper cloud management requires visibility in all areas of cloud performance and use. Only by determining the best data for the enterprise to track and setting up systems to accomplish it can responsible enterprise people prove the cost-effectiveness that a cloud-migration project has achieved.

Fostering Best Practices for Cloud Optimization

Of course, that raises the question of what to do if the data shows cost-effectiveness remains elusive. One road to reaching that goal is to follow procedures that foster optimization. An important one is analyzing cloud-service usage patterns to use CSP-provided cost savings, such as reserved instances, spot instances, use savings plans, and enrolling in the best data-storage plans a CSP offers.

For example, reserved instances (RI) are available to Amazon Web Services (AWS) users under Amazon's Elastic Compute Cloud (EC2) and Relational Database Services (RDS) offerings. Two versions are available in one- or three-year contract durations. Standard RI plans offer an up to 72 percent discount on on-demand services but aren't as flexible as Convertible RI plans, which provide a 54 percent discount and let users trade attributes, such as family (i.e., workload characteristics), operating systems, and tenancy (i.e., isolated or secured partitions), between instance uses. EC2 lets users, in effect, rent virtual machines on which to run cloud apps, but users only pay for what they use rather than having 24/7 on-demand access. Under EC2, users can bid for spot instances, which occur at odd times when there may be available cycles on a server accessible by AWS or the CSP, enabling users to bid on using that capacity for specific workloads. RDS is a database management service that simplifies relational database operations in the cloud and automates selected frequent database administration tasks. However, effective buying of spot instance prices requires someone to keep an eye on pricing trends (via third-party tools) because prices fluctuate frequently due to supply and demand.

Another cost savings regarding data transfer fees can be realized by analyzing the fees charged by the CSP for moving data from one region to another. That information could justify optimizing the enterprise's cloud architecture to reduce data movement frequency, for example, by moving apps that require frequent data moves to run directly in the cloud rather than on-premises, to mitigate transfer needs. Diving deep into data transfer methods between the cloud and on-premise data may also uncover more economical ways of accomplishing those transfers.

Other areas where good information about actual cloud usage can help trim costs are optimizing storage, improving response times that may lag for certain activities, and bringing visibility to such aspects as costs related to regulatory requirements, managed service fees, serverless functions, backup and disaster recovery operations, and machine learning activities. Having data to show before-and-after costs will help with justification even more.

Storage methods may also provide some cost savings. For example, there are two main types of storage: block and object. Block storage is best for frequently referenced structured and transactional data and can improve performance over object storage if too much latency becomes a problem. Object storage is designed to more effectively handle lots of unstructured data and data that isn't accessed constantly. Using the right kind of storage can help enterprises trim a small cost that happens many times in a single day.

One idea that probably won't help as much as it seems like it might is to compare cloud operational expense data directly to former on-premises operations. Usage patterns under each system will be significantly different in too many ways, although throughput, uptime, and user response times under each system are worth comparing.

Maintain a Learning Environment

In sum, making cloud computing cost-effective is a moving target. The responsible group or department must monitor as many statistics about an enterprise’s cloud environment as it can afford to 1) gradually learn the profile of the system when it's working at its best, 2) identify cloud resources that, over time, are not being used as much as the original migration plan may have specified (and can therefore be modified), and 3) understand what enterprise resources need to be converted to being cloud-native rather than opting for maintaining familiar old processes just because they're less confusing to end users. Regular monitoring is necessary for tracking vital metrics such as hardware usage, bandwidth, disk I/O, and other system attributes mentioned earlier. Learning to right-size elements of the cloud environment is essential to achieving provable cost justification for moving to the cloud. Keeping even the end-users aware that the cloud is a new landscape can help keep minds open to further changes should they become necessary.

John Ghrist has been a journalist, programmer, and systems manager in the computer industry since 1982. He has covered the market for IBM i servers and their predecessor platforms for more than a quarter century and has attended more than 25 COMMON conferences. A former editor-in-chief with Defense Computing and a senior editor with SystemiNEWS, John has written and edited hundreds of articles and blogs for more than a dozen print and electronic publications. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..