Supplemental topics
Steps to enable cross-account data lake integration
If the solution was not deployed in the same account as the Amazon S3 bucket name, you must complete these additional steps to use the data lake. Complete these steps after onboarding a customer using the Tenant Provisioning Service microservice.
Important
You must repeat these steps for every applicable customer.
-
Navigate to the CloudFormation console
. -
Select the stack name of the target customer to open the Stack info window, and choose Outputs on the stack menu bar. Then, copy the value for the key:
CrossAccountDataLakeTemplateUrl
. -
Sign in to the Connected AWS Account ID in the Region that contains the target AMC instance S3 bucket, and navigate to the CloudFormation console.
-
Choose the Create stack dropdown, and select With new resources (standard).
-
Keep all default selections and paste the
CrossAccountDataLakeTemplateUrl
value copied from step 4 into the Amazon S3 URL field. -
Choose Next, enter a stack name, and choose Next again.
-
Review and choose Submit.
If your AMC Instance S3 bucket is KMS-encrypted you must grant permission using the following steps (otherwise you may stop here):
-
Navigate to the S3 console
and select your AMC Instance S3 bucket. -
Choose Properties on the bucket menu bar, and select Encryption Key ARN under the Default encryption section.
-
Select Edit next to Key policy, and add the following statement to the policy, replacing [replaceable]`<AWS_ACCOUNT_ID>` with the solution deployment account, then save the changes.
{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:root" }, "Action": "kms:Decrypt", "Resource": "*" }
Retrieving Client ID and Client Secret
-
Set up an Amazon Ads developer account and create a Login with Amazon (LwA) application.
-
Create a new security profile
or use an existing profile. -
From the security profile in use, select Show Client ID and Client Secret, or choose the settings icon and download.
See the Create a LwA application documentation
Managing Multiple Authenticated Credentials
If your API-backed resources span across multiple authenticated accounts, this solution provides the ability to manage your credentials from a single deployment. When adding your credentials through Secrets Manager, you can optionally add multiple pair of credentials by mapping each one to a unique AuthId value:
{ “my_auth_id_1” : { “client_id”: “”, “client_secret”: “”, “authorization_code”: “”, “refresh_token”: “”, “access_token”: “” }, “my_auth_id_2”: { “client_id”: “”, “client_secret”: “”, “authorization_code”: “”, “refresh_token”: “”, “access_token”: “” } }
You can now pass your AuthId in with your requests to ensure the right credentials are used. Refer to the microservice notebooks for examples of how to include this value.
Note
Secrets Manager is limited in the maximum size of a secret value. Refer to quotas to ensure you do not have more credentials than can fit in a single secret.
SageMaker notebook instance lifecycle configuration
This solution implements a lifecycle configuration for the SageMaker notebook instance, which automatically terminates an idle session after one hour to prevent unnecessary instance compute charges.
Steps to modify the auto-stop configuration:
-
Sign in to the Amazon SageMaker console
. -
In the left navigation pane, select Notebook instances and select the notebook instance created by this solution.
-
Choose Actions, then select Instance settings.
-
Under Instance settings, select Lifecycle configuration and edit the script of the existing configuration.
-
You can modify the value of the
--time
parameter in the command to set the desired idle time in seconds before auto-stop:(crontab -l 2>/dev/null; echo "*/5 * * * * $(which python) $PWD/autostop.py --time 3600 --ignore-connections >> /var/log/autostop.log 2>&1") | crontab -