Public Sector on AWS: What Nimbus Actually Requires
Project Nimbus is the Israeli government cloud framework. This post explains what it requires from suppliers and how to deploy a workload on it without rebuilding your system.
Project Nimbus is the framework that Israeli government organizations use to buy public cloud services from AWS and Google Cloud. If you want to sell a SaaS product or managed service to a Nimbus customer, you need to know what the framework requires. Many things people say about Nimbus are incorrect.
What Nimbus actually is
Nimbus is a procurement framework. It is not a separate cloud product. The infrastructure is standard AWS, in standard AWS regions, with data residency rules and extra contract terms added on top. Customers access it through approved partners - not directly from the AWS marketplace.
In practice: if you are an ISV and you want a Nimbus customer to use your product, you work with an approved partner. The partner handles the contracts, billing, and compliance paperwork.
What Nimbus demands of your workload
- Data residency. Customer data must stay in the Nimbus zones inside the region. You cannot replicate data to other AWS regions like us-east-1.
- Tenancy isolation. Multi-tenant SaaS is allowed. But you must show logical isolation for each customer. This means separate encryption keys, IAM boundaries, and network segmentation.
- Audit logging. You must enable CloudTrail and access logs. You must keep them stored and available to the customer when they ask.
- Approved encryption. KMS with customer-controlled keys is the minimum requirement. Some government bodies also require BYOK.
- Vendor support model. The customer needs a clear support path that does not depend on a US-only AWS support case.
What it does NOT demand
- You do not need a different SDK or different APIs.
- You do not need to rebuild your CI/CD pipeline.
- You do not need to hire a Hebrew-speaking SRE team (but it helps for customer-facing support).
How an ISV typically gets onboarded
- Work with an approved Nimbus partner for contracts and procurement.
- Map your workload to the residency requirements. Find everything that must stay in the region.
- Do a tenancy-isolation review based on the customer body's specific requirements.
- Set up the audit and logging tools that the customer needs to see.
- Have the partner write the SOW and submit it through the framework.
The typical timeline from "we want to sell to a Nimbus customer" to "first deployed workload" is 8-12 weeks if your system already runs on AWS. It takes much longer if you are starting from on-premises or another cloud.
Funding angle
AWS has a public-sector funding program that works with Nimbus projects. Credits and procurement support are available for partners who deliver Nimbus workloads. We usually apply for these at the same time as the technical setup. This means the customer's first 6-12 months of usage can be partly or fully covered by credits.
If you are an ISV or service provider trying to get onto Nimbus, we can handle the partner side of the project from start to finish. The hard part is the framework process. The technical work, if you already run on AWS, is usually small.