by Steve Zeller, VP of Product Marketing
From standardized testing in high schools, to multimillion dollar stock trades, to doctors treating life-threatening illnesses, Software-as-a-Service applications are the new norm in mission-critical business-to-business products. Logicworks architects, builds, and manages AWS infrastructure for dozens of SaaS apps that power today’s most important business functions.
Here’s a quick overview of how we enable innovative software companies through the use of AWS technologies, services, and partnerships.
AWS Landing Zone
If you are rolling out software in the context of a large organization – think insurance companies, hospitals, banks, large retail stores – governance is going to be a big challenge. You’ll have different groups of administrators from product development to customer support, billing, security, networking, and quality assurance, all accessing the same cloud environment. Prior to 2018, you had two choices: allow all of these stakeholders to access the same AWS account (opening up a security and governance nightmare), or manually create and manage a multitude of accounts (improving security but drastically increasing complexity).
In January of 2019, Logicworks became one of the first service providers to participate in the AWS Landing Zone beta program. AWS Landing Zone is the first automated approach to multi-account creation and management, introducing the concept of an “Account Vending Machine” that can automatically create new AWS accounts based on templates. By building AWS Landing Zones for our high-governance customers, we can solve both problems – providing a secure and clearly delineated environment with unique access for different types of admins, while using Infrastructure-as-Code to automate the account creation process and greatly increase efficiency.
AWS Landing Zone architecture baseline. Source: AWS
The capabilities of an environment running AWS Landing Zone eliminate a number of pain points. Exposure is limited – a breach in one area, whether from user error or a malicious act, is contained. Similarly the “blast radius” of an outage whether infrastructure- or application-related is contained to a smaller area. Multiple accounts are also useful for SaaS companies whose clients must meet different compliance requirements. Multiple accounts provide strong isolation for auditing data; if only a single account has compliant or sensitive data, you only have to audit that account. However if that application were intertwined with the rest of your environment, everything would be audited. This allows you to maintain different compliance standards for different layers of the infrastructure. With the Account Vending Machine concept, any child account added under the master has built-in guardrails via pre-defined rules and procedures.
AWS Service Catalog
In the competitive world of SaaS delivery, the time it takes to onboard a new client is critical. In some cases, this could be an individual signing up via a software portal. In other cases, like onboarding a group of hospitals, remote offices, or bank branches, it may be necessary to spin up new infrastructure, configure additional instances of proprietary software and databases, and configure custom networking and security. A SaaS provider’s ability to get a new customer up and running quickly can mean the difference between closing a deal or losing out to a competitor who can get the job done faster.
To give our customers an advantage when it comes to time-to-market, Logicworks often leverages AWS Service Catalog. We can pre-build a library of infrastructure templates using AWS CloudFormation. These templates are extremely comprehensive and can include infrastructure choices like server instances and storage, complex networking schema, and security configurations. A CTO can create permissions allowing different departments the right to spin-up specific infrastructure templates. This achieves rapid time-to-market without sacrificing the governance standards of the organization.
With AWS Service Catalog, complex builds for new customers are done quickly and accurately, hitting all the bars for security, compliance, and executive oversight.
Building a Multi-Regulatory Compliance Framework
Today’s SaaS providers often find themselves needed to satisfy the security and compliance requirements of many different types of customers. An identity management platform may have clients in banking, healthcare, and hospitality. Each of these customers will have different concerns around security, and may ask to audit the SaaS platform against different industry regulations. Measuring the same organization against PCI, HIPAA, HITRUST, GDPR, ISO, and SOC2 can be very challenging for a mid-sized software company.
Each regulation will have dozens if not hundreds of different control groups, and your information security team will need to translate your technology choices into different formats and cover all kinds of special requirements. The good news is that many of these compliance regulations share the same underlying technology benchmarks and measures.
By creating a Multi-Regulatory Framework, you can address all the underlying technical requirements, and enforce the right security and information logging systems across all of your workloads. Then fulfilling all the various audit requirements is just a task of reformatting the same data to fit each different audit.
Here’s what a Multi-Regulatory Framework for a SaaS platform looks like, covering 13 different regulatory standards:
Logicworks offers an automated Compliance Assessment product that will score any cloud-based infrastructure against all the major regulatory compliance standards and give you a head start preparing for your next audit.
While security is always a top priority during the initial build phase of a cloud project, over time security tends to slip. As systems evolve, stacks change, and engineers come and go, it’s very easy to end up with a mash-up of legacy and cloud security policies piled on top of custom code that only a few engineers know how to work with.
The security of your system should not depend on the manual labor — or the memory — of your engineers. They shouldn’t have to remember to close XYZ security loophole when deploying a new environment. They don’t have time to manually ensure that every historical vulnerability is patched on every system across multiple clouds.
Security automation is the only long-term solution.
Automation significantly improves an engineer’s ability to “guarantee” that security policies are not only instituted, but maintained throughout the lifecycle of the infrastructure. Automated security policies encourage the adoption of evolving standards. And as vulnerabilities are exposed, changes can be implemented across hundreds or even thousands of complex systems, often simultaneously.
Many of the architectural principles that allow you to scale easily are also security benefits; for example, if you build out every environment using a pre-approved AWS CloudFormation template, the chance of you building out an environment with misconfigured security settings is much, much lower. And separating out SDLC tiers into spoke accounts provides a separation of concerns and reduced blast radius.
To learn more about security automation, read our extensive documentation on the subject.
The Essentials: Billing and Maintenance
If you’re running multiple clients in a single account or organization, you’re going to want to determine what each client is billing on AWS. This can be more complicated than you might expect.
As you grow and add additional applications to AWS, it becomes increasingly important to tag every resource. Each team will want to report their cost, usage, and performance data, sometimes in different ways — and tagging is the key to effectively tracking this data over time. In the case of running multiple SaaS customers on AWS, your AWS resources should at minimum have the Customer name, product, and SDLC tier.
While the AWS Cost Explorer tool is excellent for getting a snapshot of cost data, you will definitely want to invest in a cost management tool. A tool can automatically strip out internal data and produce reports for your customers so that you can bill usage back to them.
If you’re offering your software as a managed service to customers, then you need to offer around-the-clock support for issues/outages. This means maintaining a 24×7 team, not just putting your engineers on pager duty.
Small to mid-sized software companies that are transitioning to SaaS often don’t have the resources to staff a 24×7 AWS team. They’d rather focus on software development, not on hiring (and retaining) AWS administrators. Hence why so many Saas companies seek out an AWS Managed Services Provider (MSP) like Logicworks.
Cloud MSPs go far above and beyond traditional MSPs in terms of built-in automation, reporting, and compliance support — they’re much more than just an IT support line. They can also help you achieve a particular compliance objective if you don’t have the in-house resources to complete an audit. You can either let the MSP work behind the scenes, or actually introduce your client directly to your MSP.
From multi-regulatory compliance to multi-account architectures, SaaS applications require a unique set of AWS architectural best practices. The most mature SaaS providers are able to go after new customers in any industry — no matter their compliance requirements — and get them onboarded quickly, knowing that each environment meets a baseline set of security requirements.
However, building a fully-automated AWS infrastructure is complex, and most SaaS companies want their team to focus on delivering better software — not configuring and maintaining infrastructure. That’s why companies turn to Logicworks. We have worked with hundreds of SaaS companies to build and manage their AWS environments. If you want to learn more about Logicworks, visit our website at www.logicworks.com or contact us to get a free quote.