AWS installation

You can install authentik to run on AWS with a CloudFormation template.

Prerequisites

• An AWS account.
• An AWS Certificate Manager (ACM) certificate for the domain you will use for authentik. Take note of the ARN of the certificate. The certificate must:

  • Be in the same AWS region as the stack. ACM certificates are regional resources.

  • Have the status Issued before you create the stack. A certificate starts in Pending validation and only becomes Issued after ACM validates the domain (see CertificateDetail status). If the certificate isn't issued yet, creating the HTTPS listener fails with an error that ends with:

    must have a fully-qualified domain name, a supported signature, and a supported key size.

Certificate validation

If your domain has CAA DNS records, one of them must allow Amazon to issue certificates, for example 0 issue "amazon.com". Otherwise ACM can't issue the certificate and the request fails with the reason CAA_ERROR. For the full list of accepted values, see Configure a CAA record and CAA problems.

If your DNS is hosted on Cloudflare, set the DNS validation CNAME records that ACM gives you to DNS only. Cloudflare recommends not proxying records used for domain verification.

Installation

1. Log in to your AWS account and create a CloudFormation stack with our template.
2. Under the CertificateARN parameter, enter the previously created certificate ARN.
3. Review the other parameters and change them if needed.
4. Follow the prompts to create the stack.

Parameters

The template has the following parameters:

Parameter	Default	Description
CertificateARN	None, required	ARN of the ACM certificate used by the HTTPS listener of the load balancer.
DBInstanceType	m5.large	RDS PostgreSQL instance type, without the leading db..
DBVersion	17	RDS PostgreSQL engine version. It must be a version that RDS currently offers, see PostgreSQL version.
DBStorage	10	RDS PostgreSQL storage size in GB. The minimum is 10.
AuthentikImage	ghcr.io/goauthentik/server	authentik container image.
AuthentikVersion	The authentik version the template ships with	authentik container image tag.
AuthentikServerCPU	512	CPU units for each authentik server task (1024 = 1 vCPU).
AuthentikServerMemory	1024	Memory in MiB for each authentik server task.
AuthentikServerDesiredCount	2	Number of authentik server tasks. The minimum is 1.
AuthentikWorkerCPU	512	CPU units for each authentik worker task (1024 = 1 vCPU).
AuthentikWorkerMemory	1024	Memory in MiB for each authentik worker task.
AuthentikWorkerDesiredCount	2	Number of authentik worker tasks. The minimum is 1.

The server and worker tasks run on Fargate, so their CPU and memory values must be a valid Fargate combination. For the supported values, see Fargate task CPU and memory.

Resources

This stack will create the following resources:

• AWS Secrets Manager secrets for the PostgreSQL user and the authentik secret key
• A VPC for all other resources
• An RDS PostgreSQL Multi-AZ instance
• An ECS cluster with two services:
  • One for the authentik server
  • One for the authentik worker
• An ALB (Application Load Balancer) pointing to the authentik server ECS service with the configured certificate
• Two EFS file systems, for data and media, mounted on both ECS services
• A CloudWatch Logs log group for each of the server and worker containers

The authentik server and worker tasks connect to the RDS PostgreSQL database over TLS.

The stack will output the endpoint of the ALB to which you can point your DNS records.

PostgreSQL version

The default value 17 lets RDS choose the current 17.x minor version for your region. If you set a specific minor version, it must be one that RDS currently offers in your region, because RDS retires older minor versions over time. To list the versions you can use, run describe-db-engine-versions:

aws rds describe-db-engine-versions --engine postgres --region <region> --query "DBEngineVersions[].EngineVersion" --output text

Access authentik from AWS CloudFormation

To start the initial setup, navigate to http://<domain_you_configured>.

You are then prompted to set a password for the akadmin user (the default user).

Issues with initial setup

If you run into issues, refer to our troubleshooting docs.

Further customization

If you require further customization, we recommend you install authentik via Docker Compose or Kubernetes.

Troubleshooting

Logs

The authentik server and worker containers send their logs to CloudWatch Logs. Each container has its own log group, which you can find on the Resources tab of the stack in the CloudFormation console, with the type AWS::Logs::LogGroup. Log streams start with authentik-server or authentik-worker.

ECS service events

If ECS tasks keep stopping, never become healthy, or the service fails to deploy, check the service events. In the ECS console, choose Clusters, select the cluster created by the stack, select the service, and open the Events tab. You can also use the AWS CLI:

aws ecs describe-services --cluster <cluster_name> --services <service_name>

Database connection errors

The authentik server and worker containers connect to the database with AUTHENTIK_POSTGRESQL__SSLMODE set to require, so connections fail if the database doesn't accept TLS. If the logs show database connection errors, check that the RDS instance accepts TLS connections. For more information, see Using SSL with a PostgreSQL DB instance.

Stack stuck in progress

When creating or updating the stack, CloudFormation waits until each ECS service runs its desired number of tasks. If the tasks keep failing, for example because they can't connect to the database, the stack can stay in CREATE_IN_PROGRESS or UPDATE_IN_PROGRESS for several hours.

To let CloudFormation finish, set the desired count of the affected service to 0. This stops all of its tasks, so avoid doing this on a production deployment.

aws ecs update-service --cluster <cluster_name> --service <service_name> --desired-count 0

After you fix the cause, set the desired count back to its previous value. For more information, see the AWS Knowledge Center article on ECS services that fail to stabilize.

Delete the stack

When you delete the stack, CloudFormation keeps some resources so that your data isn't lost:

• The two EFS file systems are retained.
• The two CloudWatch Logs log groups are retained.
• The RDS database is deleted, but CloudFormation takes a final snapshot of it first.

Retained resources and snapshots continue to incur charges until you delete them. If you no longer need them, delete the file systems in the EFS console, the log groups in the CloudWatch console, and the snapshot under Snapshots in the RDS console.