Welcome to 'This is My Architecture.' I am Hawn and today I am joined by Matt from
Replicon. Welcome, before we get started tell us a little bit about Replicon. - Replicon is a
SaaS based software company we build a time tracking and project management solution and we're hosted on AWS.
Awesome, so what does a typical user do when they sign up with you?
So a typical user when they interact with Replicon systems and we have that here in the architecture
diagram, as these users down here. They get onboarded and they get put into a shared
multi-tenant system, that's this Aurora system over here so when they access our application
they're going to be going through an API Gateway accessing a set of shared business logic, which
is a combination of EC2, ECS, and EKS systems. And then ultimately their data will be stored
in the Aurora system that is backed by Replicon's platform provided KMS key for encryption at rest.
So if there is a requirement for customers that have more compliant regulatory needs what does that
look like? - That's where we get to these enterprise users up here the enterprise users tend to come
in and require a little bit different security story than the more typical users. And what they'll
do is they'll - within their own AWS account, provision a AWS KMS CMK and they'll share that
with our account through a CMK key policy we'll end up provisioning dedicated data storage systems
to support their needs. So this Aurora system will end up being encrypted with this KMS key
So you pull the KMS key from the customer environment into the Aurora to basically
encrypt the data, is that correct? - That's correct. Yeah so all the data ends up getting encrypted
at rest when these Enterprise users end up accessing the system they'll still be
accessing the same shared API Gateway system in the same shared business logic components,
but now their data is being stored on a separate database server.
What we have down here is a system that we call our Inter-Infrastructure Intelligence or I3 for
short, and it's a Fargate-based application API with a DynamoDB backing store and every time the
business logic tries to read, write, or otherwise access the data systems, it's going to access the
I3 system. It's going to ask the question "hey I am Customer A where do I go to access my data?"
and that's where the business logic will end up being routed between the shared multi-tenant
Aurora system or between the dedicated enterprise-provisioned Aurora system. - Gotcha, and so with that
because they're using their own KMS keys, that really emphasizes some level of a shared security
model. Is that correct? - That's right, there are a number of responsibilities that come along with
this so first of all is there's a higher cost involved with onboarding and bringing these
customers into our system because we're going to provision dedicated Aurora systems which have a
high amount of overhead and we're going to pass that cost along to the customer. But ultimately
they're also going to be responsible to make sure that they maintain availability for this KMS
key. If they ever do something like forget to spend or pay their AWS bill and we lose access to this
KMS key, their data is going to be encrypted at rest in the Aurora system but no longer be accessible.
So truly a separation of concerns for compliance regulations, right? - That's right, so ultimately what
they're going for when they onboard in this kind of system is the ability to manage and own
this KMS key and have complete autonomy over it. And therefore all the data that's stored in our system.
Well thank you so much for going over your architecture. That's amazing how you're enabling a
multi-tenance capability to allow customers to retain control of their keys. That's
awesome, thank you. - Thank you Hawn. - And thank you for watching 'This is My Architecture.'