Accounts Ids By Service

Resolve, at runtime, the mapping between a Janis service code and its AWS Account ID.

The mapping lives in a single SSM Parameter Store parameter named accountsIdsByService, shared across accounts via AWS RAM. This package encapsulates the discovery (RAM) + read (SSM) + in-memory cache logic so consumers such as @janiscommerce/lambda (runtime) and sls-helper-plugin-janis (deploy-time) can resolve account IDs through a single dependency.

Installation

npm install @janiscommerce/accounts-ids-by-service

API

AccountsIdsByService.getAccountId(serviceCode)

async. Returns the AWS Account ID (string) for the given Janis serviceCode.

• Throws an AccountsIdsByServiceError with code NO_SERVICE_ACCOUNT_ID when the service code is not present in the mapping.
• In a local/dev environment it resolves to undefined instead of throwing (see Usage).

'use strict';

const { AccountsIdsByService } = require('@janiscommerce/accounts-ids-by-service');

const accountId = await AccountsIdsByService.getAccountId('catalog');
// '012345678901'

AccountsIdsByService.getMapping()

async. Returns the full mapping object { [serviceCode]: awsAccountId }. Used, for example, by the deploy-time plugin to build cross-account ARNs.

'use strict';

const { AccountsIdsByService } = require('@janiscommerce/accounts-ids-by-service');

const mapping = await AccountsIdsByService.getMapping();
// { catalog: '012345678901', wms: '109876543210', ... }

The mapping is fetched once and cached in memory permanently for the lifetime of the Lambda container (no TTL). Both getAccountId() and getMapping() share the same cache.

AccountsIdsByServiceError

Error class thrown by this package. Exposes static get codes():

| Code | Value | Meaning | |---|---|---| | NO_SERVICE_ACCOUNT_ID | 1 | The requested service code is not present in the mapping | | INVALID_MAPPING | 2 | The parameter value could not be parsed as JSON |

'use strict';

const { AccountsIdsByService, AccountsIdsByServiceError } = require('@janiscommerce/accounts-ids-by-service');

try {
	await AccountsIdsByService.getAccountId('unknown-service');
} catch(error) {
	if(error.code === AccountsIdsByServiceError.codes.NO_SERVICE_ACCOUNT_ID)
		console.error('Service is not mapped to any AWS account');
}

accountsIdsPermissions

An array of sls-helper IAM statement hooks (['iamStatement', {...}]) granting the permissions this package needs at runtime: ram:ListResources and ssm:GetParameter. Spread it into your service serverless.js.

Usage

Grant the runtime permissions by spreading accountsIdsPermissions into your service hooks:

'use strict';

const { helper } = require('sls-helper');

const { accountsIdsPermissions } = require('@janiscommerce/accounts-ids-by-service');

module.exports = helper({
	hooks: [

		// ...other service hooks

		...accountsIdsPermissions
	]
});

Local behaviour

When running locally the package never reaches AWS. It is considered a local/dev environment when any of these holds:

• JANIS_ENV === 'local'
• JANIS_LOCAL === '1'
• NODE_ENV === 'dev'

In that case:

• getMapping() resolves to an empty object {}.
• getAccountId() resolves to undefined and does not throw NO_SERVICE_ACCOUNT_ID, mirroring the behaviour of @janiscommerce/lambda Invoker.getServiceAccountId().

Resolution algorithm

On the first resolution (cache miss, non-local):

1. RAM discovery — ram:ListResources with resourceOwner: 'OTHER-ACCOUNTS' and resourceType: 'ssm:Parameter', then find the resource whose ARN ends with :parameter/accountsIdsByService.
2. SSM read — if the shared ARN is found, ssm:GetParameter by that ARN and JSON.parse its value. This is the common case.
3. Fallback — if no share is found (i.e. the parameter lives in the same account, so it is not shared with itself), ssm:GetParameter by name (accountsIdsByService) in the local account.

The resolved mapping is cached in memory for the lifetime of the container.