slic-starter | A complete , serverless starter project | Serverless library

This section covers a full deployment using multiple accounts with domain names and HTTPS certificates. It takes quite a bit longer than your average sample app since there is DNS and certificate approval involved. If you want to try SLIC Starter out in a single account without domains, go to the QUICK_START.md]. To set up deployment to your own accounts, first run through these steps.
Fork the repository into your own account or organization on GitHub. If you don't use GitHub, you will have to tweak the source project in the CICD module (source-project.ts)
Enable CodeBuild to access your GitHub repo. The most reliable way to do this is to use a Personal Access Token with access to create webhooks on your repository. The guide from AWS on how to do this is here.
Decide when DNS name you will use for your application. If you need to register one, the best place to do this is probably in your production account using Amazon Route 53.
Edit app.yml. This is an important step, so ensure you change all values to suit your needs.
Update to point to your correct repository (Change owner and name under sourceRepo)
Edit domainConfig to point to your domain. Use a domain you own so you can update DNS entries to point to your deployed environment. When the deployment process runs, the domain owner will be sent an email to verify ownership before the deployment completes.
Disable SLIC Watch, unless you need alarms and dashboards out of the box. If you aren't sure what to do, or don't want to incur the cost of additional dashboards and alarms, disable it. If you want nice alarms and dashboards, set up an SNS Topic as your alarms destination. Ensure that this topic it is accessible from all accounts by updating the SNS Topic Access Policy.
Create SSM parameters in your CICD account, pointing to the accounts of your staging (stg) and production(prod).
/shared/accounts/stg: <staging account ID>
/shared/accounts/prod: <production account ID> For single account deployment the Account IDs of CICD, Production and Staging would all be the same.
(Optional). Set up GitHub authentication for your repo. Create a GitHub Personal Access Token and add it as an secret with the name GitHubPersonalAccessToken in Secrets Manager in the CICD account. See this post for more detail on this approach.
Create a Mailosaur account. This is required for integration and end-to-end tests to verify that the application is sending emails as expected. Take the Mailosaur server ID and API key and add them in your CICD account to the Parameter Store as SecretString values with the following names
/test/mailosaur/serverId
/test/mailosaur/apiKey These are picked up by the integration and end-to-end test CodeBuild projects.
Create a secret string in System Manager Parameter store for each target account (e.g, stg or prod) with a value used to sign and verify verification codes - the parameter name should be /STAGE/sharing-service/code-secret where STAGE is the stage you are deploying to (dev, stg or prod).
Give permissions for your CICD account to deploy to staging and production accounts.
Deploy the CI/CD pipeline to your CICD account.
Trigger your pipeline by commiting your changes to the repository
Monitor your deployment by viewing the orchestrator pipeline in the AWS Console CodePipeline page.
Wait for your deployment to fail! Wait, what? Yes, your first deployment will fail. This is expected and all part of the process. Read on to find out more!
For the email-service to send emails, you must choose a 'From:' address and set it in parameter store. The paramter name is /<STAGE>/email-service/from-address. <STAGE> should be replaced with stg or prod as appropriate. order for the email service to send requests to SES, either the email address or the domain needs to be verified. This is not automatically done as part of the SLIC Starter deployment. If you are using SLIC with a domain configuration, the verification process is quite straightforward because we use Route 53 for our DNS records. See here for documentation on how to achieve domain verification throught the AWS Management Console. By default, SES will require validation of each email address to which emails are being sent. To avoid this, you can request a sending limit increase, which will remove your account/region from the SES Sandbox.