Using AWS Managed Services in an Enterprise Environment

AWS offers a wide variety of services to make modern application development easy. No matter what type of application you’re building, you can focus on your application code by mapping your architecture to these managed services.

You should be able to…but working in an enterprise environment where you need to comply with requirements from an internal security team may add nuance to your application that makes using managed services much much harder. Documentation often only covers the happiest of happy path scenarios, and some services may have subtle feature gaps that can impact your architecture.

This can drive you towards using “primitive” AWS services: running your application on an EC2 instance behind an ALB. This is much more expensive, less secure, and harder to maintain. The responsibility of keeping your servers patched, and your application healthy falls on you.

Over the next four blog posts, we’ll be covering how we at Expedia Group made AWS Managed Services work for us, while still remaining in compliant with both privacy laws and and internal security policies.

So first, what kind of application is this?

Employee Onboarding

Human Resources is not a place we typically think of when it comes to cutting edge software development. But at the Expedia Group, technology and cloud adoption is everywhere, including our Human Resources department. We had a very real software need: securely collect data about newly hired employees around the world. Expedia Group employs people from over 60 countries, and only a handful of people are staffed to help new hires through on onboarding process.

Each country has different requirements about what data we need to have about our employees. Mandatory data in some countries, might be illegal to ask for in others. And while our people management software can accommodate for those differences, new hires are not allowed to have access to that interface until their official start date.

So, we needed an interface we could expose to new hires before their start date for them to provide this required data such that it would save directly into our people management software.

Application architecture

Let’s start with our people management software. It needed a way to alert our application that a new hire was ready to receive access to the onboarding form. While the software allows for robust customization with its own IDE, it is somewhat limited when it comes to interfacing with other systems. It relies on a pattern of outputting files somewhere for a dependent system to pick up to do what ever processing is necessary. In practice, it looks something like this:

But the software does support GET requests. So we adopted SQS to allow the system to add new items to the queue. A lambda expression then runs on a timed looped to process new entries on the queue to give those new employees access to the onboarding form. The SQS queue is secured behind API Gateway, requiring an API key to be accessed. It ended up looking like this:

API Key? Why not IAM? Again, our people management software has very limited capabilities when it comes to interfacing with other systems. While it has it’s own IDE, it’s a drag-and-drop interface, not a text editor + compiler. The queue is only used to alert the system of new employees to be processed.

At the other end of the application, the UI is a React app served up using Lambda and S3, with the Serverless framework, and relies on AWS Cognito to get IAM credentials to use our other APIs secured with API Gateway.

React app? Lambda? Why not just serve it directly out of S3? At time of writing, such an architecture would’ve meant making the S3 bucket publicly readable, which is something not acceptable to our internal security team. Also, as will be discussed later, having some amount of server side rendering will be helpful.

In between the SQS queue and the UI, is an API to federate requests. This makes controlling access to our people management software easier, and it makes development of our UI simpler. Our people management software exposes its data primarily by means of a SOAP API, something not well supported in modern app development.

This API also controls which fields appear on the form for each country. So when the UI makes a request to the API, it gets a list of all the fields for the relevant country, with data prepopulated if we have it.

The API is a dockerized NodeJS app running in Fargate behind API Gateway that is secured with IAM permissions.

Making it work

Does any of this architecture sound appealing but unrealistic given your environment? We thought the same thing. But through research and experimentation we were successful.

Over the next four blog posts, we examine:

• Designing APIs to be modular, deployable, and secure
• AWS Cognito + AWS Lambda + Serverless Framework + React with Redux
• Using API Gateway for Authorization and Authentication
• Case Study in Modular Design

Conclusion

We’re looking forward to sharing what we’ve learned from over the last year and hope that you’ll be able to take our ideas and evolve them.

Please enjoy the next blog post Designing APIs to be modular, deployable, and secure by Sarah Purhar.