Silo model too expensive or configuration issue?

[hellraiserii]

First of all, congratulations on the initiative. We really like the general idea of building a saas enabler platform and the more we dive into documentation, twitch sessions and opened tickets, the better our general understanding about the solution gets.

That being said, have the impression that the silo model is punishing us too much per tenant. We currently have two SaaS Boost environments (dev and stg), with two tenants each of a simple wordpress server+efs+mysql micro db (for learning purposes).

Our experience so far seems to indicate that spinning up an ECS cluster and a VPC for each new tenant has a significant impact on our bill. Please note that these tenants are idling almost all the time. Shutting tenant loads down via scheduler did not help much because we are still being charged for the VPCs, Transit Gateways, and the ECS clusters.

For example, our forecasted november costs add up to $433 USD, being the following the most expensive items:

ECS

VPC

RDS

Our question is: Are we doing something wrong? Could anything be done by our side to lower base costs in order to make this more affordable without ditching the silo model altogether? (perhaps fiddling with could formation scripts to change the vpc-per-tenant model to subnets-per-tenant?)

Currently seems that Aws SaaS Boost could deliver for low-volume/expensive-subscription-cost SaaS pricing models, where the base cost of the silo model (around $100USD per tenant) would blend easily overall.

What are your thoughts about this?

[brtrvn]

Thanks for starting this discussion @hellraiserii. To fully understand the networking costs you will need to enable VPC Flow Logs and start capturing specifics about the traffic that is impacting your bill. See this article for some CloudWatch query examples.

We do know that when ECS launches a task it has to pull the container image from the ECR repository and the image layers themselves are stored in S3. Both ECR and S3 are communicated with through their public service endpoints (for example ecr.us-east-1.amazonaws.com). To make this connection requires the use of the Transit Gateway which links to one of the NAT Gateways in the SaaS Boost egress VPC. If you are deploying tasks frequently, and if those container images are large, I can see it impacting your networking costs. We have plans to implement VPC Endpoints for ECR to alleviate some of those costs.

The other thing to look at is whether your application is instantiating out-bound Internet calls. Do you know if your WordPress instances are calling out to some Internet address regularly? This would be your application making a request to the Internet not responding to a connection made by a customer.

[hellraiserii]

Hey @brtrvn, thank you for your thoughtful reply.
We have un-provisioned our environments to prevent incurring unnecessary expenses for holidays, but we will certainly follow your advice on enabling VPC Flow Logs in the next few days.
It's true we were not so careful about image sizes, which ranged from 100mb to 700mb, so you've probably hit the nail on the diagnosis 😄. I haven't found an existing feature-request for adding VPC Endpoints for ECR, count on upvote once there is one.
Can't confirm or deny WordPress calling back home (checking for updates perhaps?) but I will pay attention to that as well.

[rshettyami]

I have the same issues, the costs of keeping the infra running are too much especially when in a proof of concept stage. It would be nice to have a script to tear down the infr and re-provision later when needed. All I have currently running is the sample application, this is my 3rd my cost is $15, and 99% of the cost is EC and VPC. Your help in driving down the infra cost is appreciated.

Note: I have used the lambda function "sb-sandbox-ecs-shutdown-service" but no help

[brtrvn]

Using the optional shutdown/startup scripts will deprovision your SaaS application containers from the ECS cluster. If you use Fargate as the launch type for your services, then there will be no cost for ECS as long as it's shut down. If you use EC2 as the launch type, then shutting down the containers does not deprovision the cluster resources themselves. You will still incur the costs of the EC2 resources. You can modify the capacity provider to try and get it to scale your cluster to zero, but this will impact your startup time later.

If you want to completely remove the SaaS Boost environment, you will have to delete it using the installer program. This will of course delete all SaaS Boost configuration data and tenant data from your account which may not be what you want.

The overhead costs of a SaaS Boost environment with no provisioned tenants should be relatively small. There are some always on resources such as NAT Gateways, S3 buckets, DynamoDB tables, API Gateway, and others that make up the SaaS Boost control plane. Without those resources, you don't have a SaaS Boost installation.