The Walled Garden

In a professional enterprise setting, you rarely build an AI application for just one person. You build it for different departments (HR, Sales, Engineering) or different external customers (SaaS multi-tenancy). The "Nightmare Scenario" is a user from the Sales department accidentally retrieving sensitive salary data from the HR Knowledge Base.

In this lesson, we will master Resource Isolation. We will learn how to build "Walled Gardens" where data and models are strictly partitioned.

---

1. Multi-tenancy at the Data Layer (S3)

Isolation begins where the data lives.

• Prefix-based Isolation: s3://my-ai-data/tenant-A/ and s3://my-ai-data/tenant-B/.
• Bucket-based Isolation: Each tenant gets their own physical bucket. This is the most secure because it allows for distinct KMS keys and bucket policies.

The Pro Path: If you are in a highly regulated industry (Finance/Health), use separate buckets. If you are building a generic internal tool, use prefixes with strict IAM policy conditions.

---

2. Multi-tenancy in Vector Databases

How do you separate data inside a Vector Store like Amazon OpenSearch Serverless?

Alternative A: Index-per-Tenant

• Pros: Absolute isolation. No chance of data leakage at the query level.
• Cons: High management overhead. OpenSearch has limits on the number of indices.

Alternative B: Metadata-Based Filtering (Shared Index)

• Pros: Scalable and cost-effective.
• Cons: Relies on the developer ensuring every query includes a FILTER tenant_id = 'XYZ'.

Exam recommendation: For maximal security, use Index-per-Tenant. For cost-efficiency at a massive scale, use Metadata filtering.

---

3. Isolating Model Endpoints

If you are using Amazon SageMaker, you can deploy distinct "Inference Endpoints" for different customers. This ensures that a traffic spike from Customer A doesn't slow down the experience for Customer B (Noise Neighbor problem).

For Amazon Bedrock, you can use multiple Provisioned Throughputs to allocate specific capacity to specific high-priority workloads.

---

4. Logical Isolation with IAM and Tags

We can enforce isolation using the ABAC patterns we learned in the previous lesson.

{
  "Effect": "Allow",
  "Action": "bedrock:InvokeModel",
  "Resource": "arn:aws:bedrock:*:*:provisioned-model/*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/TenantID": "${aws:PrincipalTag/TenantID}"
    }
  }
}

---

5. Network Isolation: The "Islands" Pattern

For ultra-secure workloads, you can place your AI logic in distinct VPCs.

• Sales VPC: Communicates with Bedrock via Endpoint A.
• HR VPC: Communicates with Bedrock via Endpoint B.
• Result: Even if the network of the Sales department is compromised, there is no physical network route to the HR AI endpoints.

graph TD
    subgraph HR_Network
    HRA[HR Agent] --> HRE[VPC Endpoint 1]
    end
    
    subgraph Sales_Network
    SA[Sales Agent] --> SE[VPC Endpoint 2]
    end
    
    HRE --> B[Amazon Bedrock]
    SE --> B
    
    style HR_Network fill:#e1f5fe,stroke:#01579b
    style Sales_Network fill:#fff9c4,stroke:#fbc02d

---

6. Monitoring and Billing Isolation

Isolation isn't just about security; it's about Visibility. Each tenant or department resource should be tagged with a CostCenter or TenantID.

• You can then use AWS Cost Categories to generate a separate invoice for each department's AI usage.

---

Knowledge Check: Test Your Isolation Strategy

---

Summary

Resource isolation is the "Walled Garden" strategy. By separating data, models, networks, and costs, you build a multi-tenant system that is as secure as it is scalable.

This concludes Module 9. In the next module, we move beyond infrastructure to the "Content" itself: Responsible AI and Guardrails.

---

Next Module: The Ethical Compass: Bias Mitigation Strategies