Checkout the sources and perform these actions in aws-go-sdk-v2/lambda/lambdasummary/
Iteration through accounts and regions here with “Lambda.ListFunctions”.
You need a main account, in this example “11111111111” and some accounts to be listed the member accounts
CDK V2 infrastructure
This creates the Lambda Resource and the matching policy to assume the Role in multipple accounts
GO SDK V2 app
All links See also
In app
:
task build
This creates a “main.zip” in `app/dist".
Output:
task build
task: env GOOS=linux GOARCH=amd64 go build -tags cloud -ldflags="-s -w" -o ./dist/main main/main.go
task: chmod +x ./dist/main
task: cp result.html ./dist
task: cd ./dist && zip main.zip main result.html
updating: main (deflated 67%)
updating: result.html (deflated 54%)
Note that the target architecture is amd64.
In main account, create a Systems Manager Parameter named /showfunctions/accounts
with all member accounts, comma separated, to whitespaces.
This configures account for the lambda at runtime and for the CDK infrastructure creation.
In app
in main account:
cdk deploy
Where cdk is an alias to cdk='npx cdk@v2.0.0-rc.27'
or an globaly installed CDK2.
Configure main account in infra/policy/template.yaml
Replace in line 10 the account number with your main account number
AWS: 'arn:aws:iam::111111111111:role/showfunctionsrole'
Deploy stack in each member account with
task trust
If you forget to configure the main account, you get an error in the CloudFormation log:
Invalid principal in policy: "AWS":"arn:aws:iam::111111111111:role/showfunctionsrole" (Service: AmazonIdentityManagement;
Because this principal does not exist. You have to create the Lambda Resource and the Lambda role called showfunctionsrole in your main account *before this step 4, because AWS checks whether this is a valid and existing principle.
If you get this error message, configure the main account in the template file and delete the stack with:
aws cloudformation delete-stack --stack-name AuditListFunctions
Output without error:
task trust
task: aws cloudformation deploy --template-file policy/template.yaml --stack-name AuditListFunctions --capabilities CAPABILITY_NAMED_IAM
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - AuditListFunctions
task: npx cfn-tail --region eu-central-1 AuditListFunctions
...
...| 2021-11-14T13:17:45.777Z | AuditListFunctions | REVIEW_IN_PROGRES
...| 2021-11-14T13:17:51.090Z | AuditListFunctions | CREATE_IN_PROGRESS
...| 2021-11-14T13:18:12.344Z | AuditListFunctions | CREATE_COMPLETE
Now the Lambda Function is allowed to call the Lambda Service in the other accounts.
If everything is OK, you get an HTML table with the Lambda runtimes like:
<table style=\"background-color:#FFFFE0;\">\n
<tr style=\"background-color:#BDB76B;\">\n
<th>Account</th>\n <th>Region</th>\n <th>Runtimes</th>\n </tr>\n \n
<tr><td>222222222222</td>\n <td>eu-central-1</td>\n <td>\n \n </td>\n </tr>\n
<tr><td>333333333333</td>\n <td>eu-central-1</td>\n <td>\n \n <li><strong>go1.x</strong>: 3</li>\n
...
The CloudWatch log would be like:
START RequestId: 72bbe325-8f49-416c-8ceb-82cd4638d771 Version: $LATEST
time="2021-11-14T13:24:54Z" level=info msg="Account: 111111111111 Region: eu-central-1"
time="2021-11-14T13:24:54Z" level=info msg="Account: 111111111111 Region: eu-west-1"
time="2021-11-14T13:24:54Z" level=info msg="Account: 111111111111 Region: us-east-1"
time="2021-11-14T13:24:54Z" level=info msg="Account: 222222222222 Region: eu-central-1"
time="2021-11-14T13:24:54Z" level=info msg="Account: 222222222222 Region: eu-west-1"
time="2021-11-14T13:24:54Z" level=info msg="Account: 222222222222 Region: us-east-1"
...
END RequestId: 72bbe325-8f49-416c-8ceb-82cd4638d771
REPORT RequestId: 72bbe325-8f49-416c-8ceb-82cd4638d771 Duration: 609.23 ms Billed Duration: 610 ms Memory Size: 1024 MB Max Memory Used: 34 MB Init Duration: 184.62 ms
Depending on your accounts and configured regions. The duration, that means the time the lambda needs to run is always around 550-600 milliseconds.
This is the power of GO, that with the gouroutines the request to all regions and accounts is performed at once and the execution time will be almost the same altough you perform multiple calls.
Now if you click preview, you should see all your member accounts with the runtimes:
Now you may easily adapt this for other account and region wider data gathering through lambda. Because it’s all performed in parallel, the execution time will stay low.
See the full source on github.