A high-level guide to modernizing AWS infrastructure: an AWS partner perspective

Blog Post, Thought Leadership

If you are reading this article then chances are you are in some way responsible for maintaining AWS infrastructure that underpins business critical applications. And maybe, just maybe, you have some pain points with that infrastructure.


As an AWS Advanced Tier Services partner, the Lambert Labs team works with many AWS customers and gets to see AWS
infrastructure in a wide range of conditions.

Some infrastructure is kept up to date and that is always pleasing to see!

We do, however, come across plenty of AWS customers that are experiencing pain points with their AWS infrastructure because they have not yet modernized. Broadly speaking, these AWS customers often have one or more of the following traits:

  • EC2-centric infrastructure: they are using Amazon EC2 instances in the same way as you might use a traditional data centre and are not making use of the full range of AWS services available.
  • Data immaturity: they are not prepared to take advantage of AWS’ (Gen) AI services because of limitations with their data quality, accessibility and structure.
  • ClickOps: they currently maintain their AWS infrastructure using ‘point-and-click’ as opposed to using templates via Amazon CloudFormation, Terraform or AWS Cloud Development Kit (CDK).
  • Single AWS account: they have a single AWS account housing multiple products, multiple environments or infrastructure for multiple customers. Alternatively, they have a poorly configured AWS Organization made up of multiple AWS accounts.
  • Incurring significant licensing costs: they are paying to run Windows and Microsoft SQL Server unnecessarily.

What is typically involved in AWS modernization?

AWS modernization will of course be different for each and every AWS customer, but it might involve any of the following tasks:

Decoupling/loose coupling

The old school approach to hosting web applications was, in many cases, to run ‘everything’ off one physical server or virtual machine. This might have included:

  • A web server
  • An application process
  • An email server
  • A database
  • A worker process
  • A job queue
  • A cache
  • A disk for file storage
  • A place to store logs

Now, all of these can be decoupled and modernized into cloud native infrastructure using AWS services. For example, for the list above:

  • A web server -> containerize and run on Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic Kubernetes Service (Amazon EKS).
  • An application process -> containerize and run on Amazon ECS or Amazon EKS.
  • An email server -> send emails using Amazon Simple Email Service (SES) instead.
  • A database -> use a managed database service like Amazon Relational Database Service (RDS).
  • A worker process -> containerize and run on Amazon ECS or Amazon EKS.
  • A job queue – > use Amazon Simple Queue Service (SQS).
  • A cache  -> use Amazon ElastiCache.
  • A disk for storage -> store files in Amazon S3 and if you need to serve them up to users, use Amazon Cloudfront.
  • A place to store logs ->  use Amazon Cloudwatch instead.

Decoupling is not limited to decoupling services from single servers. It can also be applied to:

  • Decoupling monolithic applications into microservices.
  • Decoupling single-VPC infrastructure into multiple different VPCs for different products, environments and customers.
  • Decoupling single-AWS-account infrastructure into multiple accounts in an AWS Organization.

Move to open source

This mainly applies to Windows workloads. If you are paying hefty licensing fees for Windows OS and/or Microsoft SQL Server databases, it is likely that you could benefit significantly from using open source technologies as an alternative. The cost savings can be gigantic.

Templating

If you manage your AWS infrastructure using ClickOps then replacing this with Infrastructure-as-Code (IaC) will be easier to manage in the long term. Three prominent options are Amazon CloudFormation, Terraform and AWS Cloud Development Kit (CDK).

Containerization

Once your applications are containerized it will be easy to run them locally using docker-compose and, as touched on in the Decoupling section above, you can use container orchestration services including Amazon ECS or Amazon EKS.

Serverless

Run containers serverlessly on AWS Fargate, make heavy use of AWS Lambda and migrate your databases to Amazon Aurora serverless.

What are the benefits of AWS modernization?

AdobeStock_938930914

Faster development

With containerized applications or microservices, you can speed up application development and deployment.

With serverless, AWS provisions and scales the infrastructure so that your team can focus on application innovation.
With IaC, you can quickly deploy a new instance of your infrastructure in a new AWS account, in a different AWS region or for a new customer.

AdobeStock_1035694914

Cost reduction

With modernized AWS infrastructure it is easy to autoscale up/down according to demand. This means that you remove costs incurred from overprovisioning to meet maximum demand if and when it occurs.

The cost of maintaining modernized AWS infrastructure is typically lower than the cost of maintaining out of date AWS infrastructure.

AdobeStock_984126069

Improved security

It is easier to stay up to date with security patches across applications and operating systems.

It is easier to implement Improved network security.

AdobeStock_1083692578

Improved staff morale and retention

Skilled technical employees generally want to work on modern workloads leveraging the latest technologies.

Is AWS modernization a one-off project?

This is not a straightforward question to answer, but, in a sense, it is the most important thing to understand for decision makers such as CTOs, CIOs, Infrastructure Managers or IT Managers before making the decision to modernize.

AWS infrastructure can be done as one-off project, but this comes with some caveats:

  • In order to keep up the high standards of your newly modernized infrastructure, you will likely need to set aside time/resources for maintenance.
  • Crucially, the skillset required to maintain your AWS infrastructure post-modernization might be considerably different to the skillset required to maintain your pre-modernization AWS infrastructure; you might need to train/upskill team members, or hire new personnel altogether.
  • It can’t be guaranteed that in 10 or 20 years time there  won’t be an even better way of managing your AWS infrastructure and you may have to re-modernize at this point.

We’ve modernized our AWS infrastructure – what next?

We find that our AWS customers tend to fall into two (very broad) categories post-modernization:

  1. The customer is happy with the improvements and efficiencies AWS modernization has created and no further action is required. In this case, the AWS modernization journey has perhaps solved some pain points but the customer does not immediately need to build more products/create more infrastructure on/using AWS.
  2. The customer is happy with the AWS modernization and they now want to supercharge their business, often by making better use of data, machine learning or AI.

    In this case, the AWS modernization journey has laid the foundations which enable the customer to explore making use of a wider range of AWS services, for example:
  • Using Amazon Q to get insight from business data across many sources.
  • Building chatbots and  RAG applications with Amazon Bedrock providing access to LLMs from Anthropic, Meta and Amazon.
  • Extracting and cleaning your data with Amazon Bedrock.
  • Generating new content with Amazon Bedrock.
  • Using Amazon Redshift to enable fast querying and analysis of large volumes of data.

What is Lambert Labs’ approach to AWS modernization?

When we work with an AWS customer to modernize their infrastructure we typically start the engagement with an AWS-funded AWS Well-Architected Review. This allows our team to assess the AWS customer’s infrastructure against the six pillars of the AWS Well-Architected Framework:

  • Security
  • Reliability
  • Cost optimization
  • Operational excellence
  • Performance efficiency
  • Sustainability

The review will identify which areas of the customer’s AWS infrastructure adhere to the AWS Well-Architected Framework, but will (nearly always!) highlight some areas where there is room for improvement. These areas for improvement are usually then addressed through AWS infrastructure modernization.

If you would like to speak to the Lambert Labs team about your AWS modernization journey, please get in touch.