Setting the file. One moment.
Subchapter 37.22
references/cloudwatch/appsignals-guides/eks-java.mdMarkdown5 KBView on GitHub
This guide shows how to modify existing CDK and Terraform infrastructure code to enable AWS Application Signals for Java applications running on Amazon EKS.
Do NOT:
cdk deploy, terraform apply, etc.)import * as eks from 'aws-cdk-lib/aws-eks';
import * as iam from 'aws-cdk-lib/aws-iam';
const cloudwatchRole = new iam.Role(this, 'CloudWatchAgentAddOnRole', {
assumedBy: new iam.OpenIdConnectPrincipal(cluster.openIdConnectProvider),
managedPolicies: [
iam.ManagedPolicy.fromAwsManagedPolicyName('CloudWatchAgentServerPolicy')
],
});
new eks.CfnAddon(this, 'CloudWatchAddon', {
addonName: 'amazon-cloudwatch-observability',
clusterName: cluster.clusterName,
serviceAccountRoleArn: cloudwatchRole.roleArn
});template: {
metadata: {
labels: { app: config.appName },
annotations: {
'instrumentation.opentelemetry.io/inject-java': 'true'
}
},
}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
}Add to node group’s depends_on:
resource "aws_eks_node_group" "app_nodes" {
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
]
}template {
metadata {
labels = {
app = var.app_name
}
annotations = {
"instrumentation.opentelemetry.io/inject-java" = "true"
}
}
}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 Java application. Here’s what I modified:
Files Changed:
your-node-roleNext Steps:
git diffVerification:
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!”