Developing Applications On Managed Service For Apache Flink
AWSOfficialPublished by AWS
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides domain-specific knowledge for building, deploying, and maintaining Apache Flink applications on Amazon Managed Service for Apache Flink (MSF). It covers service-specific constraints, including the KPU resource model, configuration requirements, and operational lifecycle management. It emphasizes the use of service-level configurations over application-level settings for checkpoints and parallelism, and provides guidance on navigating the v1/v2 API identifier split for AWS CLI and SDK operations.
What it does
- Provides patterns for KPU-based resource configuration and scaling.
- Outlines service-specific constraints for checkpointing and parallelism.
- Details the lifecycle management for starting, stopping, and updating applications.
- Offers guidance on connector integration for Kinesis, Kafka, and Iceberg.
- Explains the v1/v2 identifier differences for IAM, CloudWatch, and SDK usage.
- Provides troubleshooting steps for application restart loops and state management.
When to use it
- When developing or migrating Apache Flink applications for Amazon Managed Service for Apache Flink.
- When configuring KPU resources or troubleshooting application scaling behavior.
- When setting up IAM roles, trust policies, or CloudWatch logging for MSF.
- When performing version upgrades or migrating from Flink 1.x to 2.x.
- When implementing connectors for Kinesis, Kafka, or Iceberg within an MSF environment.
Advantages
- Ensures adherence to MSF-specific service constraints and operational patterns.
- Prevents common configuration errors related to the v1/v2 API identifier split.
- Provides structured workflows for application lifecycle and deployment tasks.
- Offers clear guidance on avoiding anti-patterns in job graph design and resource management.
Usage examples
- “How do I correctly configure checkpoints for an application running on Managed Service for Apache Flink?”
- The agent will advise against hardcoding checkpoint configurations in the application code and instead direct the user to manage these settings via the MSF service-level configuration.
- “I am getting a ConcurrentModificationException when updating my Flink application. How do I fix this?”
- The agent will explain the need to fetch the current application version ID or use a conditional token before issuing an update command, providing the necessary CLI syntax.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/aws/developing-applications-on-managed-service-for-apache-flink/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip developing-applications-on-managed-service-for-apache-flink.zip -d .agents/skills
Documentation by AWS
Managed Service for Apache Flink
Overview
Domain expertise for Apache Flink applications on Amazon Managed Service for Apache Flink (MSF). Covers development, KPU resource management, connectors, state management, monitoring, IaC deployment, and version migration.
Execute commands using available tools from the AWS MCP server when connected — it provides sandboxed execution, audit logging, and observability. When the MCP server is not available, fall back to the AWS CLI or shell as needed.
General Guidance
Before starting, ensure you have a clear understanding of the user persona, use case, and requirements:
STOP: Determine the users background and use case before proceeding:
Are they new to Flink? New to Managed Service for Apache Flink?
Are they familiar with Java development?
Is the use case complex with lots of business logic? Or simple and declarative?
These will inform how to organize the project, and whether to use Flink Table API or DataStream API. In general, assume the DataStream API.
Example Workflow for New Applications
1. User asks to build a Flink application
2. Confirm user's goals and use case
3. READ [best-practices.md](references/best-practices.md)
4. READ [dependency-management.md](references/dependency-management.md)
5. READ relevant connector guides (e.g. [kinesis-connector-guide.md](references/kinesis-connector-guide.md))
6. Generate code following the loaded guidance
7. Validate against best practices
8. READ environment-setup.md via [environment-setup.md](references/environment-setup.md)
9. Compile and test locallyExample Workflow for General Questions
1. User asks about real time delivery of data to Iceberg
2. Confirm user's goals and use case
3. READ [best-practices.md](references/best-practices.md)
4. READ [iceberg-connector-guide.md](references/iceberg-connector-guide.md)
5. READ other reference files as needed
6. Answer question with loaded guidanceReference Files
You MUST use this skill and its reference files to answer any question on these topics.
Do NOT answer from training knowledge or by searching general AWS documentation when the question concerns Apache Flink, Managed Service for Apache Flink, KPU sizing, Flink monitoring, deployment, migration, real-time analytics, or Iceberg/LakeHouse streaming with Flink
You MUST load the relevant reference files below before taking other steps.
The reference files contain MSF-specific details (thresholds, statistics, namespaces, constraints) that differ from generic Flink guidance and are required for correct responses.
| Goal | Reference | When to Load |
|---|---|---|
| Best practices | best-practices.md | Always before writing code |
| Maven dependencies | dependency-management.md | New project or adding connectors |
| Local dev environment | environment-setup.md | Docker-based local development |
| MSF architecture | msf-overview.md | KPU model and service constraints |
| MSF constraints and patterns | msf-constraints-and-patterns.md | MSF vs self-managed Flink, service-level vs application-level configuration separation, MSF-specific resource/network/storage limits, common MSF patterns |
| Quotas, ENI planning, MSF vs EMR, source/sink choice | foundation-operations.md | Capacity planning, service selection, architecture design, CLI/IAM/CloudWatch identifier disambiguation |
| IAM execution role, trust policy, action prefix, service principal | foundation-operations.md | Writing IAM policies for MSF — covers the kinesisanalytics: (no v2) action prefix, kinesisanalytics.amazonaws.com (no v2) trust principal, and the v2/non-v2 disconnect that is the most common source of permission and AssumeRole failures |
| Flink 2.x migration | flink-2x-migration.md | Version upgrades, state compatibility |
| KPU sizing | resource-optimization.md | Right-sizing, performance diagnosis, scaling |
| Scaling decisions on running apps | scaling-decisions.md | In-flight scaling matrix, cost/memory impact of scale changes, autoscaling behavior, anti-patterns |
| Cost estimation | pricing-calculator.md | Budget planning, sizing-to-cost mapping, optimization levers |
| Application lifecycle ops | application-lifecycle.md | Start/stop, deploy code, rollback, snapshot lifecycle, runtime properties, delete |
| Restart loop diagnosis | first-fault-isolation.md | Crashing/restarting apps, finding original failure vs loop sustainers, Flink Dashboard live diagnosis |
| Checkpoint tuning | checkpoint-tuning.md | Checkpoint impact on KPU memory and CPU, frequency vs network bandwidth trade-offs, checkpoint duration exceeding interval, OOM/GC during checkpoints |
| Job graph design | job-graph-architecture.md | Performance issues, splitting jobs |
| Job graph anti-patterns | job-graph-anti-patterns.md | Data skew detection and mitigation, monolith job anti-pattern, high fan-out anti-pattern, removing multiple shuffles, when to split a large application |
| Monitoring and alarms | monitoring-and-metrics.md | CloudWatch dashboards, alarms, metrics |
| Logging | logging-configuration.md | Log4j2, CloudWatch Logs setup |
| Kinesis connectors | kinesis-connector-guide.md | Kinesis source and sink builders, polling configuration and throttling (READER_EMPTY_RECORDS_FETCH_INTERVAL, SHARD_GET_RECORDS_MAX, ReadProvisionedThroughputExceeded, LimitExceededException), legacy connector migration |
| Kinesis Enhanced Fan-Out (EFO) | kinesis-efo-guide.md | When to use EFO vs polling, EFO source configuration, consumer lifecycle (JOB_MANAGED vs SELF_MANAGED), parallelism vs shard count, IAM permissions, troubleshooting |
| Iceberg integration (write APIs, distribution modes, partitioning) | iceberg-connector-guide.md | Iceberg write APIs (append, upsert, dynamic), distribution modes (NONE/HASH/RANGE), CoW vs MoR, read patterns, partitioning, DDL. Does NOT contain catalog choice or maintenance approaches — for those, load iceberg-tuning-and-operations.md. |
| Iceberg tuning, operations, catalog choice, maintenance | iceberg-tuning-and-operations.md | Provides maintenance approaches for S3 Tables, Glue + Glue auto-compaction, and Glue + Flink embedded maintenance with JDBC lock for catalog-choice questions; small files problem and mitigations; Flink TableMaintenance API, post-commit maintenance, lock factories; IcebergSink monitoring, anti-patterns. |
| CDC connectors | cdc-connector-guide.md | MySQL, PostgreSQL, Oracle, SQL Server, MongoDB CDC |
| IaC and deployment | iac-and-deployment.md | CloudFormation, CDK, Terraform, two-phase deployment |
| Serialization | serialization-guide.md | POJO, Avro, Kryo guidance |
| State management | state-management.md | TTL, state types, migration safety |
Additional Resources
Files
- ATTRIBUTION.mdAdded by AutoGineer998 B
- LICENSELicence file added by AutoGineer9.9 KiB
- NOTICELicence file added by AutoGineer67 B
- SKILL.md8.8 KiB
- references/application-lifecycle.md20.7 KiB
- references/best-practices.md11.6 KiB
- references/cdc-connector-guide.md47.2 KiB
- references/checkpoint-tuning.md6.4 KiB
- references/dependency-management.md13.4 KiB
- references/environment-setup.md7.0 KiB
- references/first-fault-isolation.md14.4 KiB
- references/flink-2x-migration.md34.1 KiB
- references/foundation-operations.md12.1 KiB
- references/iac-and-deployment.md17.1 KiB
- references/iceberg-connector-guide.md17.1 KiB
- references/iceberg-tuning-and-operations.md31.1 KiB
- references/job-graph-anti-patterns.md11.8 KiB
- references/job-graph-architecture.md8.9 KiB
- references/kinesis-connector-guide.md9.3 KiB
- references/kinesis-efo-guide.md7.3 KiB
- references/logging-configuration.md9.9 KiB
- references/monitoring-and-metrics.md34.3 KiB
- references/msf-constraints-and-patterns.md8.8 KiB
- references/msf-overview.md6.3 KiB
- references/pricing-calculator.md6.2 KiB
- references/resource-optimization.md9.9 KiB
- references/scaling-decisions.md5.4 KiB
- references/serialization-guide.md9.2 KiB
- references/state-management.md4.5 KiB
references/iac-and-deployment.md
Infrastructure as Code and Deployment Guide
Overview
This guide covers IaC patterns and deployment automation for Amazon Managed Service for Apache Flink applications. Use it when generating CloudFormation, CDK, Terraform, or deployment scripts for MSF applications. The patterns here address common deployment ordering issues, IAM configuration, and resource dependencies that are specific to MSF.
CRITICAL: MSF Application JAR Dependency
The most common IaC failure for MSF is a deployment ordering problem: the MSF application resource requires the application JAR to exist in S3 at creation time.
When CloudFormation (or any IaC tool) creates a AWS::KinesisAnalyticsV2::Application resource with ApplicationConfiguration.ApplicationCodeConfiguration pointing to an S3 bucket and key, the MSF service validates that the JAR exists during resource creation. If the JAR is not yet uploaded, the stack fails with:
Resource handler returned message: "Please check the role provided or validity of S3 location
you provided. We are unable to get the specified fileKey: <key> in the specified bucket: <bucket>"Solution: Two-Phase Deployment
Always structure MSF deployments in two phases:
Phase 1 — Infrastructure: Deploy all supporting resources (S3 buckets, Kinesis streams, IAM roles, CloudWatch log groups, VPC resources). This phase does NOT include the MSF application itself.
JAR Upload: Build the application JAR and upload it to the S3 bucket created in Phase 1.
Phase 2 — Application: Deploy the MSF application resource, referencing the JAR that now exists in S3.
This applies to all IaC tools: CloudFormation, CDK, Terraform, SAM, etc.
CloudFormation: Two-Stack Pattern
Split the deployment into two CloudFormation stacks:
Stack 1 — Infrastructure (cfn-infra.yaml):
S3 bucket for JAR staging
S3 bucket for application output (if applicable)
Kinesis streams or Kafka/MSK resources
IAM execution role for the MSF application
CloudWatch log group and log stream
VPC, subnets, security groups (if VPC deployment)
Exports: bucket names, stream ARNs, role ARN, log group/stream ARNs
Stack 2 — Application (cfn-app.yaml):
AWS::KinesisAnalyticsV2::ApplicationresourceAWS::KinesisAnalyticsV2::ApplicationCloudWatchLoggingOption(if not inline)Imports: references from Stack 1 via
Fn::ImportValueor parameters
Deploy script ordering:
# 1. Deploy infrastructure
aws cloudformation deploy --template-file cfn-infra.yaml --stack-name my-app-infra ...
# 2. Build and upload JAR
mvn clean package -q
aws s3 cp target/my-app.jar s3://${JAR_BUCKET}/${JAR_KEY}
# 3. Deploy application (JAR now exists in S3)
aws cloudformation deploy --template-file cfn-app.yaml --stack-name my-app ...CDK: Deployment Ordering with Dependencies
In CDK, use separate stacks or ensure the JAR upload happens before the MSF application construct is created. CDK does not natively upload JARs during synthesis — you need a custom resource or a deploy script wrapper.
Option A — Two CDK stacks with a script wrapper:
// InfraStack: buckets, streams, IAM, logs
// AppStack: MSF application (depends on InfraStack)
// Deploy script uploads JAR between the two stack deploymentsOption B — CDK BucketDeployment construct:
import * as s3deploy from 'aws-cdk-lib/aws-s3-deployment';
// Upload JAR to S3 as part of the CDK deployment
const jarDeployment = new s3deploy.BucketDeployment(this, 'JarDeployment', {
sources: [s3deploy.Source.asset('./target')],
destinationBucket: jarBucket,
destinationKeyPrefix: 'jars/',
});
// Ensure MSF application is created AFTER the JAR is uploaded
flinkApp.node.addDependency(jarDeployment);Terraform: depends_on for Upload Ordering
In Terraform, use aws_s3_object to upload the JAR and add an explicit depends_on to the MSF application resource:
resource "aws_s3_object" "app_jar" {
bucket = aws_s3_bucket.jar_bucket.id
key = "jars/my-app.jar"
source = "target/my-app.jar"
etag = filemd5("target/my-app.jar")
}
resource "aws_kinesisanalyticsv2_application" "flink_app" {
name = "my-flink-app"
runtime_environment = "FLINK-2_2" # Default for new apps. Use FLINK-1_20 only when migrating an existing 1.20 app and state compatibility forbids the upgrade.
service_execution_role = aws_iam_role.flink_role.arn
application_configuration {
application_code_configuration {
code_content {
s3_content_location {
bucket_arn = aws_s3_bucket.jar_bucket.arn
file_key = aws_s3_object.app_jar.key
}
}
code_content_type = "ZIPFILE"
}
# ... other configuration
}
depends_on = [aws_s3_object.app_jar]
}IAM Role Configuration
The MSF application's IAM execution role needs permissions for all AWS resources the application accesses. A common mistake is missing permissions, which causes the application to fail at runtime rather than at deployment.
Minimum Required Permissions
Every MSF application needs at minimum:
# CloudWatch Logs (required for application logging)
# Scope to the application's log group, not log-group:* — that grants logs
# permissions across every group in the account.
- Effect: Allow
Action:
- logs:PutLogEvents
- logs:DescribeLogStreams
Resource:
- !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/kinesis-analytics/${ApplicationName}"
- !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/kinesis-analytics/${ApplicationName}:log-stream:*"
# DescribeLogGroups does not support resource-level permissions
- Effect: Allow
Action:
- logs:DescribeLogGroups
Resource: "*"
# S3 JAR bucket (required to read the application JAR), and KMS permissions if encrypted by a CMK
- Effect: Allow
Action:
- s3:GetObject
- s3:GetObjectVersion
Resource:
- !Sub "${JarBucket.Arn}/*"Common Source/Sink Permissions
Kinesis Data Streams (source):
- Effect: Allow
Action:
- kinesis:DescribeStream
- kinesis:GetShardIterator
- kinesis:GetRecords
- kinesis:ListShards
- kinesis:DescribeStreamSummary
- kinesis:DescribeStreamConsumer
- kinesis:SubscribeToShard # Required for EFO
- kinesis:RegisterStreamConsumer # Required for EFO
- kinesis:DeregisterStreamConsumer # Required for EFO
Resource:
- !GetAtt KinesisStream.Arn
- !Sub "${KinesisStream.Arn}/consumer/*" # Required for EFOKinesis Data Streams (sink):
- Effect: Allow
Action:
- kinesis:PutRecord
- kinesis:PutRecords
- kinesis:DescribeStream
- kinesis:DescribeStreamSummary
Resource:
- !GetAtt OutputKinesisStream.ArnS3 (sink):
- Effect: Allow
Action:
- s3:PutObject
- s3:GetObject
- s3:ListBucket
- s3:DeleteObject
- s3:GetBucketLocation
- s3:AbortMultipartUpload
- s3:ListMultipartUploadParts
Resource:
- !GetAtt OutputBucket.Arn
- !Sub "${OutputBucket.Arn}/*"Kafka/MSK (source or sink):
# VPC access for MSK. The describe* and *NetworkInterface* actions don't
# accept ARN-scoped resources, so the resource has to be "*" — but you can
# (and should) constrain them with condition keys to the specific VPC/region.
# Example: ec2:Vpc on the network-interface actions, aws:RequestedRegion on
# the describe actions. See guideline 10 (condition keys) below.
- Effect: Allow
Action:
- ec2:DescribeVpcs
- ec2:DescribeSubnets
- ec2:DescribeSecurityGroups
- ec2:DescribeDhcpOptions
- ec2:CreateNetworkInterface
- ec2:CreateNetworkInterfacePermission
- ec2:DescribeNetworkInterfaces
- ec2:DeleteNetworkInterface
Resource: "*"
Condition:
StringEquals:
aws:RequestedRegion: !Ref AWS::Region
# For CreateNetworkInterface / CreateNetworkInterfacePermission you can
# additionally constrain to the application's VPC:
# ArnEquals:
# ec2:Vpc: !Sub "arn:aws:ec2:${AWS::Region}:${AWS::AccountId}:vpc/${VpcId}"IAM Anti-Patterns
Do not use
*for resource ARNs in production. Scope permissions to the specific streams, buckets, and log groups the application uses.Do not grant
s3:*orkinesis:*. Use the minimum set of actions listed above.Do not forget the consumer sub-resource ARN for EFO.
SubscribeToShardrequires permissions onstream/*/consumer/*, not just the stream ARN.
MSF Application Resource Configuration
CloudFormation AWS::KinesisAnalyticsV2::Application
Key configuration sections and their correct usage:
FlinkApplication:
Type: AWS::KinesisAnalyticsV2::Application
Properties:
ApplicationName: !Ref ApplicationName
RuntimeEnvironment: !Ref FlinkRuntimeEnvironment # FLINK-2_2 (default for new apps). FLINK-1_20 only for in-place upgrades of existing 1.20 apps.
ServiceExecutionRole: !GetAtt FlinkRole.Arn
ApplicationConfiguration:
# JAR location — JAR must exist before this resource is created
ApplicationCodeConfiguration:
CodeContent:
S3ContentLocation:
BucketARN: !GetAtt JarBucket.Arn
FileKey: !Ref JarS3Key
CodeContentType: ZIPFILE
# Runtime properties — equivalent to MSF console "Runtime properties"
EnvironmentProperties:
PropertyGroups:
- PropertyGroupId: "kinesis.source"
PropertyMap:
stream.arn: !GetAtt InputStream.Arn
aws.region: !Ref AWS::Region
- PropertyGroupId: "s3.sink"
PropertyMap:
bucket.name: !Ref OutputBucket
path.prefix: "output/"
# Parallelism and scaling
FlinkApplicationConfiguration:
ParallelismConfiguration:
ConfigurationType: CUSTOM
Parallelism: !Ref Parallelism # Total parallelism (= KPU count × par/KPU)
ParallelismPerKPU: !Ref ParallelismPerKPU
AutoScalingEnabled: true
CheckpointConfiguration:
ConfigurationType: CUSTOM
CheckpointingEnabled: true
CheckpointInterval: 60000
MinPauseBetweenCheckpoints: 5000
MonitoringConfiguration:
ConfigurationType: CUSTOM
LogLevel: INFO
MetricsLevel: APPLICATIONKey Configuration Notes
RuntimeEnvironment: For new applications, useFLINK-2_2(production-recommended default). UseFLINK-1_20only when migrating an existing 1.20 application and state compatibility prevents an in-place upgrade (see flink-2x-migration.md for state-break patterns). The valid enum values come from thekinesisanalyticsv2API; the version-segment format mirrors the underlying Flink minor version with an underscore separator (FLINK-<major>_<minor>). For the full list of accepted values, see thekinesisanalyticsv2 create-applicationCLI reference, and for migration steps see flink-2x-migration.md.CodeContentType: AlwaysZIPFILEfor JAR files (this is the correct value despite the name).ConfigurationType: Set toCUSTOMto override defaults. If set toDEFAULT, the service ignores your parallelism/checkpoint settings.Parallelism: This is the total parallelism, which equals KPU count × ParallelismPerKPU. For example, 8 KPUs with ParallelismPerKPU=1 means Parallelism=8.AutoScalingEnabled: Set totruefor production workloads. See Resource Optimization for auto-scaling behavior details.MetricsLevel: UseAPPLICATIONfor production.OPERATOR,TASK, andPARALLELISMlevels increase CloudWatch metric cardinality and cost significantly.
Deployment Script Patterns
Build, Deploy, and Start Pattern
A complete deployment script should handle: build → infrastructure deploy → JAR upload → app deploy → code update → start.
Key considerations:
Always build the JAR first and verify it exists before uploading.
Use
aws cloudformation deploy(or equivalent) with--no-fail-on-empty-changesetto make scripts idempotent.After updating the JAR in S3, call
UpdateApplicationwith the new S3 object version to point the running application at the new code.Starting the application is a separate API call (
StartApplication) — CloudFormation creates the application in a stopped state.
Updating a Running Application's Code
To deploy new code to an existing MSF application:
# 1. Upload new JAR
aws s3 cp target/my-app.jar s3://${JAR_BUCKET}/${JAR_KEY}
# 2. Get current application version
CURRENT_VERSION=$(aws kinesisanalyticsv2 describe-application \
--application-name my-app \
--query 'ApplicationDetail.ApplicationVersionId' \
--output text)
# 3. Update application code reference
aws kinesisanalyticsv2 update-application \
--application-name my-app \
--current-application-version-id ${CURRENT_VERSION} \
--application-configuration-update '{
"ApplicationCodeConfigurationUpdate": {
"CodeContentUpdate": {
"S3ContentLocationUpdate": {
"BucketARNUpdate": "arn:aws:s3:::'"${JAR_BUCKET}"'",
"FileKeyUpdate": "'"${JAR_KEY}"'"
}
},
"CodeContentTypeUpdate": "ZIPFILE"
}
}'
# 4. Pick up the new code based on current application state.
# From RUNNING, update-application auto-restarts the app (UPDATING → RUNNING,
# typically 10–30s downtime depending on state size) — no explicit stop/start needed.
# From READY (stopped), update-application stays in READY — start the app explicitly
# to pick up the new code.
# See application-lifecycle.md for the full state-transition table.
STATUS=$(aws kinesisanalyticsv2 describe-application \
--application-name my-app \
--query 'ApplicationDetail.ApplicationStatus' --output text)
if [ "$STATUS" = "READY" ]; then
aws kinesisanalyticsv2 start-application --application-name my-app \
--run-configuration '{
"ApplicationRestoreConfiguration": {
"ApplicationRestoreType": "RESTORE_FROM_LATEST_SNAPSHOT"
}
}'
fi
# Otherwise (RUNNING/UPDATING), poll describe-application until ApplicationStatus
# returns to RUNNING to confirm the auto-restart completed.For guidance on troubleshooting errors after a Flink job upgrade, see first-fault-isolation.md.
Avoid an explicit stop-application → start-application cycle for code updates on a
RUNNING app. That pattern incurs a full graceful-stop drain plus cold start instead
of the ~10–30s in-place restart that update-application performs, and it
contradicts the lifecycle guidance in application-lifecycle.md.
Teardown
When deleting MSF resources:
Stop the application first (
StopApplicationAPI orForce=trueif stuck).Delete the application stack (MSF application resource).
Delete the infrastructure stack (buckets, streams, etc.).
S3 buckets with objects require emptying before CloudFormation can delete them — use a custom resource or script.
CloudFormation vs CDK vs Terraform Comparison for MSF
| Aspect | CloudFormation | CDK | Terraform |
|---|---|---|---|
| JAR upload handling | Manual (script between stack deploys) | BucketDeployment construct or manual | aws_s3_object resource with depends_on |
| Two-phase deployment | Two separate templates | Two stacks or dependency ordering | depends_on between resources |
| Application properties | Inline YAML PropertyGroups | Typed constructs | HCL environment_properties block |
| Drift detection | Supported | Via CloudFormation | Via terraform plan |
| Rollback | Automatic on stack failure | Via CloudFormation | Manual terraform apply with previous state |
Common IaC Mistakes to Avoid
Single-stack MSF deployment without pre-uploaded JAR — The MSF application resource will fail if the JAR doesn't exist in S3. Always use two-phase deployment.
Missing IAM permissions — The application will start but fail at runtime. Test with the minimum permission set listed above.
Using
ConfigurationType: DEFAULTwith custom values — The service ignores your parallelism and checkpoint settings. Always useCUSTOM.Hardcoding stream names instead of ARNs — Use ARNs for cross-account and cross-region compatibility.
Forgetting CloudWatch log permissions — The application runs but produces no logs, making debugging impossible.
Not setting
CAPABILITY_NAMED_IAM— CloudFormation stacks with IAM roles require this capability flag.S3 bucket cleanup on delete — CloudFormation cannot delete non-empty S3 buckets. Add a custom resource or use
DeletionPolicy: Retainand clean up manually.
References
See Best Practices for application code patterns and configuration separation
See Resource Optimization for KPU sizing and parallelism configuration
See Monitoring and Metrics for CloudWatch alarm setup
See Logging Configuration for CloudWatch Logs setup
See Kinesis Connector Guide for EFO IAM permissions
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an MCP server
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- AWS
- Publisher
- AWS (Official)
- Source
- aws/agent-toolkit-for-aws · plugins/aws-data-analytics/skills/developing-applications-on-managed-service-for-apache-flink · commit 0a218f8
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- NOTICE (added by AutoGineer from NOTICE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- aws/agent-toolkit-for-aws
AutoGineer is not affiliated with or endorsed by AWS or AWS.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download developing-applications-on-managed-service-for-apache-flink.zip