16 Questions you should ask AWS before proceeding

Purpose-built services from Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure are fast becoming the easy button for application building, replacing 3rd-party platforms and custom code with configurable functionality that can be stitched together quickly. The prospect is appealing and often viable.

Aggressive selling from these organizations paints a rosy picture of what can be done. In the following article we’ve drafted a list of questions you should ask your AWS/GCP/Azure sales team or integration partner to help you make a clear-eyed assessment of the real benefits and risks.

Configurable cloud services have democratized custom software like never before. With a little expertise and a lot of tenacity, businesses can realize real value by solving increasingly complex challenges with thoughtful, discreet, curated tools. What’s more, they’re managed and priced such that you have an engineer’s level of granularity around what to use and how much to spend. Unfortunately, it’s that granularity that gets buyers into trouble after their purchase.

From our seat, modular cloud services have been a positive, if readily-misunderstood technological shift that helped software engineers and software buyers overcome historical challenges like:

• Generalized platforms. “Everything” platforms solve problems partially, requiring custom-on-platform or adjacent custom code. You’re buying a subscription and paying to build something that can’t be used alone. Examples include first-generation IoT platforms and older CMSes and repositories that users over-customized (SharePoint).
• Encyclopedia solution. Early componentized mega-platforms usually provide checkbox, milquetoast solutions to every problem in a given vertical. See: Salesforce.
• Portfolio platforms. These solve an expanding array of problems with an equally expanding array of partners or “interconnected” products but are actually tightly-coupled bundles of necessary solutions. This is what Google Cloud and Azure used to be.
• Ecosystems. Solve 40% of your problem but also include a philosophy you’re supposed to follow. The requisite marketplace addresses the remaining 1200% of your problem. Atlassian, WordPress, and Salesforce are the best-known examples.
• Reframed platforms. Adding fractional new value to long-standing systems by rebuilding them on “the cloud” or adding a slightly enhanced interface, causing you to move to get the same thing + 0.01% improvement. ERP and SCADA systems are the prototypical victims here.
• Custom-for-custom-sake. Solving specific problems again because other solutions fall 5-15% short of expectations. This is where an engineer will lead you without supervision.

Today’s cloud services providers learned well from these scenarios (as observers or perpetrators) and have crafted offerings that eliminate many of the spurious claims of methods past.

Cloud providers’ sales teams understand what they’ve achieved with modular services. Their arsenal of exciting tools and compelling stories makes it hard to sift through the post-meeting excitement to discuss solution-specific pros and cons. Their sellers will mitigate any lack of technical knowledge on your part with glittering generalities about ease-of-use, no-code, etc. Any doubts you may have about applicability of something are bandied aside with promises of future fit or current flexibility.

We’ve seen clients walk away from early meetings feeling amazing, and grossly under-informed about the excellent technology and future considerations they’re agreeing to.

The real value of a modern cloud offering is always eclipsed by the dream state depicted by the provider’s sales team. You can understand and extract that real value from any modular cloud services provider by asking the clarifying questions below.

Note: We reference AWS (Amazon) regularly below, but every question will be relevant to a Google Cloud or Microsoft Azure project, as well as custom software that a vendor may be building for you.

Initial and future costs

A clear picture of your future costs is the first evasion, but an unnecessary one. All modular cloud services tooling is built to measure and therefore built to price. Cloud pricing is based around things like:

• Commodity use including storage, bandwidth, transmission. Measured in volume of resource, often multiple places.
• Configuration including memory, cores, read/write, etc. Measured in $/min or hour.
• Features including firewalls, restrictions, bundles, etc.

Figuring out which resources you use in what quantities is not trivial. AWS sales teams will often defer cost questions to later stages, citing “free tier” and growth modeling but your first questions should be around future costs.

Question 1: “Can you send me a completed AWS calculator quote that will represent the complete list of services used?”

This will get you baseline pricing based on some guesses but won’t uncover the real price risk: growth. Some examples:

• Addingg another server adds its own cost, then also increases storage, bandwidth, IP address use, routing, and firewall costs.
• A sudden spike in machine (language) translations due to increased usage interest might create a runaway translation cost as well as increased storage and transmission costs.
• Service coverage due to logging or debugging creates hidden storage and transmission costs as applications or dev/QA teams scale.

To address these, we also suggest:

Question 2: “Which specific items will change when we grow to ____ or add _____?”

This should be a matrixed answer based on what you’re measuring for, but should include every aspect of your application as well as every cost line item those aspects require to operate.

Question 3: “Can you send me additional calculator quotes representing my application running in production and staging, with ____ customers doing ____ things?”

Question 4: “Where do you foresee my costs exceeding expectations as we grow?”

