This is part 2 of a multipart series on how to port an app from Microsoft Azure to AWS. To read part one, click here. In part 2 we'll dive into planning a bit more, as well as take a look at our sample app. For the sake of ease, let's assume that there will be no changes to the app itself.

More with the research and planning?

In the last post I touched on researching, making a plan, and documenting everything. While the ultimate goal is to have a functional app deployed in AWS, we can also set smaller goals while moving through the process. Your overall plan may include many smaller plans for each part of of the port over. Unless you're under a strict deadline, take your time with planning. Your future self will thank you.

A critical part of research and planning is knowing your current infrastructure. Make sure you have a clear understanding of your setup, including

  • Security: how is data secured? How are authentication and authorization handled? What kind of encryption is used?
  • Services: what services does the app use? What resources do those services use? How do those services interact with one another?
  • Costs: how are current costs being measured?

Remember to document this information!

The App in Azure

Let's say you're hosting the de facto Todo List App in Azure. Users must authenticate to use the app. The todo lists and their entries are saved in a NoSQL database. Users send API requests that trigger functions to edit the list. These functions are not run from a server. This app uses

  • Microsoft Entra ID for user authentication
  • Azure Functions for the app's function code
  • Azure API Management for handling API calls to the app's functions
  • Azure Cosmos DB for storing the lists and todo items

You've identified and documented the resources allocated to these services in Azure. You know what you're paying for and why you're paying for it. You've got security on point. You're pumped. You're ready. How do we make this app in AWS?

Planning the Port

If you haven't started already, now would be the time to research the AWS equivalents to the services you're using in Azure. For our todo app, we'll be using

  • AWS Cognito for user authentication
  • AWS Lambda for the app's function code
  • AWS API Gateway for handling API calls to the app's functions
  • AWS DynamoDB for storing the lists and todo items

I won't include my pages and pages of notes and hyperlinks, but here is a simple diagram:

For a simple app like this, AWS offers a free tier that includes the above services, so cost isn't a factor here. The free tier is more than enough to get started with an app this small. However, this can dramatically change when you're planning something larger. Keep track of how costs are measured for the services you'll be using. Research pricing models and tiers. AWS has a budget tool in its Cost Management console, which may help you in comparing your current costs to what you might be paying to AWS.

If we wanted to scale the todo list app to handle thousands of users, API calls, and function executions, we'd keep the following in mind

  • AWS Cognito is billed by the number of Monthly Active Users (MAUs).
  • AWS Lambda is billed by the number of function executions and the duration of those executions.
  • AWS API Gateway is billed by the number of API calls.
  • AWS DynamoDB is billed by the number of read requests and write requests, independently.

Next Steps

Now that we have a plan for what services we'll need, we can start building them out in AWS. In the next posts, I'll show you how to configure each of these services to get our app up and running.