Setting the file. One moment.
Subchapter 37.24
references/cloudwatch/appsignals-guides/eks-python.mdMarkdown7 KBView on GitHub
This guide shows how to modify existing CDK and Terraform infrastructure code to enable AWS Application Signals for Python applications running on Amazon EKS.
Error Handling:
Do NOT:
cdk deploy, terraform apply, etc.)Create an IAM role and install the CloudWatch Observability add-on:
import * as eks from 'aws-cdk-lib/aws-eks';
import * as iam from 'aws-cdk-lib/aws-iam';
// Create IAM role for CloudWatch agent
const cloudwatchRole = new iam.Role(this, 'CloudWatchAgentAddOnRole', {
assumedBy: new iam.OpenIdConnectPrincipal(cluster.openIdConnectProvider),
managedPolicies: [
iam.ManagedPolicy.fromAwsManagedPolicyName('CloudWatchAgentServerPolicy')
],
});
// Install the CloudWatch Observability add-on
new eks.CfnAddon(this, 'CloudWatchAddon', {
addonName: 'amazon-cloudwatch-observability',
clusterName: cluster.clusterName,
serviceAccountRoleArn: cloudwatchRole.roleArn
});Update your deployment template metadata to include the Python instrumentation annotation:
template: {
metadata: {
labels: { app: config.appName },
annotations: {
'instrumentation.opentelemetry.io/inject-python': 'true'
}
},
// ... rest of your template configuration
}Add the CloudWatch policy to the node role:
Neither path in this guide confines
CloudWatchAgentServerPolicyto the agent. Attaching tonode_rolegrants it to every pod scheduled on those nodes, since any pod can reach the node’s instance credentials unless IMDS access is blocked. The CDK path above uses an IRSA-style role instead of the node role, but as written its trust policy has no:subcondition —new iam.OpenIdConnectPrincipal(cluster.openIdConnectProvider)with noconditionslets any pod holding a projected service-account token callAssumeRoleWithWebIdentityon it. To actually scope it, add a:subcondition naming the addon’s service accounts (the addon installs two —cloudwatch-agentandcloudwatch-agent-cluster-scraper) plus:aud sts.amazonaws.com. Tell the customer which of the three states the change leaves them in.
resource "aws_iam_role_policy_attachment" "cloudwatch_agent_policy" {
policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
role = aws_iam_role.node_role.name
}Important: Add this policy attachment to your node group’s depends_on block:
resource "aws_eks_node_group" "app_nodes" {
# ... existing configuration ...
depends_on = [
aws_iam_role_policy_attachment.node_policy,
aws_iam_role_policy_attachment.cloudwatch_agent_policy
]
}resource "aws_eks_addon" "cloudwatch_observability" {
cluster_name = aws_eks_cluster.app_cluster.name
addon_name = "amazon-cloudwatch-observability"
depends_on = [
aws_eks_node_group.app_nodes
]
}Update your Kubernetes deployment template:
template {
metadata {
labels = {
app = var.app_name
}
annotations = {
"instrumentation.opentelemetry.io/inject-python" = "true"
}
}
# ... rest of your template configuration
}Before reciting the summary below (guidance for you, not for the user): say which role the policy actually landed on, because the two paths differ in blast radius. The CDK path puts it on an IRSA-style role; the Terraform path attaches it to the node role, which extends it to every pod scheduled on those nodes. Also state that the CDK role’s trust policy has no
:subcondition unless one was added, so as written neither path confines the policy to the agent. The summary bullet has ayour-node-roleslot — fill it in with the role this change actually used before reciting.
Tell the user:
“I’ve completed the Application Signals enablement for your Python application. Here’s what I modified:
Files Changed:
your-node-roleNext Steps:
git diffcdk deployterraform applyVerification:
Warning for Django: If your application is built with Django, you must follow additional steps to prevent startup failures (opens in a new tab).
Troubleshooting Refer to the CloudWatch APM troubleshooting guide (opens in a new tab).
Let me know if you’d like me to make any adjustments before you deploy!”