Project Goals#
This project aims to create a system to manage a number of small SaaS applications on AWS.
System Components#
Accounts and Planes#
- Control Pane Account
- Observability Account
- Workload Accounts
Here’s a quick overview of the components that do the “real work” on this system.
Application Management and Operations#
We will have a single Root of Truth (RofT) system to manage all the client applications, AWS infrastructure, observability, security monitoring, and billing. This system can be potently hosted in a single AWS account or spread across multiple accounts.
Workloads#
These will be the SaaS client applications that we want to manage. The application can be spread across a number of AWS accounts and regions. There are a number of tradeoffs that need to be considered when setting this part up. oCOnsiderations when deciding if client applications should be hosted in isolated accounts or if a number of applications can be hosted in the same AWS account.
Client application distribution
Here are some of the factors that need to be considered whether a client application should be hosted in a single AWS account or if a number of applications should be hosted in a single AWS account.
Large applications probably deserve their own account
- we don’t have to worry about a number of different clients competing for various resource limits on the account, although we do have to manage resource limits for the single client
- if the application has a usage base billing model as we can simply take the AWS account charges and pass these on to the end user.
Smaller applications can be hosted in the same account
- we do have to be aware of account resource limits, so our architecture needs to be able to manage applications in a number of accounts so that we can spread account loads out if necessary.
- we may need a way to move an application from one account to another.
Expected Number of Clients
- if the application is expected to have a large number of clients, we should probably aim for multiple clients per AWS account.
- On the other hand, managing a small number of large clients leans more towards separate accounts per client
Level of isolation required between client sites
- Individual accounts may be warranted if we have strict compliance rules (for example, healthcare data). In this case, we want to avoid the risk of data “leaking” between client accounts. We also need to be aware that if a client’s application has a security issue, like weak passwords, it could potentially put other client applications at risk that are running in the same AWS account.
Exit Strategy
- Finally, the client exit strategy should be considered. If we want to allow a client to quit our application but still have access to their data, we may want to consider allowing the to take over the ownership of the AWS account. Bringing back a point from earlier in this discussion, this problem can potentially be mitigated if our system can move client applications from one AWS account to another.
- Another potential exit strategy would be to move the client application data to a location of the client’s choosing (within reason). In this scenario, we would need to be able to connect or system with other storage systems. This simplest way to achieve this could be to just copy their data to another S3 bucket.
Observability#
The observability system will collect data from client applications, AWS services, and potentially even edge systems. Ideally, automated monitoring can be configured to monitor the health of the system.