This phase will help you build a business case for moving to the cloud. Aspects to consider could include the list from the preceding section. Other items could of course be added:
It is not that simple to compare current on-premise and co-location costs with AWS. It requires some thought and work. It can be said that most C-Suite Directors view AWS as cheap, free, or a source of unlimited magic at no cost. Training staff, buying tools, automating, changing processes and operational management of AWS are seldom fully considered.
There is a basic TCO methodology given below, which relies on Amazon EC2 Cost Calculators which use industry data, AWS customer research, and user-defined inputs to compare the annual fully-burdened cost of owning, operating, and maintaining IT infrastructure with the pay-for-use costs of Amazon EC2. RightScale and other CMP (Cloud Management Platform) vendors, and Cloudberry (Cloud backup) also provide compute resource price comparisons.
Note that the table below compares only the direct costs of the IT infrastructure and ignores the many indirect economic benefits of cloud computing, including high availability, reliability, scalability, flexibility, reduced time-to-market, and many other cloud-oriented benefits. Decision makers are encouraged to conduct a separate analysis to quantify the economic value of these features.
| Pricing Model | One-time Upfront |
Monthly |
|||||
| AWS | Co-lo | On-Site | AWS | Co-lo | On-Site | ||
| Server Hardware | 0 | $$$ | $$ | $$ | 0 | 0 | |
| Network Hardware | 0 | $$ | $$ | 0 | 0 | 0 | |
| Hardware Maintenance | 0 | $$ | $$ | 0 | 0 | $ | |
| Software OS | 0 | $$ | $$ | $ | 0 | 0 | |
| Power and Cooling | 0 | 0 | $$ | 0 | $$ | $ | |
| Data Center/Co-located Space | 0 | $$ | $$ | 0 | $ | 0 | |
| Administration | 0 | $$ | $$ | $ | $$ | $$$ | |
| Storage | 0 | $$ | $$ | $ | 0 | 0 | |
| Bandwidth | 0 | $$ | $ | $$ | $ | $ | |
| Resource Management Software | 0 | 0 | 0 | $ | $ | $ | |
| 24X7 Support | 0 | 0 | 0 | $ | $ | $ | |
| Total | |||||||
Table: Cloud TCO Calculation Example (some assumptions are made)
You can estimate your monthly costs using the AWS Simple Monthly Calculator.
Note that this is not entirely accurate and usually the costs in reality will be higher as the platform usage matures.
AWS is more secure – or can be made more secure – than most on-premise or data centers. AWS’ security model is a shared model. AWS takes care of the security of the physical infrastructure; you must secure the application, databases, networks and data.
Data security can be a daunting issue if not properly understood and analyzed. Hence, it important that you understand the risks, threats (and likelihood of those threats), and then based on sensitivity of your data, classify the data assets into different categories (discussed in the next section). This will help you identify which datasets (or databases) to move to the cloud and which ones to keep in-house. It is also important to understand these important basics regarding AWS Security:
For more up-to-date information about certifications and best practices, please visit the AWS Security Center.
Figure: Security
Enterprises need to assess which applications to move into the cloud first, which applications to move later and which applications should remain in-house, which need to be rewritten, and which others will be decommissioned. In this stage of the phase, enterprise architects should ask the following questions. The following framework can be applied. We can then rank application readiness by putting applications into these categories, and estimating costs to cloudifying the applications.
Figure Classification of Apps for the Cloud
Application analysis should also include a thorough examination of the logical constructs of your enterprise applications including their dependencies, risks, and security and compliance requirements. We need to create a dependency tree that highlights all the different parts of your applications and identify their upward and downstream dependencies to other applications. Create a spreadsheet that lists all your applications and dependencies or simply “white-board” your dependency tree that shows the different levels of interconnections of your components.
This diagram should be an accurate snapshot of your enterprise application assets. We need to map out all IS assets including: ERP systems, HR services, Payroll, Batch processing systems, backend billing systems and customer-facing web applications, internal corporate IT applications, CRM systems, existing SaaS, COTS and off the shelf apps. We should also include DNS, AD or LDAP servers.
Figure: Example of whiteboard diagram of all the IT assets and its dependencies (Dependency Tree). AWS image.
After you have created a dependency tree and have classified your enterprise IT assets, examine the upward and downward dependencies of each application so you can determine which of them to move to the cloud quickly.
For a Web-based application or Software as a Service (SaaS) application, the dependency tree will consist of logical components (features) of the website such as database, search and indexer, login and authentication service, billing or payments etc. For a backend processing system, interconnected processes like workflow systems, logging and reporting systems and ERP or CRM systems, will be present. You could move the CRM for example into AWS and connect a parser and loading database with the batch system on-premise.
Post-it Note: In most cases, the best candidates for the cloud are the services or components that have minimum upward and downward dependencies. Identify systems that have fewer dependencies. Some examples are backup systems, batch processing applications, log processing systems, development, testing and build systems, web-front (marketing) applications, queuing systems, content management systems, or training and pre-sales demo systems.
To help identify which workloads are good candidates for the cloud consider this list:
Quite likely you can reuse most of your existing system tools and/or add AWS support very easily. All AWS services expose standard SOAP and REST Web Service APIs, and provide multiple libraries and SDKs in the programming language of your choice.
A business justification and ROI calculation is mandatory. There has to be visibility into the costs and benefits of moving into AWS. Financial and Business rationales for moving into AWS could include (examples only):
| Success Criteria | Old | New | Examples on How to Measure |
| Cost (CapEx) | $1M | $300K | 60% savings in CapEx over next 2 years |
| Cost (OpEx) | $20K/Year | $10K/Year | Server-to-Staff ratio improved by 2x 4 maintenance contracts discontinued |
| Hardware procurement efficiency | 10 machines in 7 months | 100 machines in 5 minutes | 3000% faster to get resources |
| Time to market | 9 months | 1 month | 80% faster in launching new products |
| Reliability | Unknown | Redundant | 40% reduction in hardware-related support calls |
| Availability | Unknown | At least 99.99% uptime | 20% reduction in operational support calls |
| Flexibility | Fixed Stack | Any Stack | Not locked into particular hardware vendor or platform or technology |
| New opportunities | 10 projects backlog | 0 backlog, 5 new projects identified | 25 new projects initiated in 3 months |
Table 4: Examples on how to measure success criteria
By documenting the dependencies, creating a dependency tree, and identifying the tools that you need to build or customize, you will get an idea of how to prioritize applications for migration, estimate the effort required to migrate them, understand the one-time costs involved and assess the timeline. It is advisable not to skip over this step and quickly directly to a pilot project. The pilot or proof of concept (POC), should be based on a clear understanding of the items listed in this section.
Figure: Migration Plan
This would conclude the first phase of migrating to AWS.
