Making memories is the overarching motivation for most of my outgoings (both physical and monetary). Holidays, nights out, parties, barbecues… those are my favourites. But, what happens when you trust an online service to look after these most treasured memories? What confidence do you have that they are making the right decisions to protect them?

There’s been a lot of buzz in the last 6 months about data privacy; what it means to the public and the companies that they trust their data with. What this article will focus on is how it impacts engineers.

At Popsa, we’re big on memories. We’re here to manifest your favourite memories back into the physical world by printing your best photos into lovingly curated books (among other things), and we take it seriously.

In the Popsa platform, we have made security and privacy the first considerations in our architectural design decisions, and not because of GDPR or other meme-generating regulations, but because trust and integrity is fundamental to building a business. From encrypting your personally identifiable information (PII) wherever it sits at rest in our platform to separating concerns by enforcing the principle of least privilege for every person or machine that needs access to some piece of data.

We use AWS to host our platform. We have APIs running as microservices on ECS and some running serverless as Lambda functions, we have our data at rest in S3, DynamoDB, etc., and we leverage a swathe of AWS managed services like IAM and KMS to help us on or security mission.

This is the first of a series of posts on this topic. Read on to read about a fundamental foundation of making security a reality in AWS; account strategy. In future posts, I’ll talk about encryption, data pipelines and obfuscation and more.

AWS Account Structure

We adopted AWS account design best practices. For us, an AWS account is dedicated to a singular function. For example:

• Our production services live in one account, and lower environments have their own accounts. Authorisation for these different environments is different.

• All identities (IAM users and groups) are in a dedicated account, and we use role based access control (RBAC) via IAM roles and trust relationships in the other accounts to determine who can do what and where. For example:

  • as a platform engineer, I can access most things in most accounts

  • our data scientists can only access the data they need which is funnelled into the data science accounts, and they can only perform the actions which needed to perform the data voodoo they do

• And, you guessed it, we have data science accounts which host the data and tooling required to perform said voodoo

Here’s a diagram which gives a very high level overview of the design and function of each account. The inherent barriers in place between AWS accounts (which makes them separate accounts, e.g. authorisation, limits) immediately removes a lot of risks, and I strongly encourage you to move away from multi-tenanted accounts and adopt this kind of pattern if you can.

Any questions or comments, let me know! @raidsulaiman