Skip to content
EveryBill

Product — Silo

Isolation you can verify, not just take our word for.

Silo runs your deployment in its own AWS account — an isolation boundary that AWS itself enforces, not a schema or a namespace inside a shared system.

Starts at $2,500/mo

Silo is for firms whose compliance or IT reviewer needs to see the isolation boundary, not just be told it exists.

Silo runs the same EveryBill platform as Core, but your workloads, data, and encryption keys live in an AWS account created specifically for you. EveryBill owns the account and continues to operate it day to day, but the account itself — its VPCs, its IAM boundary, its resources — belongs to your deployment alone.

Account-level isolation is an AWS primitive, not an application convention. It cannot be bypassed by a bug in a shared data model or a misconfigured tenant filter, because there is no shared data model to misconfigure.

Four pillars

Silo is built around four commitments, each backed by a specific AWS control.

    1. Isolation you can verify

    Your deployment runs in a dedicated AWS account with account-level isolation. That boundary is enforced by AWS, and it is the same boundary AWS enforces between any two unrelated AWS customers — not a claim about application-layer tenant separation.

    2. Portability by default

    Because your workload already lives in its own account, moving to a fully customer-owned account (Sovereign) is a change of account ownership, not a re-platforming project.

    3. Auditability without waiting on us

    Your own team or your assessor can read the account’s CloudTrail, AWS Config, Security Hub, and GuardDuty findings directly. You do not have to file a request with EveryBill and wait for an export.

    4. A security baseline on day one

    Every Silo account is provisioned with the same baseline that protects EveryBill’s own production estate — described below — rather than a stripped-down version for smaller accounts.

What actually lands in your account

Concrete controls, not a checklist of intentions.

  • Organization CloudTrail, multi-region, KMS-encrypted, with log-file validation enabled.
  • AWS Config with 538 rules evaluated and included in an organization-wide aggregator.
  • Security Hub with the CIS AWS Foundations Benchmark v5.0, the AWS Foundational Security Best Practices standard, and PCI DSS v4.0.1 (139 controls monitored) enabled.
  • Amazon GuardDuty, Inspector2 (EC2, ECR, and Lambda scanning), and IAM Access Analyzer enabled on the account.
  • VPC Flow Logs active on production VPCs.
  • AWS WAF in front of public-facing distributions, and a service control policy locking the account tous-east-1.
  • Customer-managed KMS keys with per-domain separation, and TLS 1.2+ in transit (CloudFront minimum TLSv1.2_2021).
  • Application data in Aurora MySQL Serverless v2, Multi-AZ, encrypted at rest, with 30-day backup retention, deletion protection on, IAM authentication, and no public accessibility.
  • Hardware security key (YubiKey) enforcement on the administrative SSO access used to manage the account.

On Silo, EveryBill still holds the AWS account and the KMS keys — your team gets read access to the account’s audit trail and posture, not administrative control of the account itself. If you need to hold the account and the keys yourself, that is EveryBill Sovereign.

A risk-posture choice, not a regulatory mandate

Single-tenant deployment is something firms choose because their own risk tolerance, contracts, or internal policy call for it — it is not something any specific regulation requires. If your reviewer is asking for a dedicated account because a particular law or standard mandates one, get that requirement in writing and verify it directly with the standard rather than assuming it is true. Silo exists so you can make that call on your own terms and verify the result yourself, not because the law makes the decision for you.

Talk to sales about Silo

Walk through what lands in your account, what your assessor will be able to see, and how a Silo account maps onto your existing AWS review process.