RONIN and the AWS Secure Research Environment: Better Together
The AWS Secure Research Environment provides the governed cloud foundation; RONIN adds researcher self-service on top. Learn how they complement each other, support tiered compliance and give researchers access to compute, storage, apps and cost controls.
If your institution is weighing up the AWS Secure Research Environment (SRE), there's a question that tends to pop up in the second or third meeting: "If we build the SRE, do we still need something like RONIN?" Or the reverse: "If we buy RONIN, does that make the SRE unnecessary?"
Short answer: they do different jobs, and they work best together. In this post we'll explain where each one sits, what each one is good at, and how to sequence them so you don't close any doors you'll want open later.
This post is written for central research IT teams and the people who sign off on their plans.
What the SRE actually is
AWS describes the Secure Research Environment as a preconfigured, compliance-aligned foundation built on the Landing Zone Accelerator on AWS (LZA). It can be deployed in commercial AWS Regions, AWS GovCloud (US), or both, and can be extended with a Trusted Research Environment for tighter control of data coming in and out.
The LZA itself is an open-source solution that deploys and governs a multi-account environment across 35+ AWS services, and AWS recommends pairing it with AWS Control Tower. In practice that means:
- Accounts and organisational units (OUs) set up through AWS Organizations
- Guardrails such as service control policies (SCPs), which limit what any account in an OU is allowed to do
- Networking patterns, including shared and inspected network paths
- Logging and monitoring with services like CloudTrail, CloudWatch and AWS Config
- Central encryption with AWS KMS
That's a strong foundation. It's also, by design, a foundation. AWS's own LZA page puts it plainly: "This solution will not, by itself, make you compliant. It provides the foundational infrastructure from which additional complementary solutions can be integrated."
What RONIN is
RONIN is the researcher self-service layer. It runs in your AWS accounts and gives researchers governed access (that isn't a terrible experience) to:
- Compute: machines, AI machines with GPUs, and autoscaling HPC clusters, chosen from options your admins approve
- Storage: object storage and drives, attached to projects
- Apps: RStudio, Jupyter, remote desktops and packaged software
- Cost controls: project budgets, forecasts and automatic notifications
- Projects: separation between research groups, with their own users, budgets and resources
- Isolate: a locked-down, non-internet-connected environment for sensitive data
Researchers click a few buttons and get to work. IT keeps the guardrails. Nobody has to file a ticket to get a machine.
So which layer does what?
RONIN and AWS managed services sit side by side on top of the SRE foundation.
| Question | SRE / LZA | RONIN |
|---|---|---|
| Who is it for? | Cloud and security engineers | Researchers, with research IT as admins |
| What does it create? | Accounts, OUs, SCPs, networks, logging | Projects, machines, clusters, storage, apps |
| How do users interact with it? | Infrastructure as code and the AWS console | A web interface built for researchers |
| Cost visibility | AWS Budgets and billing at account level | Budgets and forecasts per project, visible to researchers |
| Compliance role | Technical foundation and preventive controls | Governed, consistent environments inside those controls |
| Day-one value for a researcher | Not much on its own | A running machine or desktop |
"Does RONIN make the SRE unnecessary?"
Probably not, and we wouldn't pitch it that way. If your leadership wants an AWS-standard landing zone for all cloud research, the SRE is a sensible way to get one, and RONIN is happy to live inside it.
What's worth knowing is that RONIN doesn't require the SRE to be in place first. We can get you to a compliant production environment either way, and we can deploy before or after the SRE work, depending on how you want to sequence things.
That gives you two practical paths:
- SRE first, RONIN on top. Build the landing zone, then deploy RONIN into the accounts it creates. RONIN inherits the SCPs, logging and networking, and researchers get a friendly front end from day one of the SRE going live.
- RONIN first, SRE later. Get researchers working now in purpose-built accounts, then bring those accounts under the SRE as it matures. Useful when there's a grant deadline that won't wait for a landing zone project.
Compliance tiers without the squeeze
Central research IT in health sciences rarely gets one type of workload. You'll have HIPAA data, NIH-funded work that needs NIST 800-171, possibly CMMC, and plenty of research that needs none of the above.
RONIN can deploy into separate AWS accounts configured for the appropriate compliance level, so not every workload is forced into the most restrictive environment. That lines up neatly with how the SRE organises accounts into OUs with their own guardrails.
This matters for adoption more than people expect. If everyone has to go through the strictest path, some researchers will quietly split off and use personal Dropbox, which is the exact opposite of what the compliance program was for.
Where Databricks and other managed services fit
You'll almost certainly need AWS managed services and AWS Marketplace products alongside any researcher platform. Databricks is a common one, especially when it's tied to another institutional initiative.
That's fine. RONIN doesn't try to replace those services. They sit alongside RONIN in the same accounts or neighbouring ones, under the same SRE guardrails. Some offerings are a better fit as a managed service, some as a RONIN machine or cluster, and the sensible plan is to let each type of offering use whichever suits it.
What about the "application portal"?
AWS may show you the AWS access portal in IAM Identity Center, which gives users single sign-on to their assigned AWS accounts and applications. It's a nice front door. It isn't the house behind it: project separation, storage, compute options, logging and cost controls still need to be designed and built. It can complement RONIN, for example by giving access to internal web apps from inside an Isolate desktop.
You may also have seen Research and Engineering Studio (RES) in earlier SRE presentations. AWS has ended development of RES: 2026.09 is the final release, it's no longer available for new adoption as of 29 September 2026, and support for that release ends on 30 September 2027. Worth factoring in before building a plan around it.
What this really means
- The SRE gives you an auditable, AWS-standard foundation. Keep it.
- RONIN gives researchers something they'll actually use on top of it.
- You can deploy them in either order.
- Splitting accounts by compliance tier protects both the audit and adoption.
Next steps
If you're starting your SRE journey and want to see how RONIN slots in, get in touch with us. We're always happy to share what we've seen work, with or without RONIN.
