> For the complete documentation index, see [llms.txt](https://docs.zerve.ai/zerve-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zerve.ai/zerve-docs/self-hosting/aws-access.md). # What Zerve can access in your AWS account Exactly what access Zerve has in your AWS account when you use bring your own cloud, for security reviews. When you set up the [AWS QuickStart](/zerve-docs/self-hosting/aws-quickstart.md), Zerve manages resources in your account through **a single IAM role**. This page explains what that role can and can't do, for your security and cloud teams. ## How Zerve gets access The stack creates an IAM role named `zerve`. Only Zerve's own AWS account can use it, and only with an **external ID that matches your Zerve organization's ID**. This is AWS's standard protection against the "confused deputy" problem, where one customer could trick a service into acting on another customer's account. Zerve doesn't use stored keys for your account, unless you turned on the QuickStart's **Enable user-based auth** option, which isn't recommended. ## What the role can do The role's permissions are **limited to resources whose names start with `zerve`** wherever AWS allows it. It can't read or change your other resources. | Area | What Zerve can do | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Storage** | Read and write the Zerve S3 bucket | | **Serverless compute** | Create and manage `zerve-*` Lambda functions | | **Container compute** | Run tasks and manage services and load balancers in `zerve-*` ECS clusters | | **GPU compute** | Run `zerve-*` SageMaker training jobs, and manage `zerve-*` models and endpoints | | **Environments** | Run the Zerve image build project, and manage `zerve*` container repositories | | **Deployments** | Manage `zerve-*` CloudFormation stacks and API gateways, and `*.zerve.cloud` certificates | | **DNS** | Manage records in the deployments' hosted zone, if you set a base domain | | **Logs** | Read `/zerve*` logs | | **AI models** | Call Amazon Bedrock models, so your organization can use [Bedrock](/zerve-docs/administration/bring-your-own-api-keys.md) as its model provider | If your organization requires one, the QuickStart can apply your own **permissions boundary** to every role it creates. ## Separate roles for your code Your code doesn't run with the `zerve` role. Each kind of compute has its own role, with only what it needs: * Separate roles for Lambda, Fargate and SageMaker runs * A separate role for building environments ### Each notebook can only see its own data When a block runs, it's given credentials tagged with its notebook's ID, and they only allow access to **that notebook's own folder** in the bucket. Code in one notebook can't read another notebook's results, even in the same organization. ## Network access | Traffic | How it works | | ------------------------------------- | ------------------------------------------------------------------------------------------------------ | | **Your code** | Runs in private subnets. Outbound traffic leaves through NAT gateways with fixed IP addresses. | | **Deployed apps** | Served over HTTPS only, through a load balancer that only accepts traffic from the IP ranges you allow | | **Deployed APIs and model endpoints** | Served through API gateways, with their own certificates | ## What Zerve sets up on its side When the stack is created, Zerve: 1. Gives your account access to Zerve's container images, so its runtime can run in your account 2. Validates your deployments' SSL certificate, by adding a DNS record in `zerve.cloud` 3. Delegates your subdomain, such as `acme.zerve.cloud`, to the hosted zone in your account ## Revoking access To remove Zerve's access, delete the CloudFormation stack, which deletes the `zerve` role. See [What's kept when you delete the stack](/zerve-docs/self-hosting/aws-cloudformation-reference.md#whats-kept-when-you-delete-the-stack). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.zerve.ai/zerve-docs/self-hosting/aws-access.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.