Who handles what? Self-Service, Managed Services, and AWS responsibilities

One of the biggest questions libraries ask early is: who is actually responsible for what?

This guide makes that clearer. It explains what AWS handles, what your library still owns, what self-service means in practice, and where Managed Services changes the picture.

The short version

AWS handles the underlying cloud services. AWS provides the infrastructure services your Koha environment uses, such as compute, storage, networking, and managed database services where applicable.

You own the AWS account, see the AWS billing directly, and stay in control of the environment.

Self-service means your library handles the launch and day-to-day decisions. Self-service does not mean “do everything manually,” but it does mean your library is responsible for the setup path unless you choose to add help.

Managed Services means we help with the work. Managed Services can add guidance and hands-on help for setup, migration, training, and rollout, and support after launch, while the environment still runs in your AWS account.

Responsibility overview

Area	Your library (self-service)	KohaSupport via Managed Services
Owns the AWS account	Yes	No — account remains yours
Pays for AWS infrastructure	Yes	No — AWS bills your library directly
Chooses the deployment path	Yes	Can advise
Chooses the AWS region	Yes	Can advise
Launches the stack	Yes	Can help or do with you
Retrieves initial credentials	Yes	Can guide
Completes post-installation setup	Yes	Can help
Plans migration from another ILS	Your library decides	Can help plan and implement
Staff training	Your library decides	Can provide
DNS changes and domain ownership	Yes	Can guide
SSL setup timing	Yes	Can guide or handle during managed work
Ongoing operational help	Your library handles unless help is added	Available if included

What AWS handles

AWS handles the underlying platform services.

That can include:

• the compute environment
• networking services
• storage services
• Systems Manager Parameter Store
• Secrets Manager
• managed database services such as Aurora, where used

AWS does not decide how your Koha environment is configured for library operations.

What your library owns

Your library owns:

• the AWS account
• the AWS bill
• the decision to use Free Tier, Standard Self-Service, Managed Services, or Enterprise
• the timing of launch and go-live
• internal policy decisions around access, operations, and change control

What self-service means in practice

In the self-service model, your library is responsible for:

• launching the CloudFormation template
• choosing the important settings
• retrieving credentials and completing setup
• deciding when to configure domain names and SSL
• reviewing backup expectations
• handling ongoing operational decisions unless help is added later

Self-service is a good fit when your team is comfortable following structured documentation and making a few AWS choices.

What Managed Services changes

Managed Services does not change ownership.

Your library still owns the AWS account and sees the infrastructure billing directly.

Managed Services changes the workload, because KohaSupport can help with:

• setup
• migration
• configuration
• training
• rollout planning
• support arrangements after launch

Domains, SSL, and access

Standard Self-Service

For Standard Self-Service, custom domains use A records pointing to the Elastic IP.

If SSL is needed, the safest pattern is to wait until DNS is working, then enable SSL on the instance using koha-setup-domains rather than forcing the change through a stack update.

Enterprise

For Enterprise, custom domains use CNAME records pointing to the Application Load Balancer DNS name.

If HTTPS is used, the expected certificate path is AWS Certificate Manager (ACM). Provide a pre-validated ACM certificate ARN at launch.

Credentials and secrets

Standard Self-Service

Standard stores the Koha administrator credentials in AWS Systems Manager Parameter Store. Retrieve them from the path shown in the stack outputs, or from the instance with sudo koha-passwd library.

Enterprise

Enterprise uses AWS-native secret handling for database credentials. The stack outputs include commands for retrieving the Koha application database password and the Aurora master password from AWS Secrets Manager. The Koha application DB username is koha_library.

Backups and recovery

Backups are part of the deployment design, but recovery expectations still need ownership.

Your library should be clear about:

• where backups are stored
• how often they run
• how long they are retained
• who verifies them
• who is responsible for restore testing

If that ownership is not clear internally, Managed Services is often worth adding.

Who should read this page

This page is especially useful for:

• library managers who want clarity on ownership
• librarians who want to understand what self-service really means
• IT staff reviewing the AWS/account model
• decision-makers comparing self-service against Managed Services

Related guides

• New to AWS? How Koha on AWS works for libraries
• Which Koha on AWS option is right for your library?
• Standard Self-Service Launch Checklist
• How to choose the right Koha on AWS setup
• Migrating to Koha from another library system

Need help clarifying responsibilities?

If your library wants a clearer launch plan before work begins, talk to KohaSupport.