AWS Backend solutions

Amazon Web Services (AWS) is a leading cloud provider with dozens of services, offering a flexible solution for your workloads. However, the sheer number of AWS products and services can be overwhelming, especially for newcomers to the field or developers used to a more traditional cloud provider that only offers virtual machines (VMs).

Making the switch to AWS will require different approaches depending on your workload. To get the most out of AWS for your application, it’s best to start from scratch and take the time to get into the specifics of its unique services. There are also more traditional approaches available if you have legacy systems requiring VMs or containers—or just don’t have time to become familiar with the idiosyncrasies of AWS.

The virtual machine approach

The VM approach will serve you best if your application is on the legacy side or you need complete control over every aspect of your infrastructure. With Elastic Compute Cloud (EC2), AWS offers a state-of-the-art VM service with dozens of different machine types—some even with GPUs and other dedicated hardware.

Large applications developed over the years—or even decades—are often hard to restructure; at the same time, a complete rewrite can pose several risks. Using VM services directly is an excellent way to profit from the cloud.

Some applications have particular requirements regarding performance, security, or operating system, making a VM approach—where you can bring your tweaked operating system (OS) images—a great option. If your app is based on a unikernel approach, VMs might also be your only choice.

The VM approach also allows you to run all the software you need, host your database installation, or set up a Kubernetes cluster from scratch without directly relying on AWS-specific services. If lock-in is something you fear, this is how to avoid it.

With autoscaling, you can start and stop VMs automatically, depending on your traffic; this gives you at least some flexibility in the cloud, even when not using serverless.

The trade-off is higher maintenance costs, because you’ll need to handle the OS and VM versions yourself with the VM approach. That said, AWS offers a variety of OS images, and many of them come with the essential software, like preinstalled web servers.

The container approach

The container approach is more flexible than the VM approach we have just covered. The container approach is great for scenarios where you need more flexibility than VMs can provide, you don’t want to use AWS-specific services, or you already have containerized applications.

AWS provides two container orchestration services: Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS).

As ECS is AWS’s homegrown solution, it integrates well with other AWS services. The downside is that you cannot reuse it outside of AWS.

EKS is AWS’s Kubernetes-based solution. It’s AWS agnostic—much like using custom VMs are more or less the same on all cloud providers. But EKS is also a black box for other AWS services, so integration takes considerably more time. If you already have a Kubernetes deployment or significant Kubernetes know-how, EKS is worth considering.

Both services can use Fargate, an automatic VM provider. Typically, a user would manually assign VMs to container clusters, but Fargate can do this for the user, saving time and effort configuring AWS services when running Kubernetes.

The serverless approach

When you build a system on virtual machines or containers, you must consider server maintenance. You must keep the OS and infrastructure configuration up to date. With serverless infrastructure, this is no longer a concern. Anything that can improve the service and doesn’t require code changes from your end will be managed by the cloud provider. This doesn’t mean maintenance is a thing of the past; however, the serverless approach allows the focus to be on your application.

For example, AWS will ensure that your functions' underlying OS and scheduler are updated and bugfixed, thereby improving their performance without you having to act. Beside the optional costs for data storage, these services are usually free of charge when not used, so you don’t need to pay for idle resources like you would with a VM.

On the downside, you will likely need to restructure your application architecture with AWS-specific services to get the most out of them—DynamoDB instead of a custom MySQL installation, for example, or Cognito instead of your own user management.

AWS Lambda is a generic code execution service that combines different services and lets you add your business logic. You can upload code with up to 50MB ZIP archives or up to 10GB Docker images. This makes Lambda an extremely flexible solution, even for more extensive code bases.

S3 is the go-to solution for static files. Every file you need for your application—from code through configuration to user media—can reside in it. Furthermore, your S3 buckets can trigger other services when an upload is initiated; they can even act as a web server.

Meanwhile, DynamoDB is the serverless database of AWS. You only have to create tables that hold your data as JSON documents. On the one hand, your SQL skills might not work here. On the other hand, DynamoDB is well integrated with AWS services.

Finally, API Gateway serves as the central entry point to your backend. It integrates with IAM and Cognito to answer all auth needs, from authenticating in-house users to customer registration workflows.

Summary

AWS offers multiple ways to build and deploy your backends: from VMs through containers to serverless.

The VM approach with EC2 is suitable for legacy systems you want to lift and shift into the cloud, and for individual requirements such as unikernels and other custom OS configurations.

If you possess container know-how or don’t want to get too deep into the AWS ecosystem, EKS can be an ideal solution. For a more gradual immersion into AWS, ECS can be a good option, especially if your plans involve adopting more AWS services in the future.

Finally, serverless is the way to go when building a new project. It keeps maintenance tasks to a minimum, can run for free when idle, and gets regularly and automatically updated. However, teams often need training beforehand because serverless, with all its use case–specific managed services, requires completely rethinking the backend.