Implementing AWS Outposts to solve real world problems

This blog is the second part in the series on AWS Outposts. If you have not worked on AWS Outposts, I suggest read my previous blog where I have provided an overview of AWS Outposts.  

As I have indicated in my previous blog, AWS Outposts is tailored made for scenarios such as local data storage, low latency processing and Hybrid Cloud use cases. In this blog let us look at how we can use AWS Outposts for solving some of these problems using 2 use cases. 

Use Case 1: Customer has a local data storage requirement i.e. No data at rest or no databases on Cloud.  

Solution: Let us look at how we can setup a simple 3-tier architecture (consisting of a Presentation layer, an application layer and a data layer) using AWS Outposts and Cloud, to address this use case.

Infrastructure setup -

• For the purpose of this blog, we will consider a simple AWS setup with 1 region and 1 AZ. Our VPC consists of 3 subnets, 2 private and 1 public.
• AWS Outposts sits on one of the Private Subnet while our data processing API’s are hosted on Amazon ECS on the other private subnet. The Public subnet too consist of Amazon ECS which hosts the data distribution API’s.
• The data processing API’s on the Amazon ECS are triggered via the Amazon CloudWatch.
• Since we have considered 1 region and our data distribution API’s are hosted on 1 subnet, we will use a Network Load Balancer (NLB) which is connected to an AWS Route 53. (Remember - We have considered a simple AWS setup with 1 AZ. Application Load Balancer requires at least 2 or more AZ’s, and so I am using a NLB here).
• Since the requirement is for local data storage, we will not use Amazon RDS on the AWS Outposts as AWS Outposts RDS backups are taken to Cloud. Instead, we will install our own database such as MySQL on the Amazon EC2 with data stored on the connected Amazon EBS. This Amazon EC2 and Amazon EBS will be part of the AWS Outposts infrastructure.
• We can choose to allocate a part of the Amazon EBS as file landing zone to land the files from on-premise before loading into the database hosted on the Amazon EC2. Alternatively, we can choose an instance type which provides a large instance volume for holding the files before processing and loading them to the database.

Architecture in motion –

• To this simple, Amazon CloudWatch is scheduled to trigger the data processing API’s hosted on the Amazon ECS. The API’s read the data from the files in the landing zone, transforms the data and loads the transformed data into the MySQL database.
• The data is stored on the encrypted Amazon EBS volume attached to the Amazon EC2.
• The distribution API’s are hosted on Amazon ECS. The Network load balance sits in front of the Amazon ECS and the NLB is in turn connected to an Amazon Route 53.
• Customer traffic coming through the Amazon Route 53 flows through the NLB to the Amazon ECS data API’s which in turn service the requirement working with the MySQL installed on the Amazon EC2 and Amazon EBS in the AWS Outposts.

 

Putting it all together –

• Here we have used AWS Outposts on a private subnet to host the customer data. AWS Outposts physically sits on-premise and thus satisfies the local data storage requirement.
• The processing and distribution API’s are on Cloud on a different subnet. However, since the AWS Outposts, the data processing API’s and the data distribution API’s are all on AWS, they can all communicate with each other using the Amazon EC2 Private IP’s and all traffic between the subnets are within the AWS network. (Remember – As I mentioned in my previous blog AWS Outposts can be treated just as another subnet within your VPC).
• If you do not want to use Amazon ECS, you can use other options such AWS Batch, AWS Glue, Amazon EMR, Amazon EKS etc in this same architecture.  

 

Use Case 2: Customer requires low latency access to data on Cloud. (There is no local data storage requirement. The customer is only looking for a low latency access to the data).

Solution: We can use AWS Outposts with almost the same setup as I have explained for Use case 1.

• Since customer is looking for low latency access to the data, lets look at leveraging the power of Amazon RDS. So the only difference here will be instead of installing your own database on Amazon EC2 on the AWS Outposts, we will use Amazon RDS on AWS Outposts.
• This way your on-premise applications will have low latency access to Amazon RDS all the while using the same AWS API’s for your needs.
• The Amazon RDS in this case can save its backup to the AWS region to which it is connected.
• The rest of the architecture can follow what we saw for Use case 1 above.

~ Narendra V Joshi