authentik on AWS with the CloudFormation template: what it builds and when to use it
The official authentik CloudFormation template gives a team a starting AWS deployment of authentik without hand-building every component. It provisions the network, database, container services, load balancer, storage and logging in one stack, which fits a team that wants a managed AWS footprint and is comfortable running on ECS Fargate. Choose it over Docker Compose when a single host is too small or too exposed for your needs, and over Kubernetes when your organization does not already operate a cluster and does not want to take on one just for identity. The template creates Secrets Manager secrets, a VPC, a Multi-AZ RDS PostgreSQL instance, an ECS cluster with server and worker services on Fargate, an ALB using an ACM certificate, two EFS file systems and CloudWatch log groups.
Treat the stack as a starting point to be reviewed, not a finished production design. The template sets defaults for database instance class, PostgreSQL version, storage and task sizing, and those defaults are the first things to check against your own load, availability targets and data residency rules. Confirm the network layout (subnets, routing and which components are reachable from where), the ACM certificate and its region, how secrets are rotated, who can change the stack, and how backups and restores of the database and EFS data will be tested. Ask your AWS account team or DeployOpen for a written review of these items before you rely on the stack for users.
Your own team carries the ongoing work after the first stack is up: patching the authentik version, upgrading PostgreSQL, watching task health and logs, and scaling server and worker services as sign-in volume grows. Read the authentik AWS installation guide alongside the template parameters before you choose sizes, and plan the first upgrade in a separate stack so you can test it before it reaches users.
What the template creates and what each piece does
The CloudFormation template builds a complete authentik runtime in one stack: compute, database, load balancing, storage, secrets and logs. Each piece maps to a role in authentik's architecture, so the stack is easiest to review when you can trace every component back to what it does.
ECS cluster with server and worker services
The ECS cluster runs two Fargate services from the same authentik image. The server service runs the core application with an embedded outpost to handle sign-in, API and provider traffic. The worker service runs background tasks such as sending emails, applying blueprints and syncing. Check that the server and worker tasks each have the environment they need, because a worker that cannot reach the database fails quietly while sign-ins still appear to work.
ALB with an ACM certificate
The Application Load Balancer is the public entry point and terminates TLS using an ACM certificate. The certificate must be issued in the same region as the stack before you create it, so request it first and confirm its status. Confirm the hostname on the certificate matches the authentik domain your users and OIDC clients will use, since a mismatch breaks sign-in for every application at once.
Multi-AZ RDS PostgreSQL
RDS PostgreSQL stores all authentik configuration and data except uploaded files, so it is the record you must protect most. The template deploys it Multi-AZ, which gives you a standby in another Availability Zone for failover. Review the default instance class, PostgreSQL version and 10 GB storage against your user count and retention needs, and confirm backup retention and deletion protection settings before go-live.
Two EFS file systems
The two EFS file systems hold the files that are not in PostgreSQL, such as uploaded icons, backgrounds and similar media that the server and worker containers need to share. Because both services must read the same files, shared storage is what lets them run as multiple tasks. Confirm which mount path each service uses and plan backups for these file systems separately from the database.
Secrets Manager secrets
Secrets Manager holds sensitive values the services read at start, including the database credentials and authentik's secret key. Keeping them out of task definitions and CloudFormation parameter values limits exposure in the console and in stack history. Confirm who in your organization can read these secrets, and record the rotation approach, since changing the secret key without a plan can invalidate existing sessions and tokens.
CloudWatch log groups
CloudWatch log groups collect output from the server, worker and supporting components, so they are the first place to look during a sign-in failure or a failed task. Set retention periods that match your audit and incident response policy, because the default may not meet it. Confirm that authentik event and audit records are retained in a place your security team can search, not only in container stdout.
Template parameters to size and when each setting fits
This table covers the template parameters you decide before creating the stack, with the default each one starts from, what pushes it up or down, and what to confirm with your team. Use it as a checklist before you accept defaults. The defaults in the template are a starting point, not a sizing result, so confirm each row against your expected login volume, directory size and availability target.
| Parameter | Default and what it controls | What pushes it up or down | What to confirm |
|---|---|---|---|
| Database instance class | m5.large for the Multi-AZ RDS PostgreSQL instance, which holds all authentik configuration and data except uploaded files | Number of users and applications, login and token volume, LDAP or outpost traffic, and the connection count after the Redis removal in 2025.10 | Peak concurrent logins and expected growth, and whether the instance class needs a change before go-live |
| PostgreSQL version | PostgreSQL 17 by default in the template | Your org's supported major version policy and the authentik version you plan to run | Confirm the version your authentik release supports and the upgrade path for future PostgreSQL majors |
| Database storage | 10 GB allocated storage | Audit log and event retention, number of sessions and tokens, and growth of flows and providers | Retention needs for logs and events, and whether storage autoscaling or a larger starting size fits your plan |
| Server task count | Two server tasks on Fargate, each with 512 CPU units and 1024 MiB memory | Interactive login rate, number of OIDC and SAML clients, and forward auth traffic through the embedded outpost | Peak sign-ins per minute, response time targets, and whether two tasks across Availability Zones meet your availability goal |
| Worker task count | Two worker tasks for background jobs such as email, syncs and scheduled tasks | Directory sync size, number of sources, email volume and scheduled task load | Frequency and size of LDAP or Entra ID syncs, and how long sync jobs take to finish under load |
| Task CPU and memory | 512 CPU units and 1024 MiB per task, applied to both server and worker services | Observed CPU and memory use under test traffic, garbage pressure and the number of concurrent flows | Load test results on the chosen values, with memory headroom confirmed before production traffic |
| ACM certificate and region | Certificate must be issued in the stack's region before creation, and the ALB uses it for TLS | Region chosen for data residency, latency to users and the domain name used for the ALB | Certificate issued in the exact region, domain validation complete, and the public hostname matches the ALB configuration |
| EFS storage | Two EFS file systems for persistent files such as uploads and icons | Number of uploaded files, branding assets and CSV exports, and whether you run more than one server task | Whether EFS suits your data handling rules, and whether S3-compatible storage is needed instead |
How to deploy the template in order
This sequence takes you from account checks and certificate preparation to a running authentik server that you can sign in to, with logs and database backups confirmed. Each step ends with a check so you know it is safe to move on.
Confirm the account, region and naming
Your cloud engineer confirms the AWS account, the region the stack will run in, and the naming prefix for the stack and its resources. Check that the account has room for a new VPC, an ECS cluster, a Multi-AZ RDS instance, an Application Load Balancer and two EFS file systems, and that your IAM role can create them and read Secrets Manager. Write the region and stack name down, because the certificate in the next step must match that region. Done when you can run the stack creation in a sandbox account without permission errors in the dry review.
Request or import the ACM certificate
Your team requests or imports a certificate in AWS Certificate Manager for the hostname authentik will use, in the same region as the stack. The authentik AWS installation documentation requires the certificate to be issued before the stack is created, so a certificate in another region will not work. Confirm that the certificate status is Issued and that the domain name matches the DNS record you plan to point at the load balancer. Done when the certificate shows Issued in the stack's region and you have its ARN.
Review the template parameters
Your platform engineer opens the CloudFormation template from the authentik AWS installation documentation and reviews each parameter against your sizing plan. The template defaults include an m5.large database instance, PostgreSQL 17, 10 GB of database storage, and two server and two worker tasks at 512 CPU units and 1024 MiB each. Decide whether those values fit your expected user count, and confirm the certificate ARN and any CIDR ranges with your network team. Done when every parameter has a recorded value and an owner who agreed to it.
Create the stack and wait for resources
Your engineer creates the stack in the CloudFormation console or with the AWS CLI, using the reviewed parameters. Watch the events tab until the stack reaches a create complete status, and investigate any resource that fails before retrying, since partial resources can block a clean rerun. Confirm that the Secrets Manager secrets, the VPC, the RDS instance, the ECS cluster with server and worker services, the ALB and the two EFS file systems all appear in the stack resources list. Done when the stack status is create complete with no failed resources.
Check ALB health and HTTPS access
Your engineer points the DNS record for the authentik hostname at the load balancer and checks the target group in the EC2 console. The server targets should report healthy before any user traffic is sent. Then request the hostname over HTTPS from a machine outside the VPC and confirm that the certificate chain is valid and the authentik login page responds. Done when the target group shows healthy targets and the hostname loads over HTTPS with a certificate that matches the name you requested.
Retrieve bootstrap access and sign in
The administrator opens Secrets Manager in the stack's region, finds the bootstrap secret created by the template, and reads the initial credentials from it. Sign in to the authentik administration interface with those credentials, then change the password and store the new one in your approved password manager or secrets store. Confirm that you can open the admin interface and see the default flows and providers. Done when you have signed in as the administrator and the bootstrap password has been replaced or otherwise handled under your policy.
Verify CloudWatch logs
Your operations engineer opens CloudWatch Logs and finds the log groups the template created for the server and worker services. Sign in once more, then confirm that server and worker log streams show recent entries for the requests and background tasks you just ran. Set a retention period on each log group that matches your log policy, since the template does not decide that for you. Done when both services write log streams that you can search and the retention setting is recorded.
Confirm database backup settings
Your database administrator opens the RDS console and checks that the PostgreSQL instance is Multi-AZ, that automated backups are enabled, and that the retention window and backup window match your recovery objectives. Confirm the instance class and storage against the template values you recorded earlier, and note whether the storage can grow automatically. Ask the vendor or your own runbook for the restore test steps, then schedule a restore into a separate instance to prove the backup works. Done when the backup settings are written down and a test restore has been planned or completed.
Why the Fargate and EFS design changes what you operate
The template runs authentik server and worker tasks on ECS Fargate, and that choice changes routine maintenance. A Fargate task is not patched in place. When you change the image version, the task definition, or the environment, ECS starts new tasks and stops the old ones, so your change process should assume replacement, not repair. Keep configuration in the stack parameters or in Secrets Manager rather than inside a running container, because nothing you change by hand inside a task survives a replacement. The template also splits the application into a server service and a worker service. Background work such as email, blueprint application and scheduled tasks runs in the worker, so you can scale the two services separately. Confirm the task counts for each service in your own environment, and set alarms on both, because a healthy server does not prove that queued work is being processed.
Two EFS file systems stand in for the local /data volume that a Docker Compose or single-host install would use. They hold uploaded and generated files such as icons, backgrounds and exports, so treat them as stateful data with their own backup and retention plan, separate from the database. Plan for the file systems to be read and written by every server and worker task, which is one reason the template is not a pattern for a single container host. Check the current authentik AWS installation documentation for which paths each file system serves before you assume a restore covers them.
The database is where most of the operational weight sits. authentik's 2025.10 release removed Redis and moved caching, tasks, sessions and WebSocket functions into PostgreSQL. The RDS instance therefore carries configuration, sessions and background task state together, and its connection usage grows with the number of server and worker tasks you run. Before go-live, ask your team to size the database instance class, the connection limit and the task counts together, and to watch connection metrics in CloudWatch after any scaling change. The 2025.10 release notes warn of higher PostgreSQL connection counts after upgrading, so repeat that check at every version change. Your upgrade plan should cover the RDS instance, the task definitions and the EFS data as one unit.
Questions buyers ask before deploying authentik on AWS
What does an authentik deployment on AWS cost, and who pays for what?
The cost has three parts: AWS resources, setup labor and your own operating time. The CloudFormation template creates a VPC, a Multi-AZ RDS PostgreSQL instance, an ECS cluster running server and worker services on Fargate, an Application Load Balancer, two EFS file systems, Secrets Manager secrets and CloudWatch log groups. AWS bills you for these resources every month, and the bill rises with instance size, storage, task count and data transfer. Template defaults include an m5.large database instance, PostgreSQL 17, 10 GB of storage and two server and two worker tasks at 512 CPU units and 1024 MiB each. Confirm current rates with AWS or your AWS account team. DeployOpen's setup work is a one-time fixed-scope engagement, priced from a written scope that you review before work starts.
How long does an authentik on AWS deployment take?
Duration depends on the scope you agree in writing and on how quickly your side responds. The main drivers are certificate validation in ACM, DNS changes that point your hostname at the load balancer, a sizing review of the database and task counts, and the identity integrations you add afterward, such as LDAP sources or SAML applications. The ACM certificate must be issued in the stack's region before the stack is created, so request it early. Ask for a timeline in the quote that separates infrastructure setup, identity configuration and handover, and note which steps depend on your approvals.
Can our own team run this without outside help?
Yes, if you have engineers comfortable with AWS networking, IAM, ECS, RDS and certificate management. The template is the official starting point, and the authentik AWS installation documentation describes each resource it creates. The harder work is often ongoing: patching the authentik version, planning upgrades in sequence, tuning database and task sizing as users grow, and reviewing backups and log retention. Ask yourself whether an engineer can own these tasks every month, not only at launch. An outside partner can handle the initial build and hand over a runbook, or stay on a retainer for upgrades and testing.
What do we need to provide before the work starts?
Plan to provide four things. First, an AWS account and a role or access path with permission to create the resources in the template. Second, control of the DNS zone that will host the authentik hostname. Third, ownership of the domain and the decision on who holds the ACM certificate and its renewal. Fourth, identity decisions: which directories or upstream providers authentik will read from, which applications will sign in through it, and which administrators will hold the bootstrap access. Your security team should also confirm where logs and secrets may be stored and who receives alerts.
Does DeployOpen replace our AWS account team?
No. DeployOpen plans, implements, documents and supports the authentik deployment in your AWS environment, and it works within the scope you agree in writing. AWS account teams handle your commercial terms, service limits, support plan, pricing and any AWS-side programs. Ask your AWS account team to confirm current rates for the services in the template, your support tier and any reserved capacity options. Keep those conversations separate from the implementation scope so each decision has one owner.
Which parts of the template need sizing review before launch?
Review the database instance class, storage size, the number of server and worker tasks, and the CPU and memory per task. The defaults are a starting point, not a sizing decision. Your expected login volume, number of connected applications, background task load and the growth you plan for should drive the values. Also review whether you need the Multi-AZ database for your availability target. Because authentik keeps configuration, sessions and background tasks in PostgreSQL after the Redis removal in the 2025.10 release, database connection counts and capacity deserve particular attention.
Is the AWS template suitable for regulated workloads?
It can be a sound base, but suitability depends on your controls, not on the template alone. Confirm with your compliance advisors which encryption settings, logging, network boundaries, backup retention and access reviews your framework requires, then check the template against those requirements. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies perform those assessments.
Security and operational controls to set on day one
The CloudFormation template creates secrets, a database, a load balancer, file systems and logs in one stack, so each of those resources needs its own control. The cards below cover access, data protection, exposure, logging, release management and change control, in the order most teams should close them after the first deployment.
Restrict who reads the secrets
The template stores database credentials and authentik's secret key in AWS Secrets Manager, so anyone with secretsmanager:GetSecretValue on those secrets can read the values that unlock the database and sign sessions. Scope IAM policies to the specific secret ARNs, limit who can edit them, and confirm that the ECS task execution role is the only principal that reads them at runtime. Record who can change the secrets, because rotating them requires a planned restart of server and worker tasks.
Keep the database private and recoverable
The RDS PostgreSQL instance holds all authentik configuration and data except uploaded files, so it should not be reachable from outside the VPC. Confirm that the database sits in private subnets, that its security group allows traffic only from the ECS service security group, that storage encryption is enabled, and that automated backups and Multi-AZ failover are on. Test a restore into a separate instance before go-live, because a backup that has never been restored is not yet a recovery plan.
Limit ALB exposure and set TLS policy
The Application Load Balancer is the only public entry point, so restrict its security group to the ports and source ranges your users need, and decide whether the authentik admin interface should be reachable from the internet at all. Review the listener's TLS security policy so it rejects legacy protocol versions, and confirm the ACM certificate covers the exact hostname users type. Enable access logs on the load balancer if your security team needs request-level records.
Set CloudWatch log retention deliberately
The template creates CloudWatch log groups for the server and worker containers, and their retention defaults to never expiring unless you change it. Set a retention period that matches your internal log policy and any regulatory record-keeping rule you are bound by, then confirm the log groups were created with that setting. Decide where authentication events go for long-term analysis, since sign-in and failure records are often the first evidence an investigation needs.
Stay inside the supported release window
authentik's security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes, and the project announces security releases at least 24 hours in advance. Pin the image tag in the stack, subscribe to the releases feed, and plan a rolling update within that 24-hour window whenever a security release is announced. Keep the server and worker on the same version, since they share one database schema.
Route outpost and blueprint changes through review
Blueprint files, providers, outposts and application settings change who can sign in, so they should not be edited directly in the admin interface on production. Store blueprints in version control, require a review and a staging apply before production, and record who approved each change. Treat outpost configuration the same way, because a wrong provider or redirect URI can lock users out or expose an application to the wrong audience.
When the CloudFormation template is the wrong choice
The CloudFormation template is the right starting point only when AWS is where you want authentik to run and you accept its component layout. Docker Compose is the lighter option for test setups and small production use. The authentik Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM, and it avoids the cost of an AWS account structure, a Multi-AZ RDS instance, an ALB, two EFS file systems and Fargate tasks. The trade-off is that you own the host, its patching, its backups and its failover. If your identity service is small, single-region and your team can run one host with tested restores, Compose may fit. Confirm that your availability target can be met by one host before choosing it.
Kubernetes with Helm is the better fit when your platform team already operates clusters, wants authentik to follow the same deployment, scaling and upgrade practices as other services, or needs to manage an external PostgreSQL that is not owned by the stack. The authentik Kubernetes guide recommends a separately managed PostgreSQL for production, which is the same database pattern the CloudFormation template creates for you. The CloudFormation template is also the wrong choice when your team already runs EKS, because a second container platform adds operational work. The same applies when you need multi-region deployment, since the template builds one stack in one region, and when your organization requires infrastructure as code in Terraform or AWS CDK that your team owns. In those cases, ask whether the template's resources can be reproduced in your own tooling, and confirm the template's fit against your internal standards for networking, encryption, logging and change control before you commit.
How DeployOpen scopes and delivers an authentik AWS deployment
DeployOpen plans and implements self-hosted open-source platforms inside the client's own cloud accounts, so an authentik stack on AWS runs in your account under your controls. Engagements start with a written scope that fixes deliverables and timelines before any build work begins.
How we scope
- Confirm the AWS account, region and VPC layout the stack will join, along with the owners of each account and network boundary.
- Agree which template parameters are sized for your user count, login volume and availability target, and record the reasoning in writing.
- Define the identity sources, applications and protocols authentik will serve at launch, so the first deployment has a clear test list.
How we build
- Request and validate the ACM certificate in the stack's region, then confirm DNS records for the ALB before creating the stack.
- Deploy the CloudFormation stack, verify Multi-AZ RDS, ECS server and worker services, EFS mounts and CloudWatch log groups.
- Test sign-in, MFA, provider configuration and failover behavior against the agreed test list before any production users arrive.
How we hand over
- Deliver a written runbook covering stack parameters, Secrets Manager entries, network paths, backup settings and the upgrade sequence.
- Document every deviation from template defaults, with the reason and the change needed to reverse it safely.
- Walk your operations team through monitoring, log review and the steps for rotating secrets and scaling tasks.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
- Plan authentik version upgrades against the supported release lines in the security policy, with a staging run before production.
- Confirm with your team which security releases need same-week action, using the advance notice authentik publishes for them.
