A SaaS healthcare technology provider’s marketing homepage has been hosted on their application server’s since the company’s inception. This long-time AWS and Foghorn customer recently reached out looking for a way to have their website move to a WordPress site and to the WPEngine.
To assist the marketing team the application team first needed to figure out what URLs need to continue to go to their application server and which URLs need to get routed to their new WPEngine domain.
From the client’s engineering team Foghorn received a list of urls that they believed they needed to get routed to the application servers. But there was a lack of surety in the list, since the URLs had been set up this way for years.
Our FogOps Team working with the customer first thought it would be easy to put CloudFront in front of the applications and use Athena to query the logs. After reviewing AWS documentation, the logs did not contain the information about what rule was triggered. We could write a complex Amazon Athena that would figure this information out, but we wanted a sure fire way to ensure we do not miss any URLs and potentially cause downtime. We had to come up with a new plan.
Here’s a look at the two step process that we designed.
Phase 1: DynamoDB Research Phase
Technologies
- CloudFront
- Lambda
- Takes the request
- Gets the site URI
- Adds 1 to visits counts
- DynamoDB
- Partition Key: siteUrl (example: /web, /application, /etc)
- Visits: counter for the number of times it been hit
- Application Load Balancer
With all the rules that we knew about, we configured CloudFront. Then for the default rule we set up a lambda@Edge every time it’s triggered. The lambda would update the table and add 1 to the visit value.
response = dynamodb.update_item(
TableName=table_name,
Key={“siteUrl”: { “S”: key }},
UpdateExpression=”SET visits = if_not_exists(visits, :zero) + :inc”,
ExpressionAttributeValues={“:inc”:{“N”:”1″}, “:zero”:{“N”:”0″}},
ReturnValues=”UPDATED_NEW”,
)
Every couple of days, the client and myself would review the DynamoDB table and add any new URIs that showed up in there to our CloudFront behaviours. After a week, we were confident that we had all the behaviours configured for the application set-up properly. We then proceeded to phase two.
Phase 2: Routing to WPEngine
Technologies
- CloudFront
- Application Load Balancer
At this point in the transition process, all we had to do was to add a new origin to the WPEnginer, cut over the default behaviour, and remove the lambda at the edge. As an added benefit to creating this architecture we were able to configure CloudFront to act as a cache and speed up response time of the applications and decrease network egress bandwidth.
Our customer was thrilled with the final result. Foghorn was able to complete their homepage migration out of their SaaS application and into WP Engine. Their homepage is highly available, delivered at a lower cost, and easier to manage.
About Foghorn
Foghorn Consulting was founded in 2008 with a mission to ensure that cloud computing initiatives deliver maximum value for its customers. Based in the Silicon Valley, Foghorn provides domain expertise in strategy, planning, execution and managed cloud services to high-growth and enterprise companies seeking a cloud partner. Our team of DevOps engineers, SRE’s and certified cloud architects bring over 20 years of domain expertise to ensure your cloud initiatives are a success.
We invite you to chat with our team to learn more about what Foghorn can do for you.
