As a SaaS CTO, you’re regularly faced with critical decisions that can shape the future of your product and company. One such decision that may come up is whether to deploy your software components into your customers’ AWS accounts or keep them within your own infrastructure. This choice can have far-reaching implications for your business model, operations, and customer relationships. Let’s look at the pros and cons of each approach to help you make an informed decision.

The Case for Customer AWS Accounts

At first glance, deploying your SaaS components into your customers’ AWS accounts might seem appealing, especially in high-compliance environments where you’d prefer not to be on the hook for your customers’ security posture. Some customers, particularly those in regulated industries, may even insist on this approach to maintain stricter control over their own infosec outcomes: this can provide them with a sense of ownership and transparency that they might not get otherwise.

However, this approach comes with significant drawbacks. By deploying into customer accounts, you’re essentially relinquishing control over your platform infrastructure. You’ll likely be required to adhere to each customer’s unique standards and practices, which can quickly become a logistical nightmare as your client base grows. This can lead to a scenario where you’re managing multiple unique deployments, dramatically increasing the complexity and cost of your operations.

Moreover, deploying in customer accounts may be a risk to your intellectual property. Customers with access to the platforms your software runs in will have access to artefacts which form the core of your product, potentially compromising your competitive advantage.

The SaaS Purist Approach

Strictly speaking, the essence of a SaaS product is to provide your software as a service - it’s right there in the name! Unless you’re running the platform in your own accounts, it becomes challenging to truly call your offering a “service.”

The ideal SaaS model involves deploying your software components into accounts that you own and provision, either on a shared or a per-tenant basis. Your customers don’t have direct access to the underlying infrastructure. Instead, they interact with your product through defined APIs and web interfaces, or (less often) using a desktop client that you maintain and they install.

This approach offers several advantages:

Control and Flexibility: You maintain complete control over your environment, allowing you to make changes, updates, and improvements without navigating the complexities of customer infrastructure.

Economies of Scale: As your business grows, you can leverage your predictable cloud usage to negotiate private pricing agreements and enterprise discount programmes with AWS, potentially increasing your profit margins.

Simplified Support: Because you run the workload (using a managed cloud provider), they don’t have to. If there ever is a problem with the software and how it interacts with AWS, you need to contact AWS support just once, not once per customer.

Intellectual Property Protection: By keeping your infrastructure separate, you better protect your proprietary technology and processes.

Consistency: A standardised deployment model allows for more efficient operations, easier updates, and consistent performance across all customers.

Addressing Customer Concerns

While some customers may initially push for deployment in their own accounts, there are ways to address their concerns while maintaining control of your infrastructure:

Design Patterns: Using architecture patterns for tenancy separation, you can reassure customers that their data is held securely. If they’re already AWS customers, you can expose application interfaces to them over private network connections

Clear Communication: Educate your customers on the benefits of your deployment model, emphasising the improved service quality, faster updates, and potentially lower costs.

Compliance and Security: Define security policies that cover key stakeholder needs, and get certified to prove that you’re really doing it. This isn’t just about confidentiality and privacy; your customers also care about availability, data durability, and information integrity.

Service Level Agreements (SLAs): With full control over your side of the offering, you can define strong SLAs. The commitments you can make give customers confidence in the reliability and performance of your service.

The Multi-Cloud Conundrum

It’s worth noting here that if you bend to your customers’ will, and agree to deploy into their accounts, you may find yourself obligated to support multiple cloud providers. If a potential customer primarily uses a cloud vendor other than AWS, they may expect you to deploy your solution there as well. This can significantly complicate your operations and dilute your expertise.

If your customers prefer to use a cloud vendor other than AWS, you can still present an AWS-hosted solution to them over a secure network, by adopting the right design patterns.

In Conclusion

While there may be scenarios where deploying on customers’ own infrastructure seems necessary or advantageous, for most SaaS companies, maintaining control of your infrastructure by deploying in your own AWS accounts is the way you should go, so that you can truly offer your software as a service, and offer a more consistent and reliable service to your customers.

As a SaaS CTO, your goal should be to build a scalable, efficient, and profitable business. By carefully considering the implications of your deployment strategy and opting for a model that gives you maximum control and flexibility, you’ll be setting your company up for success.

We’ve been an AWS SaaS Services Competency Partner since 2020. If you’re building SaaS on AWS, why not book a free health check to find out what the SaaS SI Partner of the Year can do for you?

---

This blog is written exclusively by The Scale Factory team. We do not accept external contributions.