Environments

Names and conventions are settled; the account mapping is not

This page is the authority for the environment names, the resource-naming convention and the tag set. It took them over from Confluence ALMA on 2026-09-03, and the Confluence page is the older copy. The hostname pattern is on Hostnames. Which AWS account each environment runs in is not recorded for most services, so this page cannot answer that in general. The MySQL clusters are the exception, and Connect to MySQL through Session Manager names their accounts per environment. The account list this page links to is real and current.

The four environments

Environment	Used for	Deployed from	Data
feature	Testing one branch before it merges. Each branch gets its own	That branch, automatically	Test or synthetic
test	Integration testing on the latest merged code, by the team and QA	The main development branch, automatically	Test or synthetic
staging	Final validation before a release, for QA and stakeholders	A stable snapshot of tested code	Obfuscated production data
production	Live	By hand, after staging validation	Real

Other, one-off environments exist for specific projects, so treat these four as the common case rather than a closed set.

Note that these are the infrastructure environment names. They do not always match a repository’s branch names — staging is the default branch of six repositories, which makes “staging” ambiguous unless you say whether you mean the branch or the environment. The repository map has the branch side.

Resource names tell you the environment

Every AWS resource in the split-account estate is named ajomark-<project>-<environment>-<resource>, so a resource name alone tells you which environment you are looking at and usually which repository owns it:

ajomark-rekkari-test-alb
ajomark-infra-production-opensearch
ajomark-sse-staging-main-server

• <project> is normally the repository the resource’s code lives in, or an umbrella name for a larger set of resources.
• <environment> is test, staging or production. Feature-branch deployments are the named exception: their resources may carry the branch name instead.
• <resource> is brief and descriptive — alb, main-server, mysql-db. Put the detail in tags, not the name.

Two exceptions are allowed. Where AWS caps the name at 32 characters, as it does for load-balancer target groups, abbreviate the resource part and keep the rest of the scheme. Where a technology dictates its own naming, as S3 buckets do, follow the technology.

infra-v2 documents a different scheme

infra-v2’s conventions page names resources almaajo-test-vpc and rekkari-test-service, without the ajomark- prefix, and lists a different set of tag keys. This page is the authority, and that page is the one out of date. Until it is fixed, read a resource named either way as the same environment.

Tags

Every Terraform root applies the default tags through default_tags on the AWS provider, and each resource adds its own Name and Description on top. The per-resource Description overrides the default one, so a resource can say what it is while the default says what the whole state is for.

Tag	Value
Description	What the resources in this Terraform state are for
Author	Who created them — a company or a person
Contact	The author’s email address
Environment	test, staging or production. What a feature-branch deployment carries is not written down
Organization	Alma Mobility (Alma Liikkuminen)
Project	Usually Almaajo
ProjectAndEnvironment	The two joined, such as Almaajo-test
Terraform	True
Repository	The repository holding the Terraform, such as alma-mobility-marketplaces/infra

The accounts

Twelve accounts, seven non-prod and five prod, listed in tools/aws-sso/accounts.json. That file is the source of truth and carries each account’s own environment flag (nonprod or prod). Use Configure AWS SSO for the CLI to get at them.

Reaching an environment’s database

Database access to a live environment from a local machine goes through AWS Session Manager and a jumphost, per Connect to MySQL through Session Manager.