{"id":19014318,"url":"https://github.com/serverless-heaven/serverless-aws-alias","last_synced_at":"2025-05-08T23:48:41.636Z","repository":{"id":18145268,"uuid":"83552562","full_name":"serverless-heaven/serverless-aws-alias","owner":"serverless-heaven","description":"Alias support for Serverless 1.x","archived":false,"fork":false,"pushed_at":"2024-07-17T16:01:40.000Z","size":1309,"stargazers_count":190,"open_issues_count":87,"forks_count":69,"subscribers_count":12,"default_branch":"master","last_synced_at":"2025-05-08T23:48:35.070Z","etag":null,"topics":["alias-stacks","api-gateway","aws","aws-lambda","lambda-functions","serverless","serverless-framework","stage"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/serverless-heaven.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-03-01T12:33:53.000Z","updated_at":"2024-12-14T03:08:07.000Z","dependencies_parsed_at":"2023-02-18T02:46:03.234Z","dependency_job_id":"433c2ff2-9ca1-4484-96f6-d1180dbb419d","html_url":"https://github.com/serverless-heaven/serverless-aws-alias","commit_stats":{"total_commits":181,"total_committers":14,"mean_commits":"12.928571428571429","dds":"0.30939226519337015","last_synced_commit":"5690c82af9dfb43674a1bae31b452591d3560170"},"previous_names":["hyperbrain/serverless-aws-alias"],"tags_count":28,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-heaven%2Fserverless-aws-alias","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-heaven%2Fserverless-aws-alias/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-heaven%2Fserverless-aws-alias/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-heaven%2Fserverless-aws-alias/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/serverless-heaven","download_url":"https://codeload.github.com/serverless-heaven/serverless-aws-alias/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253166477,"owners_count":21864467,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["alias-stacks","api-gateway","aws","aws-lambda","lambda-functions","serverless","serverless-framework","stage"],"created_at":"2024-11-08T19:28:51.733Z","updated_at":"2025-05-08T23:48:41.611Z","avatar_url":"https://github.com/serverless-heaven.png","language":"JavaScript","readme":"[![Serverless][ico-serverless]][link-serverless]\n[![License][ico-license]][link-license]\n[![NPM][ico-npm]][link-npm]\n[![npm][ico-npm-downloads]][link-npm]\n[![Build Status][ico-build]][link-build]\n[![Coverage Status][ico-coverage]][link-coverage]\n[![Contributors][ico-contributors]][link-contributors]\n\n# Serverless AWS alias plugin\n\n**The plugin requires Serverless 1.12 or later!**\n\nThis plugin enables use of AWS aliases on Lambda functions. The term alias must not\nbe mistaken as the stage. Aliases can be deployed to stages, e.g. if you work on\ndifferent VCS branches in the same service, you can deploy your branch to a\nnew alias. The alias deployment can contain a different set of functions (newly\nadded ones or removed ones) and does not impact any other deployed alias.\nAliases also can be used to provide a 'real' version promotion.\n\nAs soon as the service is deployed with the plugin activated, it will create\na default alias that is named equally to the stage. This is the master alias\nfor the stage.\n\nEach alias creates a CloudFormation stack that is dependent on the stage stack.\nThis approach has multiple advantages including easy removal of any alias deployment,\nprotecting the aliased function versions, and many more.\n\n## Installation\n\nAdd the plugin to your package.json's devDependencies and to the plugins array\nin your `serverless.yml` file\n\nTerminal:\n```\nnpm install --save-dev serverless-aws-alias\n```\n\nserverless.yml:\n```\nplugins:\n  - serverless-aws-alias\n```\n\nAfter installation the plugin will automatically hook into the deployment process. Additionally the new `alias` command is added to Serverless which offers some functionality for aliases.\n\n## Deploy the default alias\n\nThe default alias (for the stage) is deployed just by doing a standard stage\ndeployment with `serverless deploy`. By default the alias is set to the stage\nname. Optionally you can set the name of the default (master) alias using the\noption `--masterAlias`, e.g., `serverless deploy --masterAlias`. (If you have\nalready created a serverless deployment without manually setting the default\nalias, this option should not be used.)\nFrom now on you can reference the aliased versions on Lambda invokes with the\nstage qualifier. The aliased version is read only in the AWS console, so it is\nguaranteed that the environment and function parameters (memory, etc.) cannot\nbe changed for a deployed version by accident, as it can be done with the\n`$LATEST` qualifier.This adds an additional level of stability to your deployment\nprocess.\n\n## Deploy a single function\n\nThe plugin supports `serverless deploy function` and moves the alias to the\nupdated function version. However you must specify the `--force` switch on the\ncommandline to enforce Serverless to deploy a new function ZIP regardless, if the\ncode has changed or not. This is necessary to prevent setting the alias to a\nversion of the function that has been deployed by another developer.\n\n## Deploy an alias\n\nTo deploy an alias to a stage, just add the `--alias` option to `serverless deploy`\nwith the alias name as option value.\n\nExample:\n`serverless deploy --alias myAlias`\n\n## Remove an alias\n\nSee the `alias remove` command below.\n\n## Maintain versions\n\nBy default, when you deploy, the version of the function gets assigned the retention policy of 'Delete'. This means any subsequent deploys will delete any version without an alias. This was done because each lambda version has its own stack. That stack can contain differences in not only the function code, but resources and events. When an alias is removed from a version and the version of the lambda is not deleted, it is no longer possible to tell which stack it came from and which resources/events it was meant to work with. Therefore versions without aliases will get deleted on subsequent deploys.\n\nThere are usecases where retaining versions is less risky and as such, you can opt into retaining these versions by deploying with the `--retain` flag.\n\n## Remove a service\n\nTo remove a complete service, all deployed user aliases have to be removed first,\nusing the `alias remove` command.\n\nTo finally remove the whole service (same outcome as `serverless remove`), you have\nto remove the master (stage) alias with `serverless alias remove --alias=MY_STAGE_NAME`.\n\nThis will trigger a removal of the master alias CF stack followed by a removal of\nthe service stack. After the stacks have been removed, there should be no remains\nof the service.\n\nThe plugin will print reasonable error messages if you miss something so that you're\nguided through the removal.\n\n## Aliases and API Gateway\n\nIn Serverless stages are, as above mentioned, parallel stacks with parallel resources.\nMapping the API Gateway resources to this semantics, each stage has its own API\ndeployment.\n\nAliases fit into this very well and exactly as with functions an alias is a kind\nof \"tag\" within the API deployment of one stage. Curiously AWS named this \"stage\"\nin API Gateway, so it is not to be confused with Serverless stages.\n\nThus an alias deployment will create an API Gateway stage with the alias name\nas name.\n\n### API Gateway stage and deployment\n\nThe created API Gateway stage has the stage variables SERVERLESS_STAGE and\nSERVERLESS_ALIAS set to the corresponding values.\n\nIf you want to test your APIG endpoints in the AWS ApiGateway console, you have\nto set the SERVERLESS_ALIAS stage variable to the alias that will be used for the\nLambda invocation. This will call the aliased function version.\n\nDeployed stages have the alias stage variable set fixed, so a deployed alias stage is\nhard-wired to the aliased Lambda versions.\n\n### Stage configuration (NEW)\n\nThe alias plugin supports configuring the deployed API Gateway stages, exactly as\nyou can do it within the AWS APIG console, e.g. you can configure logging (with\nor without data/request tracing), setup caching or throttling on your endpoints.\n\nThe configuration can be done on a service wide level, function level or method level\nby adding an `aliasStage` object either to `provider`, `any function` or a `http event`\nwithin a function in your _serverless.yml_. The configuration is applied hierarchically,\nwhere the inner configurations overwrite the outer ones.\n\n`HTTP Event -\u003e FUNCTION -\u003e SERVICE`\n\n#### API logs\n\nThe generated API logs (in case you enable logging with the `loggingLevel` property)\ncan be shown the same way as the function logs. The plugin adds the `serverless logs api`\ncommand which will show the logs for the service's API. To show logs for a specific\ndeployed alias you can combine it with the `--alias` option as usual.\n\n#### The aliasStage configuration object\n\nAll settings are optional, and if not specified will be set to the AWS stage defaults.\n\n```\naliasStage:\n  cacheDataEncrypted: (Boolean)\n  cacheTtlInSeconds: (Integer)\n  cachingEnabled: (Boolean)\n  dataTraceEnabled: (Boolean) - Log full request/response bodies\n  loggingLevel: (\"OFF\", \"INFO\" or \"ERROR\")\n  metricsEnabled: (Boolean) - Enable detailed CW metrics\n  throttlingBurstLimit: (Integer)\n  throttlingRateLimit: (Number)\n```\n\nThere are two further options that can only be specified on a service level and that\naffect the whole stage:\n\n```\naliasStage:\n  cacheClusterEnabled: (Boolean)\n  cacheClusterSize: (Integer)\n```\n\nFor more information see the [AWS::APIGateway::Stage](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-stage.html) or [MethodSettings](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apitgateway-stage-methodsetting.html) documentation\non the AWS website.\n\nSample serverless.yml (partial):\n\n```\nservice: sls-test-project\n\nprovider:\n  ...\n  # Enable detailed error logging on all endpoints\n  aliasStage:\n    loggingLevel: \"ERROR\"\n    dataTraceEnabled: true\n  ...\n\nfunctions:\n  myFunc1:\n    ...\n    # myFunc1 should generally not log anything\n    aliasStage:\n      loggingLevel: \"OFF\"\n      dataTraceEnabled: false\n    events:\n      - http:\n          method: GET\n          path: /func1\n      - http:\n          method: POST\n          path: /func1/create\n      - http:\n          method: PATCH\n          path: /func1/update\n          # The update endpoint needs special settings\n          aliasStage:\n            loggingLevel: \"INFO\"\n            dataTraceEnabled: true\n            throttlingBurstLimit: 200\n            throttlingRateLimit: 100\n\n  myFunc2:\n    ...\n    # Will inherit the global settings if nothing is set on function level\n```\n\n## Reference the current alias in your service\n\nYou can reference the currently deployed alias with `${self:provider.alias}` in\nyour service YAML file. It should only be used for information, but not to\nset any resource names. Making anything hard-wired to the alias name might\nmake the project unusable when deployed to different aliases because the resources\nare maintained in the master CF stack - the plugin takes care that resources\nare available.\n\nA valid use is to forward the alias name as environment variable to the lambdas\nand use it there for tagging of log messages. Then you see immediately which\naliased lambda is the origin.\n\nAny other use with the further exception of lambda event subscriptions (see below)\nis strongly discouraged.\n\n## Resources\n\nResources are deployed per alias. So you can create new resources without destroying\nthe main alias for the stage. If you remove an alias the referenced resources will\nbe removed too.\n\nHowever, logical resource ids are unique per stage. If you deploy a resource into\none alias, it cannot be deployed with the same logical resource id and a different\nconfiguration into a different alias. Nevertheless, you can have the same resource\ndefined within multiple aliases with the same configuration.\n\nThis behavior exactly resembles the workflow of multiple developers working on\ndifferent VCS branches.\n\nThe master alias for the stage has a slightly different behavior. If you deploy\nhere, you are allowed to change the configuration of the resource (e.g. the\ncapacities of a DynamoDB table). This deployment will reconfigure the resource\nand on the next alias deployment of other developers, they will get an error\nthat they have to update their configuration too - most likely, they updated it\nalready, because normally you rebase or merge your upstream and get the changes\nautomatically.\n\n## Event subscriptions\n\nEvent subscriptions that are defined for a lambda function will be deployed per\nalias, i.e. the event will trigger the correct deployed aliased function.\n\n### SNS\n\nSubscriptions to SNS topics can be implicitly defined by adding an `sns` event to\nany existing lambda function definition. Serverless will create the topic for you\nand add a subscription to the deployed function.\n\nWith the alias plugin the subscription will be per alias. Additionally the created\ntopic is renamed and the alias name is added (e.g. myTopic-myAlias). This is done\nbecause SNS topics are independent per stage. Imagine you want to introduce a new\ntopic or change the data/payload format of an existing one. Just attaching different\naliases to one central topic would eventually break the system, as functions from\ndifferent stages will receive the new data format. The topic-per-alias approach\neffectively solves the problem.\n\nIf you want to refer to the topic programmatically, you just can add `-${process.env.SERVERLESS_ALIAS}`\nto the base topic name.\n\n### Use with global resources\n\nEvent subscriptions can reference resources that are available throughout all\naliases if they reference the same resource id. That means that an event will\ntrigger all aliases that are deployed with the subscription defined.\n\nExample:\n\n```\nfunctions:\n  testfct1:\n    description: 'My test function'\n    handler: handlers/testfct1/handler.handle\n    events:\n      - stream:\n          type: kinesis\n          arn: \"arn:aws:kinesis:${self:provider.region}:XXXXXX:stream/my-kinesis\"\n      - http:\n          method: GET\n          path: /func1\nresources:\n  Resources:\n    myKinesis:\n      Type: AWS::Kinesis::Stream\n      Properties:\n        Name: my-kinesis\n        ShardCount: 1\n```\n\nWhen a function is deployed to an alias it will now also listen to the *my-kinesis*\nstream events. This is useful, if you want to test new implementations with an\nexisting resource.\n\n### Use with per alias resources\n\n**Currently this feature is not available. The Serverless framework does not\nsupport variable substitution in property names (see [#49][link-49]).\nAs soon as this has been implemented there, this note will be removed.**\n\nThere might be cases where you want to test with your private resources first,\nbefore you deploy changes to the master alias. Or you just want to create separate\nresources and event subscriptions per alias.\n\nThe solution here is to make the resource id dependent on the alias name, so that\nthe alias effectively owns the resource and the event subscription is bound to it.\n\nExample:\n\n```\nfunctions:\n  testfct1:\n    description: 'My test function'\n    handler: handlers/testfct1/handler.handle\n    events:\n      - stream:\n          type: kinesis\n          arn: \"arn:aws:kinesis:${self:provider.region}:XXXXXX:stream/my-kinesis-${self.provider.alias}\"\n      - http:\n          method: GET\n          path: /func1\nresources:\n  Resources:\n    myKinesis${self:provider.alias}:\n      Type: AWS::Kinesis::Stream\n      Properties:\n        Name: my-kinesis-${self.provider.alias}\n        ShardCount: 1\n```\n\n### Named streams\n\nThe examples above use named streams. I know that this is not perfect as changes\nthat require replacement are not possible. The reason for the named resources is,\nthat Serverless currently only supports event arns that are strings.\nThe change is already in the pipeline there. Afterwards you just can reference\nthe event arns with CF functions like \"Fn::GetAtt\" or \"Ref\". I will update\nthe examples as soon as it is fixed there and publicly available.\n\n## Serverless info integration\n\nThe plugin integrates with the Serverless info command. It will extend the information\nthat is printed with the list of deployed aliases.\n\nIn verbose mode (`serverless info -v`) it will additionally print the names\nof the lambda functions deployed to each stage with the version numbers the\nalias points to.\n\nGiven an alias with `--alias=XXXX` info will show information for the alias.\n\n## Serverless logs integration\n\nThe plugin integrates with the Serverless logs command (all standard options will\nwork). Additionally, given an alias with `--alias=XXXX`, logs will show the logs\nfor the selected alias. Without the alias option it will show the master alias\n(aka. stage alias).\n\nThe generated API logs (in case you enable logging with the stage `loggingLevel` property)\ncan be shown the same way as the function logs. The plugin adds the `serverless logs api`\ncommand which will show the logs for the service's API. To show logs for a specific\ndeployed alias you can combine it with the `--alias` option as usual.\n\n## The alias command\n\n## Subcommands\n### alias remove\n\nRemoves an alias and all its uniquely referenced functions and function versions.\nThe alias name has to be specified with the `--alias` option.\n\nFunctions and resources owned by removed aliases will be physically removed after\nthe alias stack has been removed.\n\n## Compatibility\n\nThe alias plugin is compatible with all standard Serverless commands and switches.\nFor example, you can use `--noDeploy` and the plugin will behave accordingly.\n\n## Interoperability\n\nCare has to be taken when using other plugins that modify the CF output too.\nI will add configuration instructions in this section for these plugin combinations.\n\n### [serverless-plugin-warmup](https://github.com/FidelLimited/serverless-plugin-warmup)\n\nThe warmup plugin will keep your Lambdas warm and reduce the cold start time\neffectively. When using the plugin, it must be listed **before** the alias plugin\nin the plugin list of _serverless.yml_. The warmup lambda created by the plugin\nwill be aliased too, so that the warmup plugin can be configured differently\nper deployed alias.\n\n## Test it\n\nIn case you wanna test how it behaves, I provided a predefined test service in\nthe `sample` folder, that creates two functions and a DynamoDB table.\nFeel free to check everything - and of course report bugs immediately ;-)\nas I could not test each and every combination of resources, functions, etc.\n\n## Use case examples\n\n### Multiple developers work on different branches\n\nA common use case is that multiple developers work on different branches on the same\nservice, e.g. they add new functions individually. Every developer can just\ndeploy his version of the service to different aliases and use them. Neither\nthe main (stage) alias is affected by them nor the other developers.\n\nIf work is ceased on a branch and it is deleted, the alias can just be removed\nand on the next deployment of any other alias, the obsoleted functions will\ndisappear automatically.\n\n### Sample project\n\nA preconfigured sample project can be found [here](https://github.com/HyperBrain/serverless-aws-alias-example).\nIt lets you start testing right away. See the project's README for instructions.\nThe sample project will evolve over time - when new features or changes are\nintegrated into the plugin.\n\n## Uninstall\n\nIf you are not happy with the plugin or just do not like me, you can easily get rid\nof the plugin without doing any harm to the deployed stuff. The plugin is\nnon-intrusive and does only add some output variables to the main stack:\n\n* Remove all alias stacks via the CloudFormation console or with 'alias remove'\n* Remove the plugin from your serverless.yml and your package.json\n* Deploy the service again (serverless deploy)\n\nYou're all set.\n\n## Advanced use cases\n\n### VPC settings\n\nAliases can have different VPC settings (serverless.yml:provider.vpc). So you\ncan use an alias deployment also for testing lambda functions within other\ninternal networks. This is possible because each deployed AWS lambda version\ncontains its entire configuration (VPC settings, environment, etc.)\n\n## For developers\n### Lifecycle events\n\n_currently the exposed hooks are not available after the change to the new SLS lifecycle model_\n\nThe plugin adds the following lifecycle events that can be hooked by other plugins:\n\n* alias:deploy:uploadArtifacts\n\n  Upload alias dependent CF definitions to S3.\n\n* alias:deploy:updateAliasStack\n\n  Update the alias CF stack.\n\n* alias:deploy:done\n\n  The Alias plugin is successfully finished. Hook this instead of 'after:deploy:deploy'\n  to make sure that your plugin gets triggered right after the alias plugin is done.\n\n* alias:remove:removeStack\n\n  The alias stack is removed from CF.\n\n### CF template information (not yet implemented)\n\nIf you hook after the alias:deploy:loadTemplates hook, you have access to the\ncurrently deployed CloudFormation templates which are stored within the global\nServerless object: _serverless.service.provider.deployedCloudFormationTemplate_\nand _serverless.service.provider.deployedAliasTemplates[]_.\n\n## Ideas\n\n* The master alias for a stage could be protected by a separate stack policy that\n  only allows admin users to deploy or change it. The stage stack does not have\n  to be protected individually because the stack cross references prohibit changes\n  naturally. It might be possible to introduce some kind of per alias policy.\n\n## Version history\n\n* 1.8.0\n  * Option to retain lambda function versions [#160][link-160]\n  * **Breaking** drop Node.js 6 support [#161][link-161]\n\n* 1.7.2\n  * Added support for Lambda custom roles [#87][link-87] [#88][link-88]\n  * Added support for dash in alias name when creating api gateway authorizers [#140][link-140]\n  * Configurable master alias [#127][link-127]\n  * Fix for \"functionnames\" where \"functionname\" A starts with function name B [#159][link-159]\n  * Dependencies updated\n\n* 1.7.1\n  * Restore compatibility with Serverless 1.27 [#120][link-120]\n\n* 1.7.0\n  * Support existing custom authorizers [#101][link-101]\n  * Support domain-manager plugin [#110][link-110]\n  * Support pseudo-parameter plugin [#112][link-112]\n  * Show logs from arbitrary versions [#62][link-62], [#89][link-89]\n\n* 1.6.1\n * Fixed custom authorizer references [#102][link-102]\n * Fixed broken DynamoDB stream deployments [#85][link-85]\n * Security: Updated moment\n\n* 1.6.0\n * Fixed issue with request authorizers [#96][link-96]\n * Support subscription to existing SNS topic [#94][link-94]\n\n* 1.5.1\n  * Support prewarmup with the warmup plugin [#72][link-72]\n  * Support `_ - +` in alias names [#68][link-68]\n  * Support ANY method type with stage configuration [#80][link-80]\n\n* 1.5.0\n  * Support `serverless deploy function` [#29][link-29]\n\n* 1.4.1\n  * Fixed crash when using logs --tail\n\n* 1.4.0\n  * Add support for S3 server side encryption [#63][link-63]\n  * Add `serverless logs api` command to watch API logs [#60][link-60]\n\n* 1.3.0\n  * Support full stage configuration at multiple levels [#57][link-57]\n  * Fix issue when trying to remove a stage completely [#56][link-56]\n\n* 1.2.1\n  * Fix issue when using a Cognito User Pools authorizer [#51][link-51]\n  * IAM roles of removed aliases are not deleted [#50][link-50]\n  * Added note to README to state that per-alias resources do not work until fixed/added in Serverless\n\n* 1.2.0\n  * Fix issue when stage is specified as Serverless variable [#45][link-45]\n  * Add support for SNS Lambda subscriptions [#43][link-43]\n  * Add support for custom authorizers [#22][link-22]\n\n* 1.1.0\n  * Use stage variable in APIG [#40][link-40]\n  * Fix tail logging [#42][link-42]\n\n* 1.0.0 Support \"serverless logs\" with aliases. First non-alpha!\n\n[ico-serverless]: http://public.serverless.com/badges/v3.svg\n[ico-license]: https://img.shields.io/github/license/serverless-heaven/serverless-webpack.svg\n[ico-npm]: https://img.shields.io/npm/v/serverless-aws-alias.svg\n[ico-build]: https://travis-ci.org/serverless-heaven/serverless-aws-alias.svg?branch=master\n[ico-coverage]: https://coveralls.io/repos/github/serverless-heaven/serverless-aws-alias/badge.svg?branch=master\n[ico-contributors]: https://img.shields.io/github/contributors/serverless-heaven/serverless-aws-alias.svg\n[ico-npm-downloads]: https://img.shields.io/npm/dt/serverless-aws-alias.svg\n\n[link-serverless]: http://www.serverless.com/\n[link-license]: ./blob/master/LICENSE\n[link-npm]: https://www.npmjs.com/package/serverless-aws-alias\n[link-build]: https://travis-ci.org/serverless-heaven/serverless-aws-alias\n[link-coverage]: https://coveralls.io/github/serverless-heaven/serverless-aws-alias?branch=master\n[link-contributors]: https://github.com/serverless-heaven/serverless-aws-alias/graphs/contributors\n\n[comment]: # (Referenced issues)\n\n[link-22]: https://github.com/serverless-heaven/serverless-aws-alias/issues/22\n[link-29]: https://github.com/serverless-heaven/serverless-aws-alias/issues/29\n[link-40]: https://github.com/serverless-heaven/serverless-aws-alias/issues/40\n[link-42]: https://github.com/serverless-heaven/serverless-aws-alias/issues/42\n[link-43]: https://github.com/serverless-heaven/serverless-aws-alias/issues/43\n[link-45]: https://github.com/serverless-heaven/serverless-aws-alias/issues/45\n[link-49]: https://github.com/serverless-heaven/serverless-aws-alias/issues/49\n[link-50]: https://github.com/serverless-heaven/serverless-aws-alias/issues/50\n[link-51]: https://github.com/serverless-heaven/serverless-aws-alias/issues/51\n[link-56]: https://github.com/serverless-heaven/serverless-aws-alias/issues/56\n[link-57]: https://github.com/serverless-heaven/serverless-aws-alias/issues/57\n[link-60]: https://github.com/serverless-heaven/serverless-aws-alias/issues/60\n[link-62]: https://github.com/serverless-heaven/serverless-aws-alias/issues/62\n[link-63]: https://github.com/serverless-heaven/serverless-aws-alias/issues/63\n[link-68]: https://github.com/serverless-heaven/serverless-aws-alias/issues/68\n[link-72]: https://github.com/serverless-heaven/serverless-aws-alias/issues/72\n[link-80]: https://github.com/serverless-heaven/serverless-aws-alias/issues/80\n[link-85]: https://github.com/serverless-heaven/serverless-aws-alias/issues/85\n[link-87]: https://github.com/serverless-heaven/serverless-aws-alias/issues/87\n[link-88]: https://github.com/serverless-heaven/serverless-aws-alias/issues/88\n[link-89]: https://github.com/serverless-heaven/serverless-aws-alias/issues/89\n[link-94]: https://github.com/serverless-heaven/serverless-aws-alias/issues/94\n[link-96]: https://github.com/serverless-heaven/serverless-aws-alias/issues/96\n[link-101]: https://github.com/serverless-heaven/serverless-aws-alias/issues/101\n[link-102]: https://github.com/serverless-heaven/serverless-aws-alias/issues/102\n[link-110]: https://github.com/serverless-heaven/serverless-aws-alias/issues/110\n[link-112]: https://github.com/serverless-heaven/serverless-aws-alias/issues/112\n[link-120]: https://github.com/serverless-heaven/serverless-aws-alias/issues/120\n[link-127]: https://github.com/serverless-heaven/serverless-aws-alias/issues/127\n[link-140]: https://github.com/serverless-heaven/serverless-aws-alias/issues/140\n[link-159]: https://github.com/serverless-heaven/serverless-aws-alias/issues/159\n[link-160]: https://github.com/serverless-heaven/serverless-aws-alias/issues/122\n[link-161]: https://github.com/serverless-heaven/serverless-aws-alias/pull/173\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fserverless-heaven%2Fserverless-aws-alias","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fserverless-heaven%2Fserverless-aws-alias","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fserverless-heaven%2Fserverless-aws-alias/lists"}