# AWS > Run the Atlantic Agentic Engine on AWS: the one-click stack, what it creates, the permissions it takes, regions, and deployment profiles. Draft: this page is being written, and what it says is not yet complete. The engine runs in an AWS account of yours, as Terraform your own GitLab pipeline applies. Models are called through Amazon Bedrock, in your account and region, by the gateway’s role alone. ## The one-click stack In LightHouse, **Setup and admin → Where agents run**, choose **AWS**, a region and a profile, then **Get my stack**. LightHouse gives you two files: 1. **`lighthouse-bootstrap.json`**, a CloudFormation template. **Open your AWS console** takes you to CloudFormation’s create page in your region; upload the template there. Its parameters are your GitLab project’s path, your GitLab address (`https://gitlab.com` by default) and the region. It creates the identity your pipeline deploys with, and outputs `DeploymentRoleArn`: set it as `AAL_DEPLOY_ROLE_ARN` in your pipeline. 2. **`main.tf`**, which calls Atlantic’s AWS module at a pinned version. Commit it to your repository; your pipeline plans and applies it from `main`, as a reviewed merge request. LightHouse never applies anything in your account. The template is downloaded, not hosted by Atlantic, so Atlantic cannot change what you applied. ### What to have ready - An AWS account for the deployment, and the Bedrock models you want enabled in your region. - A GitLab project whose CI runs with OIDC. - The gateway’s image (pinned by digest), your monthly budget and the addresses for budget alerts, and the gateway policy (which models, caps and pacing). - For a public load balancer: an ACM certificate. For the ephemeral profile: the gateway’s Lambda image. ## What it creates Every resource is named `aal-…` and tagged. | Area | Resources | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Keys | A KMS key and alias for the deployment’s data | | Network | A VPC (10.40.0.0/16 by default) with the default security group closed, two private and two public subnets in two availability zones, flow logs, a NAT gateway, and interface endpoints for Bedrock, ECR, CloudWatch Logs, Secrets Manager, KMS and EFS, plus an S3 gateway endpoint | | Logs and audit | CloudWatch log groups for the app, the gateway and flow logs (400 days by default); a multi-region CloudTrail with log file validation, into its own bucket | | Database | RDS PostgreSQL 17 (Multi-AZ, deletion protection, 14-day backups, a final snapshot); or Aurora Serverless v2, pausing after five idle minutes; or SQLite on EFS, ephemeral only | | Files | EFS, encrypted with the key, with access points | | Budget | An AWS Budget emailing at 80% forecast and 100% actual | | Secrets | The gateway’s token and the product’s secret key in Secrets Manager; the gateway policy in SSM, as a SecureString | | Compute | An ECS cluster on Fargate (ARM64): the gateway (two tasks, port 8090) and the product (one task, port 8081), with service discovery | | Edge | An Application Load Balancer (TLS 1.3 policy, deletion protection, optional OIDC sign-in), with a WAF on the public load balancer; or a Cloudflare Tunnel | | Guardrail | A Bedrock guardrail: prompt-attack filter on input; hate, insults, sexual content, violence and misconduct filtered; personal data anonymised (passwords and AWS keys always blocked); grounding and relevance checks | | Telemetry, reads, commands | The relay, the content reader and the command channel, each with its own role; the reader and the command channel run only if you turn them on | | Scheduled jobs | One EventBridge Scheduler schedule per job, each with its own task and role | ## Permissions ### The deployment role The bootstrap creates a GitLab OIDC provider and one role, `lighthouse-deploy-`, that only your GitLab project’s `main` branch can assume, for at most an hour. No long-lived key exists. It holds `PowerUserAccess`, narrowed: | Statement | Effect | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | One region only | Denies anything outside the chosen region, except global services (IAM, STS, CloudFront, Route 53, Organizations, Support) | | The roles the stack needs | Allows IAM role actions only on roles named for the stack | | Never itself | Denies any IAM action on its own role | | No users, no keys | Denies creating IAM users, access keys or console passwords, leaving the organisation, and stopping or deleting CloudTrail | The template grants Atlantic no access to your account. ### The workload’s roles | Role | Holds | | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Gateway (the only role that may call a model) | `bedrock:InvokeModel`, `InvokeModelWithResponseStream`, `Converse` and `ConverseStream` on the listed models only; `ApplyGuardrail`; decrypt only through Bedrock in your region | | Product | No Bedrock at all. The file system through its access points; on the ephemeral profile, invoke the gateway’s function only | | Task execution | Its own secrets and the policy parameter only | | Reader, command channel, jobs | Each its own role, with its own secret | Setting `models_enabled = false` attaches an explicit deny on `bedrock:*` to the gateway’s role: a second kill switch, below the gateway’s own. See [Suspension](/operations/suspension/). ## Regions LightHouse offers eu-west-1 (the default), eu-west-2, eu-central-1, us-east-1 and us-west-2. Pinned to the region you choose: every resource, the endpoints, the model ARNs and the key’s conditions. Global cross-region inference profiles are refused; any other inference region must be named. See [Regions](/data-sovereignty/regions/). ## Deployment profiles | | Always-on (`always_on`) | Ephemeral (`ephemeral`) | | --------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | Gateway | Two Fargate tasks, always warm | An AWS Lambda function (ARM64) behind a function URL with IAM authentication; the product reaches it through a local forwarder | | Product | One task | One task | | Database | RDS | Your choice; Aurora Serverless v2 pauses when idle | | Network | NAT gateway | Optionally a NAT instance (t4g.nano) | | Content reader, command channel | Services | A function every minute | | Estimated cost a month (eu-west-1, the lines that differ) | $329.87 | $15.09 | The estimated saving is $314.78 a month. The module defaults to `always_on`; LightHouse proposes `ephemeral`. To switch, set `deployment_profile` (and, for ephemeral, `gateway_lambda_image`), plan and apply: no data moves, and the key, database, file system and secrets are kept. See [Deployment profiles](/concepts/deployment-profiles/). ## Upgrading and removing the stack - **Upgrade**: move the module’s pinned tag (`?ref=vX.Y.Z`) in a reviewed merge request; never track `main`. Images are pinned by digest. See [Upgrades](/operations/upgrades/). - **Remove**: the database and the load balancer have deletion protection, and the database takes a final snapshot. A person turns protection off before `terraform destroy`. Removal is not automated \[Coming]. Source: https://docs.atlanticagenticlabs.com/clouds/aws/