Finally, make sure you’re pricing your entire application including development, staging, and production environments as well as regional copies of infrastructure. Some services are globally accessible while others are (rightly) copied to a region closer to your customers.

Question 5: “Can I get a detailed breakdown of the environment and regional impact on my total price?”

Operating budget

All cloud providers offer cost controls including budget management, alarms, etc. This should be the first thing you configure before anyone is allowed to create solutions.

Question 6: “Where do I manage my usage budgets?”

Paradoxically, these budgets may cause customer issues if you exceed your planned limits but miss the relevant alerts.

Question 7: “How will cost controls affect service performance and availability and how should we remediate this risk?”

Initial configuration (starting with users)

During early-stage conversations you’ll hear things like “you just do ____ and it will ____.” The word “just” is your cue to pause the meeting and seek help. You’ll see this pop up first when discussing users (AWS permissions are complex). Something that should just take an AWS employee a few minutes to solve will likely take your team hours to sort through documentation and solve.

Question 8: “Can you assist my team (directly) in setting up key users and roles across our departments?”

Service selection

AWS offers many paths to the same end, for example:

• Multiple database types, each often solving the same problem different ways
• Core architecture plans which allow different ways of scaling
• Overlapping products (including some legacy) that can address the same thing differently

Many of these choices wont make sense for non-technical stakeholders but your engineers will have preferences. For each technical discussion/decision, it’s worth asking:

Question 9: “How will ____ choice impact our overall experience versus its alternative?”

Question 10: “Is there a more cost-effective way to do this without compromising experience?”

Having finance, compliance, and legal listening in on these conversations is a great way to elevate service selection to the whole business where it belongs.

Adjacent non-AWS costs

All new software has hidden costs. Moving from a hosted solution to a custom one built on AWS means you incur new costs that used to be someone else’s problem. They include but are not limited to:

• User account management. This used to be an appendage to your organization but is now part of your core business.
• Version management (not the code, the infrastructure). This is different from dev > stage > prod. This is production-over-time.
• Log management. Logs are a vital, chronic cost offender and need to be addressed as a part of the whole system.
• Uptime monitoring. AWS offers some of this, but it’s gnarly. Gone are the days of calling someone for an update. You’re the someone now!
• Documentation (developer and user). The third rail of engineering is now your critical-path problem.
• Operating procedures. Again, you’re the one people will call now. You’ll need a plan.
• Ticketing. You probably have a help desk for consumer issues, do you have a technical one that can handle infrastructure tickets?
• Compliance (CCPA, GDPR, etc). AWS provides compliant hosting services, but it’s your responsibility to do the actual complying. Have legal in your first meeting, invite them often.

Most of these will cost you money outside your AWS spend. Fortunately, they’ve seen all this and can direct you to resources and help you estimate costs.

Question 11: “What aspects will we need to add to make our application work within AWS that you don’t offer?”

For each item you can’t address internally:

Question 12: “Can you direct us to someone who can help estimate ________?”

New staffing required

If you’re considering an AWS solution, you should be considering future staffing before you commit. If you’re moving from a platform or 3rd-party product to your own solution, this can be a jarring rise in staffing.

• DevOps. People who know how to deploy, operate and troubleshoot your infrastructure.
• Testing. Your QA team not only has to cover your code, they now have to cover your infrastructure.
• Support. This includes both customer support (which you likely have, but not at the capacity you might need) and developer support (which your team may have received from previous vendors).

This is another area that was someone else’s problem that will soon be yours. Luckily, it’s also a well-trod path for your AWS team!

Question 13: “Can I get a list of recommended staff seats to support our planned application?”

This brings up two more questions:

Question 14: “What can I expect for each salary?”

Question 15: “Do you have a job description for each role that also accurately describes our needs with your tools?”

Referrals

You’re already planning to ask for referrals, so our last question recommendation is more about framing the overall discussion to surface a batch of referrals covering multiple axes to answer specific questions:

Question 16: “Can we get emails for referrals:

1. To similar businesses. This will uncover like problems you will encounter with implementation
2. Using similar technology or architecture. This is where you will find hidden costs discussed.
3. At similar stages of delivery. This will be most helpful for learning about in-the-moment frustrations that are forgotten once a product is live.”

You should plan 6-9 conversations to cover those three key areas of inquiry. It’s important that you get enough variety to overcome any favored-customer/quid pro quo facade. Ideally, they send a list of possible referrals in each question group from which you pick.

Fulfilling the promise

Modular cloud services like AWS are helping deliver on the decades-old promise of technology as a value-delivery tool. Coming prepared with the right questions will make the difference between adding new value to your organization or just adding value to AWS.

---

Next Mile can help guide you through early stage cloud service planning. Contact us if you need expert advice before making a major commitment.