Pulumi Blog: Elisabeth Lichtie

Passwordless PostgreSQL: IAM Authentication with Pulumi

Elisabeth Lichtie — Fri, 13 Feb 2026 00:00:00 +0000

Managing database credentials is one of the persistent challenges in cloud infrastructure. Passwords need to be rotated, secrets need to be stored securely, and access needs to be carefully controlled. AWS IAM authentication for RDS offers a better way: instead of managing long-lived passwords, your applications authenticate using short-lived tokens generated from IAM credentials. This approach is more secure, eliminates password rotation overhead, and integrates seamlessly with your existing IAM policies. With Pulumi, you can set up this entire system using reusable components that make IAM authentication a standard part of your infrastructure.

Why IAM authentication for PostgreSQL?

Traditional database authentication relies on usernames and passwords. These credentials need to be stored somewhere secure, rotated regularly, and distributed to applications that need them. Each of these steps introduces complexity and potential security risks.

IAM authentication changes this model fundamentally. Instead of passwords, your applications generate authentication tokens on demand using their IAM credentials. These tokens are valid for only 15 minutes, eliminating the need for password rotation. Access control happens through IAM policies, which you’re already using to manage other AWS resources. The result is a more secure system that’s easier to maintain and audit.

The benefits become even more pronounced when you componentize this setup with Pulumi. Rather than repeating the same configuration steps for each database, you can build reusable components that handle IAM authentication setup automatically. This turns a complex, multi-step process into a simple, repeatable pattern that your entire team can use. In this post, we’ll cover an example that sets up the complete flow: an RDS cluster with IAM authentication, the necessary IAM roles and policies, and a Kubernetes application that connects using IAM tokens.

Architecture overview

This example sets up a complete environment with IAM-authenticated database access from a Kubernetes application. The architecture includes:

VPC with public and private subnets across multiple availability zones
EKS cluster for running containerized applications
Aurora PostgreSQL cluster with IAM authentication enabled
IAM roles and policies that connect Kubernetes service accounts to database access
A demo application that authenticates to the database using IAM tokens

The key integration point is IAM Roles for Service Accounts (IRSA), which allows Kubernetes pods to assume IAM roles. This means your application doesn’t need any AWS credentials stored in environment variables or mounted secrets. The pod’s service account automatically has the permissions it needs to generate database authentication tokens.

Setting up the RDS cluster with IAM authentication

The foundation of this setup is an RDS cluster configured to accept IAM authentication. With Pulumi’s componentized approach, you can encapsulate all the RDS configuration in a reusable component:

const rdsCluster = new RdsCluster("iam-postgres", {
 vpcId: vpc.vpc.id,
 vpcCidrBlock: vpc.vpc.cidrBlock,
 subnetIds: vpc.publicSubnets.map((s) => s.id),
 databaseName: DATABASE_NAME,
 masterUsername: MASTER_USERNAME,
 masterPassword: dbMasterPassword,
 instanceClass: "db.t4g.medium",
 engineVersion: "17.4",
 iamDatabaseUser: IAM_DB_USERNAME,
});

Inside the component, the critical configuration is iamDatabaseAuthenticationEnabled:

this.cluster = new aws.rds.Cluster(
 `${name}-cluster`,
 {
 engine: "aurora-postgresql",
 engineVersion: engineVersion,
 databaseName: args.databaseName,
 masterUsername: args.masterUsername,
 masterPassword: args.masterPassword,
 dbSubnetGroupName: subnetGroup.name,
 vpcSecurityGroupIds: [this.securityGroup.id],
 iamDatabaseAuthenticationEnabled: true,
 skipFinalSnapshot: true,
 tags: { Name: `${name}-cluster` },
 },
 { parent: this }
);

This single flag tells RDS to accept authentication tokens in addition to traditional passwords. The cluster still needs a master password for initial setup and administrative tasks, but your applications can use IAM authentication instead.

Creating the database user with IAM permissions

Enabling IAM authentication on the cluster isn’t enough. You also need to create a database user and grant it the special rds_iam role that allows IAM authentication. This is where Pulumi’s PostgreSQL provider comes in:

const dbSetup = new DbSetup(
 "iam-postgres",
 {
 dbEndpoint: rdsCluster.cluster.endpoint,
 dbName: DATABASE_NAME,
 masterUsername: MASTER_USERNAME,
 masterPassword: dbMasterPassword,
 iamUsername: IAM_DB_USERNAME,
 },
 { dependsOn: [rdsCluster.instance] }
);

The DbSetup component handles all the database-level configuration. It creates the IAM user and grants the necessary permissions:

// Create IAM-enabled database user
this.iamRole = new postgresql.Role(
 `${name}-iam-user`,
 {
 name: args.iamUsername,
 login: true,
 },
 { parent: this, provider: this.provider }
);

// Grant rds_iam role to enable IAM authentication
new postgresql.GrantRole(
 `${name}-grant-rds-iam`,
 {
 role: this.iamRole.name,
 grantRole: "rds_iam",
 },
 { parent: this, provider: this.provider }
);

The component also grants the necessary database privileges (CONNECT, USAGE, CREATE, and table operations). By encapsulating this in a component, you ensure that every IAM-authenticated database user is set up consistently with the correct permissions.

Configuring IAM policies for database access

The next piece is the IAM role and policy that allows applications to generate authentication tokens. This involves two parts: the role that the application assumes, and the policy that grants database access.

For Kubernetes applications, this uses IRSA (IAM Roles for Service Accounts). The RdsCluster component includes a method that creates the appropriate IAM role:

const rdsIamRole = rdsCluster.createIamRole(
 eksCluster.oidcProvider,
 NAMESPACE,
 SERVICE_ACCOUNT_NAME
);

This creates an IAM role with a trust policy that allows the specified Kubernetes service account to assume it:

assumeRolePolicy: pulumi
 .all([oidcProvider.arn, oidcProvider.url])
 .apply(([arn, url]) =>
 JSON.stringify({
 Version: "2012-10-17",
 Statement: [
 {
 Effect: "Allow",
 Principal: { Federated: arn },
 Action: "sts:AssumeRoleWithWebIdentity",
 Condition: {
 StringEquals: {
 [`${url}:sub`]: `system:serviceaccount:${namespace}:${serviceAccountName}`,
 },
 },
 },
 ],
 })
 ),

The role is then granted the rds-db:connect permission for the specific database user:

{
 Version: "2012-10-17",
 Statement: [
 {
 Effect: "Allow",
 Action: ["rds-db:connect"],
 Resource: `arn:aws:rds-db:${region}:${accountId}:dbuser:${resourceId}/${iamDatabaseUser}`,
 },
 ],
}

This policy is scoped to exactly one database user on one cluster. This level of granularity is one of the security advantages of IAM authentication: you can control database access with the same precision you use for other AWS resources.

Connecting from Kubernetes with IRSA

The application running in Kubernetes needs a service account annotated with the IAM role ARN:

this.serviceAccount = new k8s.core.v1.ServiceAccount(
 `${name}-sa`,
 {
 metadata: {
 name: args.serviceAccountName,
 namespace: args.namespace,
 annotations: {
 "eks.amazonaws.com/role-arn": args.iamRoleArn,
 },
 },
 },
 { parent: this, provider: args.provider }
);

When a pod uses this service account, EKS automatically configures the pod with temporary AWS credentials for the associated IAM role. The application can then use these credentials to generate database authentication tokens.

How IAM authentication works at runtime

The authentication flow happens at connection time:

%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#FF9900','primaryTextColor':'#232F3E','primaryBorderColor':'#232F3E','lineColor':'#666','secondaryColor':'#527FFF','tertiaryColor':'#fff'}}}%%
sequenceDiagram
autonumber
participant App as Application Pod
participant SDK as AWS SDK
participant STS as AWS STS
participant IAM as AWS IAM
participant RDS as RDS Aurora
rect rgb(255, 249, 230)
Note over App,SDK: Phase 1: Token Generation
activate App
App->>+SDK: generate_db_auth_token()
SDK->>+STS: Get temporary credentials (IRSA)
STS-->>-SDK: Return AWS credentials
SDK->>SDK: Sign auth request
SDK-->>-App: Return IAM token (15 min TTL)
deactivate App
end
rect rgb(235, 245, 255)
Note over App,RDS: Phase 2: Database Connection
activate App
App->>+RDS: Connect (user + IAM token)
activate RDS
RDS->>+IAM: Validate token & permissions
IAM-->>-RDS: Token valid + rds-db:connect allowed
RDS->>RDS: Verify rds_iam role
RDS-->>-App: Connection established
deactivate App
end
Note over App,RDS: 💡 Token expires after 15 minutes - generate new token per connection

The application uses the AWS SDK to call generate_db_auth_token(), passing the database endpoint, port, and username
The SDK uses the pod’s IAM credentials (provided automatically by IRSA) to sign the request and generate a token
The application connects to PostgreSQL using the IAM username and the token as the password
RDS validates the token against IAM, verifying that the caller has rds-db:connect permission for that database user
If the token is valid, the connection is established

Here’s what this looks like in Python:

def get_iam_token():
 """Generate an IAM authentication token for RDS"""
 client = boto3.client('rds', region_name=AWS_REGION)
 token = client.generate_db_auth_token(
 DBHostname=DB_ENDPOINT,
 Port=DB_PORT,
 DBUsername=DB_USER,
 Region=AWS_REGION
 )
 return token

def get_db_connection():
 """Create a database connection with IAM auth"""
 token = get_iam_token()
 return psycopg2.connect(
 host=DB_ENDPOINT,
 port=DB_PORT,
 database=DB_NAME,
 user=DB_USER,
 password=token,
 sslmode='require',
 sslrootcert=RDS_CA_CERT
 )

The token is valid for 15 minutes. Applications should generate a new token for each connection or implement token caching with refresh logic.

Testing the setup with the demo application

The example includes an interactive demo application that lets you test the IAM authentication setup. Once deployed, the application provides a web interface for creating tables, adding messages, and querying the database:

Deploy the infrastructure and access the demo app:

pulumi up
export APP_URL=$(pulumi stack output appUrl)
echo "Demo app: http://$APP_URL"

The application shows the database endpoint and IAM username it’s using, and provides buttons to create tables and add data. Behind the scenes, every database operation authenticates using IAM tokens, demonstrating that the entire authentication flow is working correctly.

The full code for this example is available at https://github.com/pulumi-demos/examples/tree/main/typescript/aws-iam-for-postgres. The example includes all the component code referenced in this post.

Make passwordless access your default

Wrap this IAM authentication setup in a Pulumi component and apply the same passwordless pattern to every RDS cluster your team runs.

Get started

Production considerations

This example demonstrates IAM authentication in a working environment, but you’ll want to make several adjustments for production use:

Network security: The example places RDS in public subnets to allow the PostgreSQL provider to connect during deployment. In production, place RDS in private subnets and ensure your deployment environment (like GitHub Actions or Pulumi Cloud) can reach the database for initial setup, either through a bastion host or VPN.

Connection pooling and performance: IAM tokens expire after 15 minutes. If you’re using connection pooling, you’ll need logic to refresh tokens before they expire. AWS recommends using IAM authentication only when your application creates fewer than 200 new connections per second. For higher connection rates, consider using Amazon RDS Proxy, which manages connection pooling and can reduce the overhead of IAM token generation.

Master password management: You still need a master password for database administration and for the initial user setup. Store this in AWS Secrets Manager or Pulumi ESC, and restrict access to it carefully.

Monitoring and auditing: Token generation via the AWS SDK is logged in CloudTrail. Note that CloudWatch and CloudTrail do not log database authentication attempts themselves, so you’ll need to rely on PostgreSQL’s native logging for connection monitoring.

Multi-region considerations: If your application runs in multiple regions, ensure that IAM policies and database access work correctly across regions. Token generation and validation must happen in the same region as the RDS cluster.

Cost: IAM authentication itself is free, but be aware that cross-AZ data transfer costs still apply for database connections.

Conclusion

IAM authentication for PostgreSQL transforms database credential management from a security burden into a seamless part of your infrastructure. By eliminating long-lived passwords, you reduce your attack surface and remove the operational overhead of password rotation. By integrating with IAM, you gain fine-grained access control and comprehensive audit logs.

Pulumi makes this setup practical and repeatable through componentization. The components in this example encapsulate the complexity of IAM authentication setup, making it easy to apply the same pattern across multiple databases and applications. This turns security best practices into your team’s default approach.

Whether you’re building a new application or improving the security posture of existing infrastructure, IAM authentication for RDS deserves consideration. The investment in setup pays dividends in security, maintainability, and operational simplicity.

Feature Flagging for Your Infrastructure

Elisabeth Lichtie — Sat, 06 Dec 2025 00:00:00 +0000

One of Pulumi’s foundational benefits is that it allows you to manage your infrastructure as software with rich programming languages, robust testing, and CI/CD patterns that you’d use with your application code. This post will cover applying another classic software development technique to your infrastructure: feature flagging. You can use feature flags to control change rollout, reduce the risk of new releases, and speed up the development of your infrastructure, the same way you do with your applications.

The examples in this post range from simply creating a flag and using it in a Lambda function to fully integrating with LaunchDarkly to build a comprehensive flagging system for your infrastructure.

Creating flags with Pulumi

Check out the code here: 01: Flag Application With LaunchDarkly.

When you define flags in your infrastructure as code, you can configure them alongside all the supporting infrastructure your code needs. You can also encourage flag creation as a best practice in Pulumi components or templates.

With Pulumi, you can use any Terraform provider to manage your feature flags, whether that’s LaunchDarkly, Statsig, Split, Flagsmith, or any other feature flagging tool with Terraform support. This lets you define flags, targeting rules, and the infrastructure they control in a single codebase. The example uses the LaunchDarkly provider to create flags and supporting infrastructure:

const flag = new launchdarkly.FeatureFlag("example-flag", {
 key: "exampleFlag",
 projectKey: "default",
 variationType: "boolean"
}, { provider });

The Lambda function evaluates the flag at runtime using the LaunchDarkly SDK key from environment variables, allowing you to toggle behavior without redeploying code.

Using flags to control infrastructure

Check out the code here: 02: Flaggable Infrastructure.

Before deploying this code, first deploy either 03 (for ESC Only) or 04 (for ESC and LaunchDarkly) so that the environment is created and available.

Once you have flags defined, you can use them to control infrastructure provisioning. Apply the same best practices you would for application feature flags: keep flags focused, remove them when they’re no longer needed, and document their purpose. In this example, a boolean flag controls whether internet-facing resources are created:

const config = new pulumi.Config();
const flags: Record<string, any> | undefined = config.getObject("flags");
const enableInternetAccess = flags ? flags["enableInternetAccess"] : false;

if (enableInternetAccess) {
 // Create Internet Gateway, public subnet, route table, and routes
}

To enable automatic infrastructure updates when flags change (as shown in examples 3 and 4), configure deployment settings in your stack. This requires:

The Pulumi GitHub App installed on your repository
Webhook configuration to trigger deployments when configuration values change

With these in place, changing a flag value automatically triggers a deployment.

Configuring values with ESC

Check out the code here: 03: ESC Auto-updating.

Ingesting config from ESC

Pulumi ESC provides a centralized way to manage configuration and secrets. For teams that don’t need the full feature set of a dedicated flagging service, you can store flag values directly in an ESC environment. Your infrastructure stack imports this environment and reads flag values at deployment time:

const pulumiProv = new pulumiservice.Environment("flaggingEnv", {
 name: "config",
 organization: pulumi.getOrganization(),
 yaml: new pulumi.asset.StringAsset(`values:
 pulumiConfig:
 flags:
 enableInternetAccess: 'true'`),
});

This approach keeps all configuration in one place, eliminates dependencies on external services, and works seamlessly with Pulumi’s existing stack configuration system. You can update flag values through the Pulumi CLI, API, or Cloud console.

Automatically triggering deployments with webhooks

There is some risk involved with automatically triggering updates. You can leave out the webhook and deploy manually if that’s safer for your team.

Set up a Pulumi Cloud webhook to automatically deploy infrastructure when ESC environment values change. The example creates an AWS Lambda function behind API Gateway that receives webhook events and triggers deployments via the Pulumi Deployments API:

const webhook = new pulumiservice.Webhook("escEnvironmentWebhook", {
 organizationName: pulumi.getOrganization(),
 displayName: "ESC Environment Change Webhook",
 payloadUrl: api.apiEndpoint.apply((endpoint) => `${endpoint}/webhook`),
 active: true,
 filters: ["environment_revision_created"],
});

When you update a flag value in ESC, the webhook fires, the Lambda identifies which stacks use that environment, and triggers their redeployment. This creates a continuous delivery pipeline for infrastructure configuration changes.

Flag your infrastructure with Pulumi

Define feature flags alongside the resources they control, store values in Pulumi ESC or your existing flagging service, and roll out infrastructure changes with less risk.

Get started

Ingesting flag values from LaunchDarkly

Check out the code here: 04: LaunchDarkly Auto-updating.

Ingesting flags from LaunchDarkly using ESC Connect

If your team already uses LaunchDarkly for application feature flags, you can integrate those same flags with your infrastructure using ESC Connect. This is also a good option if you need enterprise-grade features like advanced targeting rules or percentage rollouts.

This approach unifies application and infrastructure flag management. The ESC environment uses fn::open::external to query a Lambda function that fetches current flag values from LaunchDarkly:

values:
 pulumiConfig:
 flags: ${customSecrets.response}
 customSecrets:
 fn::open::external:
 url: ${getterUrl}
 request:
 secretName: ANY_SECRET
 secret: true

Your infrastructure code remains unchanged: it still imports the ESC environment and reads flag values the same way as in example 3. The difference is that flag values now come from LaunchDarkly, giving you access to advanced features like targeting rules, percentage rollouts, and flag scheduling.

Automatically triggering deployments with webhooks

There is some risk involved with automatically triggering updates. You can leave out the webhook and deploy manually if that’s safer for your team.

LaunchDarkly’s webhook system can trigger infrastructure updates whenever a flag changes. Here’s how the automation flow works:

graph LR
A[Update Flag in LaunchDarkly] --> B[LaunchDarkly Webhook]
B --> C[API Gateway]
C --> D[Lambda Function]
D --> E[Pulumi Deployments API]
E --> F[Infrastructure Updates]

When the infrastructure deploys, it retrieves the current flag values through ESC:

graph LR
A[Infrastructure Stack] --> B[ESC Environment]
B --> C[fn::open::external]
C --> D[Flag Getter Lambda]
D --> E[LaunchDarkly SDK]
E --> |Flag Value| D
D --> |Flag Value| C
C --> |Flag Value| B
B --> |Flag Value| A

The Lambda function is configured as a webhook endpoint in LaunchDarkly:

const launchDarklyWebhook = new LaunchDarklyWebhook("myWebhook", {
 pulumiProv: provCreation.pulumiEnv,
 flagKey: launchdarklyFlag.key,
 pulumiTokenSecret,
 lambdaRole,
}, { provider });

This creates a full automation loop: change a flag in LaunchDarkly’s UI, and your infrastructure automatically updates to reflect the new value. This pattern works with any feature flagging service that supports webhooks.

ESC Only vs ESC with LaunchDarkly

Both approaches enable automated infrastructure updates based on flag changes, but they suit different use cases:

Aspect	ESC Only (Example 3)	ESC with LaunchDarkly (Example 4)
Complexity	Simpler setup with fewer moving parts	More components but unified with application flags
Dependencies	No external services required	Requires LaunchDarkly subscription
Flag Management	Edit via Pulumi CLI or Cloud console	Edit via LaunchDarkly UI with full feature set
Advanced Features	Basic flag storage, versioning, and approvals	Targeting rules, percentage rollouts, experiments, scheduling
Best For	Teams wanting simple config management	Teams already using LaunchDarkly or needing sophisticated flag controls
Key Benefit	Centralized Pulumi-native configuration	Unified management of application and infrastructure flags

Conclusion

Infrastructure deserves the same development practices as application code. Feature flags let you control rollouts, reduce deployment risk, and coordinate changes across your entire system, not just in your applications, but in the infrastructure that supports them.

Pulumi makes infrastructure feature flagging practical. Whether you choose the simplicity of ESC-only flag management or integrate with an enterprise service like LaunchDarkly, you can build infrastructure that responds dynamically to configuration changes while maintaining the same development practices you use for application code.

Change Management with the Pulumi Kubernetes Operator and Kargo

Elisabeth Lichtie — Tue, 25 Nov 2025 00:00:00 +0000

The Pulumi Kubernetes Operator (PKO) enables you to manage Pulumi stacks as Kubernetes resources, but it doesn’t provide much guidance on change management. Kargo fills this gap by providing controlled, staged promotions with verification steps. Together, they let you keep your infrastructure defined in Pulumi while managing multi-environment rollouts in a systematic way.

This pattern is especially useful for platform teams that need to balance delivery speed with governance as environments and expectations scale.

Going to KubeCon Europe 2026?

Visit Pulumi at Booth 784 for live demos of Pulumi Kubernetes Operator and Kargo workflows for managing infrastructure change at scale.

What you can do with Argo CD, PKO, and Kargo

When you combine these tools, you gain several change management capabilities:

Control release timing: Determine when updates to your Pulumi program are released to different environments, rather than deploying everywhere at once.
Visualize deployments: See which environments are running which versions of your infrastructure code at a glance.
Automatic verification: Automatically verify deployment success before promoting changes to the next environment.
Approval gates: Set up discrete approval requirements before promotion, ensuring human review when needed.
Change tracking: Maintain a clear audit trail of what changed, when, and how it moved through your environments.

About Kargo

Kargo is a continuous promotion platform that manages how changes move through application lifecycle stages. While it’s commonly used for application deployments, it also works for infrastructure code managed by PKO.

The key concepts you’ll work with:

Freight: A packaged set of artifacts that move together through your pipeline. When integrating with PKO, this will typically be the pulumi program that defines your infrastructure and the git commit with the latest version.

Stages: Promotion targets that represent different lifecycle phases (like dev, staging, production). Each stage corresponds to a different PKO Stack resource managing that environment’s infrastructure.

Promotions: The process of moving freight from one stage to the next. Kargo updates the Stack resources to point to the promoted freight.

Warehouses: Monitors that watch your Git repository for infrastructure code changes and package new commits or releases as freight.

Projects: Organizational units that group related stages and warehouses, mapping to Kubernetes namespaces for access control.

When Kargo promotes freight to a stage, it updates the corresponding PKO Stack resource with the new Git reference. PKO then reconciles the stack, and your infrastructure changes are applied.

Example architecture

Workflow

To demonstrate how these tools work together, let’s look at an example setup that manages infrastructure code through a controlled promotion pipeline:

This architecture includes six main components working together:

Security Scanner repository: Contains your Pulumi infrastructure code. Kargo watches this repository for new commits or releases.
Kargo: Controls the release pipeline. When it detects new code in the security scanner repository, it triggers an update to promote that code to the next stage.
Kargo manifests repository: Stores the Kubernetes manifests that define PKO Stack resources. Kargo updates this repository with the new Git references when promoting freight.
Argo CD: Watches the Kargo manifests repository and creates or updates Stack objects in Kubernetes when it detects changes.
Pulumi Kubernetes Operator: Watches Stack objects and deploys them to Pulumi, triggering stack updates or previews.
Pulumi: Performs the actual infrastructure deployments and previews based on PKO’s instructions.

The workflow follows this pattern: Kargo detects new infrastructure code, updates the manifests repository with the new Git reference, Argo CD syncs the Stack objects to Kubernetes, PKO triggers Pulumi to deploy the changes, and Kargo verifies the successful deployment. This creates a closed loop where infrastructure changes are systematically promoted and verified at each stage.

Dashboard and Management

The Kargo dashboard brings operational visibility to this entire workflow. The timeline view at the top shows every freight version moving through your pipeline, making it immediately clear which infrastructure code version is running in each environment and how long it has been there.

The flow diagram above maps out your complete promotion path with color-coded stages. You can see at a glance where changes are flowing smoothly and where they are waiting at approval gates or blocked by failed verifications.

Status indicators on each stage show real-time health information, eliminating the need to manually check multiple systems or run status commands. This single-pane view reduces context switching, speeds up troubleshooting when issues arise, and gives an understanding of exactly what infrastructure is deployed where.

You can see the complete setup for this example, including configuration files and manifests, in the pulumi-operator-with-kargo-change-management repository.

Setting up the environment

The example repository contains three Pulumi projects that deploy in sequence:

cluster: Creates a basic Amazon EKS cluster where everything will run.
cluster-setup: Installs the required dependencies including PKO, cert-manager, Argo CD, Argo Rollouts, and AWS Cognito for authentication.
kargo: Deploys Kargo via Helm and provides examples to set up the project with stages, approval gates, and analysis templates for the promotion pipeline.

Configuring Kargo

Once Kargo is installed, you need to configure several components to set up your promotion pipeline.

Creating a project

Start by creating a Kargo project, which automatically creates a corresponding Kubernetes namespace.

Git credentials

Kargo needs access to your Git repositories to monitor for changes and update manifests. Create a secret with your Git credentials, labeled so Kargo recognizes it:

apiVersion: v1
kind: Secret
metadata:
 name: github-creds
 namespace: kargo-managed-stack
 labels:
 kargo.akuity.io/cred-type: git
stringData:
 repoURL: https://github.com/YOUR_REPO
 username: YOUR_USERNAME
 password: GITHUB_TOKEN

Setting up approver roles

To control who can approve promotions at approval gates, you can create custom roles with the promote permission. This requires three resources: a ServiceAccount with OIDC claim mapping, a Role with promotion permissions, and a RoleBinding to connect them. The easiest way to set up these resources is through the Kargo UI.

The screenshot shows a role configured with the promote verb on specific stages (like approvalgateqa), which allows users bound to this role to approve promotions at that gate. The role also includes permissions to create promotions and view other resources.

Project configuration

Use a ProjectConfig resource to control promotion policies for your project. This example enables automatic promotion for preview and deployment stages:

apiVersion: kargo.akuity.io/v1alpha1
kind: ProjectConfig
metadata:
 name: kargo-managed-stack
 namespace: kargo-managed-stack
spec:
 promotionPolicies:
 - stageSelector:
 name: devpreview
 autoPromotionEnabled: true
 - stageSelector:
 name: dev2preview
 autoPromotionEnabled: true
 - stageSelector:
 name: dev
 autoPromotionEnabled: true
 - stageSelector:
 name: dev2
 autoPromotionEnabled: true
 - stageSelector:
 name: qapreview
 autoPromotionEnabled: true
 - stageSelector:
 name: qa
 autoPromotionEnabled: true

This configuration automatically promotes freight through preview stages and dev environments, while approval gates remain manual.

Pulumi access token

Kargo needs access to the Pulumi API to verify that infrastructure deployments completed successfully. Create a secret in your project through the Kargo UI:

Navigate to your project in the Kargo UI
Navigate to Settings → Credentials
Select Create a new credential with:
- Name: pulumi-api-token
- Type: Opaque
- Key: PULUMI_ACCESS_TOKEN
- Value: Your Pulumi access token

This token allows Kargo’s analysis templates to query the Pulumi API and confirm that stack updates and previews ran successfully before promoting freight to the next stage.

Defining stages

Stages represent different points in your promotion pipeline. This example uses three types of stages to control how infrastructure changes move from development to production.

Preview stages

Preview stages run pulumi preview operations to show what changes would be applied without actually deploying them. These stages help catch issues early by validating that the infrastructure code is valid and showing the expected changes:

devpreview and dev2preview: Run previews for the dev environments
qapreview: Runs a preview for QA after passing approval gates

Preview stages automatically promote to their corresponding update stages once the preview completes successfully and verification passes.

Update stages

Update stages run pulumi up to actually deploy the infrastructure changes:

dev and dev2: Deploy changes to parallel dev environments for testing
qa: Deploy to the QA environment after all approvals

Update stages are configured to automatically promote once the deployment succeeds and verification confirms the infrastructure is in the expected state.

Approval gates

Approval gates are stages that require manual approval before freight can proceed. They act as checkpoints where designated approvers review changes before they move forward:

approvalgatedev: Manual checkpoint before dev deployments
approvalgateqa: Functional review gate before QA deployment
approvalgateqasec: Security review gate before QA deployment

The QA preview stage uses availabilityStrategy: All, meaning freight must pass through both approvalgateqa and approvalgateqasec before proceeding. This ensures both functional and security teams approve changes before they reach QA.

Custom approver roles

Different approval gates may require different approvers. Using the custom roles described earlier, you can grant specific users or groups the promote permission on individual approval gates. For example, security team members might have the promote permission on approvalgateqasec, while functional testers have it on approvalgateqa. This ensures the right people review changes at each checkpoint.

Manage Kubernetes change with Pulumi

Define your Pulumi stacks as Kubernetes resources, then promote and verify infrastructure changes across dev, staging, and production with controlled, staged rollouts.

Get started

Verification

After each stage completes, Kargo can verify that the operation succeeded before promoting to the next stage. This example uses analysis templates to query the Pulumi API and confirm deployments completed successfully.

Kargo uses Argo Rollouts for verification, so Argo Rollouts must be installed in your cluster.

Analysis templates

Analysis templates define how to verify a stage. They can make HTTP requests, run queries, or execute any checks you need. For Pulumi verification, the templates:

Wait for operations to complete: Include a delay to give Pulumi time to finish the preview or update operation
Query the Pulumi API: Make HTTP requests to the Pulumi API to retrieve the stack’s latest update information
Verify the commit ID: Check that the deployed commit matches the freight being promoted
Confirm success: Ensure the operation completed without errors

The analysis template uses the PULUMI_ACCESS_TOKEN secret created earlier to authenticate with the Pulumi API.

Custom verification standards

Analysis templates are flexible enough to enforce other standards your organization requires as well.

This gives you a way to codify your deployment standards and ensure they’re enforced automatically as infrastructure changes move through environments.

Conclusion

Combining the Pulumi Kubernetes Operator with Kargo gives you systematic control over how infrastructure changes move through your environments. Rather than manually managing deployments or pushing changes directly to production, you get automated promotions with verification steps, approval gates where human review is needed, and a clear audit trail of what changed and when. This approach is particularly valuable for teams managing multiple environments where infrastructure changes need to be tested and approved before reaching production. By defining your promotion pipeline as code with stages, approval gates, and verification templates, you ensure that your infrastructure changes follow the same rigorous process every time.

If you want to put this pattern into practice, you can see it live at KubeCon Europe 2026 (Booth 784) or register for our upcoming Zero to Production in Kubernetes workshop.

Try Pulumi for Free

Automatic Diagram Generation for Always-Accurate Diagrams

Elisabeth Lichtie — Mon, 22 Sep 2025 00:00:00 +0000

Architecture diagrams are one of the most tedious aspects of infrastructure management. Teams spend countless hours manually creating and updating visual representations of their systems, only to see them become outdated the moment infrastructure changes.

When you manage your infrastructure as code, you can automatically generate accurate, up-to-date diagrams directly from your IaC definitions and state. Pulumi’s preview capabilities let you anticipate exactly what changes will result from code modifications before deployment, providing the perfect foundation for automated diagramming workflows.

In this post, we’ll explore three practical approaches to automating diagram generation in your CI/CD pipeline:

Native Pulumi diagramming: Using Pulumi’s built-in diagramming capabilities to generate basic architecture diagrams that you can retrieve from GitHub Actions’ artifact archive
AI-powered diagramming: Leveraging the Claude app with Mermaid and Pulumi preview to generate detailed diagrams and automatically add them to pull requests for infrastructure changes
Pulumi Neo for enterprise diagramming: Using Pulumi’s AI-powered platform for organization-wide diagramming patterns, project-level and organization-level views, and intelligent customization for different stakeholders

These approaches eliminate manual diagramming work while ensuring your documentation stays current with your actual infrastructure, from simple automation to enterprise-scale intelligent diagramming.

Native Pulumi diagramming with GitHub Actions

Pulumi’s built-in pulumi stack graph command generates architecture diagrams directly from your deployed infrastructure state. This approach provides a reliable foundation for automated diagramming since it reflects your actual deployed resources rather than just the code.

Complete example: View the full working example on GitHub.

Here’s a complete GitHub Actions workflow that deploys infrastructure and automatically generates diagrams:

name: Pulumi Deploy & Diagram

on:
 push:
 branches: [main]

jobs:
 deploy:
 name: Deploy & Generate Diagram
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - name: Setup Node.js
 uses: actions/setup-node@v4
 with:
 node-version: "20"
 cache: "npm"

 - name: Install dependencies
 run: npm ci

 - uses: pulumi/actions@v5
 with:
 command: up
 stack-name: dev
 env:
 PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}

 - name: Install Pulumi CLI
 run: |
 curl -fsSL https://get.pulumi.com | sh
 echo "$HOME/.pulumi/bin" >> $GITHUB_PATH

 - name: Generate Architecture Diagram
 run: pulumi stack graph architecture.dot --stack dev
 env:
 PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}

 - name: Install Graphviz
 run: sudo apt-get update && sudo apt-get install -y graphviz

 - name: Generate PNG from DOT file
 run: dot -Tpng architecture.dot -o architecture.png

 - name: Upload Architecture Diagrams
 uses: actions/upload-artifact@v4
 with:
 name: architecture-diagrams
 path: |
 architecture.dot
 architecture.png

How the workflow works

This workflow follows a straightforward pattern that ensures your diagrams always reflect your deployed infrastructure:

Deploy first: The workflow uses the official pulumi/actions@v5 action to deploy your infrastructure changes. This ensures the state reflects your latest code.
Generate diagram from state: The pulumi stack graph command reads your deployed stack’s state and generates a DOT format file containing the resource relationships and dependencies.
Convert to visual format: Graphviz converts the DOT file into a PNG image that’s easy to view and share.
Archive as artifacts: Both the raw DOT file and the rendered PNG are uploaded as GitHub Actions artifacts, making them downloadable from the workflow run.

Key advantages and limitations

Highest accuracy: Since diagrams are generated from deployed state rather than code, they reflect your actual infrastructure including any drift or manual changes. This is the biggest advantage of the native approach.

Zero maintenance: Once set up, diagrams update automatically with every deployment without any manual intervention.

Multiple formats: The DOT format can be converted to various output formats (PNG, SVG, PDF) depending on your needs.

Audit trail: Each workflow run preserves the diagram as an artifact, creating a visual history of your infrastructure changes.

However, this approach has some limitations:

Fixed styling: You’re locked into Pulumi’s diagram style and layout algorithms, with limited customization options.

Basic aesthetics: The generated diagrams are functional but not always aesthetically polished compared to hand-crafted or AI-generated alternatives.

Technical focus: Diagrams show all resources and relationships, which can be overwhelming for non-technical stakeholders who need higher-level architectural views.

Accessing your diagrams

After each workflow run, you can download the generated diagrams from the Actions tab in your repository. Click on any workflow run, scroll to the “Artifacts” section, and download the architecture-diagrams package.

For a more sophisticated setup, you could extend this workflow to automatically commit diagrams back to your repository, post them to Slack, or integrate them with your documentation system.

AI-powered diagramming with Claude and Mermaid

The second approach leverages Claude’s ability to analyze Pulumi preview output and generate aesthetically pleasing, contextually relevant diagrams using Mermaid syntax. This method addresses the styling limitations of native Pulumi diagrams while maintaining accuracy through pulumi preview integration.

Complete example: View the full working example on GitHub.

The automated workflow

This approach uses two GitHub Actions workflows working together:

Auto-comment workflow (auto-pr-comment.yml):

name: Auto PR Comment

on:
 pull_request:
 types: [opened]
 paths:
 - 'index.ts'
 - 'Pulumi.yaml'
 - 'Pulumi.*.yaml'

jobs:
 comment:
 if: github.actor != 'claude-code[bot]'
 runs-on: ubuntu-latest
 permissions:
 contents: read
 pull-requests: write
 steps:
 - name: Comment on PR
 uses: actions/github-script@v7
 with:
 github-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
 script: |
 github.rest.issues.createComment({
 issue_number: context.issue.number,
 owner: context.repo.owner,
 repo: context.repo.repo,
 body: '@claude update the diagrams to reflect any infrastructure changes.'
 })

Claude integration workflow (claude.yml):

name: Claude Code

on:
 issue_comment:
 types: [created]
 pull_request_review_comment:
 types: [created]

jobs:
 claude:
 if: contains(github.event.comment.body, '@claude')
 runs-on: ubuntu-latest
 permissions:
 contents: write
 pull-requests: write
 issues: write
 steps:
 - name: Checkout repository
 uses: actions/checkout@v4

 - name: Run Claude Code
 uses: anthropics/claude-code-action@beta
 env:
 PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
 with:
 anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
 allowed_tools: "Bash(npm install),Bash(pulumi stack select prod),Bash(pulumi preview --json),Bash(npx mmdc)"
 custom_instructions: |
 ## Pulumi Infrastructure Diagramming Assistant

 ### Step 1: Analyze Infrastructure State
 - Run `npm install` and `pulumi stack select prod`
 - Execute `pulumi preview --json` to get detailed resource plan
 - Parse JSON output to understand resource relationships and changes

 ### Step 2: Generate/Update Diagrams
 Update Mermaid diagram files in `/diagrams/`:
 - aws-infrastructure.mmd: Technical AWS resource diagram
 - c4-context.mmd: System context diagram
 - c4-container.mmd: Container-level view
 - c4-component.mmd: Component-level architecture

 ### Step 3: Generate SVG Files
 Convert .mmd files to .svg using mmdc CLI

How the AI approach works

Automatic triggering: When a pull request with infrastructure changes is opened, the auto-comment workflow adds a @claude mention, triggering Claude’s analysis.
Infrastructure analysis: Claude runs pulumi preview --json to get detailed information about planned infrastructure changes, including resource relationships and dependencies.
Intelligent diagram generation: Claude analyzes the preview output and updates multiple Mermaid diagrams:
- AWS infrastructure diagram: Technical view showing resources, networking, and data flow
- C4 diagrams: Context, container, and component views for different stakeholder needs
Visual rendering: The mmdc CLI converts Mermaid syntax to SVG files for immediate viewing.
PR integration: Updated diagrams are committed directly to the pull request branch, making them visible in code review.

Example generated diagram

Here’s a sample of the AWS infrastructure diagram that Claude generates:

graph TB
subgraph VPC["myVpc - CIDR: 10.0.0.0/16"]
subgraph PublicSubnet["myPublicSubnet - CIDR: 10.0.1.0/24"]
EC2["myInstance<br/>Type: t2.micro<br/>AMI: Latest Amazon Linux 2"]
end
IGW["myInternetGateway<br/>Internet connectivity"]
SG["mySecurityGroup<br/>HTTP (80) + SSH (22) access"]
end
WEB_USER["Web Users"] -->|HTTP requests| IGW
IGW --> PublicSubnet
SG --> EC2

Key advantages and limitations

Intelligent styling: Claude generates aesthetically pleasing diagrams with consistent formatting, colors, and layout that’s much more polished than native Pulumi output.

Multiple perspectives: Creates different diagram types (technical infrastructure, C4 architecture views) suitable for different audiences and stakeholder needs.

Context awareness: Claude understands the purpose and relationships of resources, creating meaningful groupings and flow representations.

Automated maintenance: Diagrams update automatically with infrastructure changes, staying current without manual intervention.

Integration with code review: Diagrams appear directly in pull requests, making infrastructure changes visible during review.

However, this approach also has limitations:

Potential for inaccuracy: Unlike native Pulumi diagrams that are generated directly from infrastructure state, AI-generated diagrams depend on Claude’s interpretation of preview output. While generally reliable, there’s inherent risk of misinterpretation or missed details that could lead to diagram inaccuracies.

AI dependency: Diagram accuracy is only as good as Claude’s understanding of complex infrastructure relationships, which may occasionally miss nuances or make incorrect assumptions.

Setup complexity: Requires more configuration including API keys, GitHub app installation, and workflow permissions.

Cost considerations: Each diagram update consumes Claude API credits, though costs are typically minimal for most projects.

Preview limitations: Diagrams reflect planned changes from pulumi preview rather than actual deployed state, which may differ if deployments fail.

This approach works best for teams that value diagram aesthetics and need multiple architectural views for different stakeholders, while accepting slightly more complexity and potential accuracy trade-offs in exchange for significantly better visual presentation.

Generate diagrams from your code

You can produce accurate architecture diagrams directly from your Pulumi state and preview, then wire the workflow into any coding agent through the Pulumi MCP server. Start a project to keep your diagrams in sync with your infrastructure.

Get started

Pulumi Neo: Enterprise-scale intelligent diagramming

Pulumi Neo brings the next evolution in infrastructure diagramming, with AI-powered intelligence that enables organization-wide diagram generation. Unlike the previous approaches that focus on individual stacks, Pulumi Neo provides enterprise-scale diagramming capabilities with intelligent customization for different stakeholders.

How the workflow works

Pulumi Neo streamlines enterprise diagramming through an intelligent, organization-aware approach that scales across multiple projects and stakeholders:

Repository setup: Create a dedicated repository to host your architecture diagrams and ensure your GitHub App has access. The repository structure helps Neo understand your diagramming patterns:
- overview/ folder for organization-wide infrastructure views
- stacks/ folder for individual stack diagrams
- Template files that Neo can model new diagrams from
- README documentation explaining the repository’s purpose and conventions

Neo prompt engineering: Use structured prompts to guide Neo’s diagram generation with enterprise-grade specificity. You can also select your architecture diagram repository to tell Neo where to store his work:

1. Scope: Create diagrams for all resources in my prod Pulumi stacks
1. Diagram Types:
- Individual stack diagrams showing resources within each stack
- Master overview diagram showing cross-stack dependencies and data flow
1. Visual Standards:
- Use official AWS/Azure/GCP service icons from their architecture icon sets
- Show resource relationships with labeled connections (security groups, subnets, etc.)
- Group related resources visually (VPC boundaries, availability zones)
1. Content Focus:
- Infrastructure resources only (compute, storage, networking, databases)
- Resource dependencies and data flow directions
- Cross-stack references and shared resources
1. Format: Generate diagrams as Mermaid code that can be rendered in documentation

Automated pull request generation: Neo analyzes your entire organization’s infrastructure state, identifies changes, and automatically creates pull requests with updated diagrams for review and approval.

Complete example: You can see my resulting architecture diagrams repository on GitHub.

Key advantages and limitations

Pulumi Neo offers the most sophisticated approach to infrastructure diagramming, particularly for enterprise environments:

Enterprise-scale intelligence: Neo understands your entire organization’s infrastructure landscape, generating diagrams that show cross-project dependencies and organization-wide resource relationships that individual stack-based approaches cannot capture.

Style customization: Customize your prompts to request different styles of diagrams.

Organizational consistency: Maintains consistent diagramming standards across teams and projects, ensuring visual coherence in large organizations with multiple infrastructure teams.

Cross-stack visibility: Unlike single-stack approaches, Neo provides organization-wide infrastructure views showing how different projects and teams’ resources interconnect.

Template-driven generation: Learns from your existing diagram patterns and templates to maintain consistency with your established visual standards and conventions.

AI-powered context understanding: Goes beyond simple resource mapping to understand business context, automatically highlighting critical paths, security boundaries, and architectural patterns.

However, Neo also has limitations:

AI interpretation risks: Like the Claude approach, AI-generated diagrams may miss nuances or make incorrect assumptions about complex enterprise infrastructure relationships.

Repository access requirements: Neo requires permissions to open pull requests against your repository.

Learning investment: Getting maximum value from Neo requires developing sophisticated prompt engineering skills and understanding how to structure repositories for optimal AI comprehension.

Conclusion

Automating diagram generation transforms one of the most tedious aspects of infrastructure management into a seamless part of your development workflow. All three approaches eliminate the manual overhead of keeping architecture diagrams current while solving the core problem of documentation drift.

Choose native Pulumi diagramming when accuracy is paramount and you need diagrams that perfectly reflect your deployed infrastructure. This approach offers the highest reliability with minimal setup complexity.

Choose AI-powered diagramming when you need polished, stakeholder-friendly diagrams and can accept slightly more complexity for significantly better aesthetics and multiple architectural perspectives.

Choose Pulumi Neo when you need enterprise-scale diagramming with organization-wide consistency, multi-level views across projects and stacks, and intelligent customization for different stakeholders with varying technical backgrounds.

Regardless of which approach you choose, you’ll eliminate hours of manual work while ensuring your documentation stays synchronized with your infrastructure changes. With Pulumi Neo’s AI capabilities now available, intelligent, context-aware diagramming has moved from possibility to reality, making infrastructure documentation both effortless and incredibly powerful.

The future of infrastructure documentation is here: automated, intelligent, and always accurate. With these examples as your foundation, you’re ready to transform how your team approaches architecture visualization at any scale.

AWS RDS - Blue/Green Deployments for Low-Downtime Updates

Elisabeth Lichtie — Mon, 23 Jun 2025 00:00:00 +0000

AWS RDS supports blue/green deployments to support database maintenance. In a blue/green deployment, you have one production (blue) and one staging (green) database. You can safely make changes to the green instance without affecting production and promote it to be the main instance. When you enable blue/green updates, Pulumi will temporarily set up a blue/green deployment for the duration of the update to minimize downtime.

There are many benefits to using blue/green deployments for updates, especially for critical databases that need to be kept available and safe from untested changes.

How it works

By default, updates to a database will be applied in-place, meaning there may be service interruptions while a database is modified especially when making long-running updates like changing the engine version, parameter groups, or storage settings.

blueGreenUpdate can be enabled for Low-Downtime Updates. When this setting is on and an update is performed, the program starts the update by creating a blue/green deployment to maintain availability. Then, it performs the requested update on the green instance, performs a guardrail check, promotes the green instance, and finally deletes the old instance and removes the blue/green deployment. This leaves just the updated database running with minimal downtime during the update while minimizing the downtime.

Though this strategy typically increases the amount of time that updates need to run, it minimizes downtime for the application by keeping a current version of the database available during the update process.

How to use

Please see the full example code here: Blue/Green Deployment Updates on RDS. To use blue/green deployments for your database updates, start by creating a database and corresponding parameter group.

const dbVersion = "14.18";

const parameterGroup = new aws.rds.ParameterGroup(
 "parameter-group",
 {
 family: `postgres${dbVersion.split(".")[0]}`,
 parameters: [
 {
 name: "rds.logical_replication",
 value: "1",
 applyMethod: "pending-reboot",
 },
 ],
 },
 { deleteBeforeReplace: false } // This explicitly calls out that the new group should be created before the old is deleted so that database availability can be maintained
);

const database = new aws.rds.Instance(
 "rds-instance",
 {
 allocatedStorage: storageAllocation,
 engine: "postgres",
 engineVersion: dbVersion,
 instanceClass: aws.rds.InstanceType.T3_Micro,
 username: dbUsername,
 password: dbPW,
 storageEncrypted: true,
 backupRetentionPeriod: 7,
 blueGreenUpdate: { enabled: true },
 skipFinalSnapshot: true,
 parameterGroupName: parameterGroup.name,
 },
 { dependsOn: [parameterGroup] } //This line can be omitted since the dependency is also inferred by the reference to parameterGroup.name
);

After running pulumi up with the above code, you’ll have a database deployed and attached to your custom parameter group. It’s important to create and attach a custom parameter group so that you can keep it up to date with any engine version upgrades. If you use the default parameter group, updates to the database version may fail when the green deployment is created since its parameter group family won’t match the new version. You can avoid a failure by ensuring that the parameter group’s family and engineVersion are always changed in the same update.

You won’t see the effects of having blueGreenUpdate enabled until you run your first update. Change any part of the database configuration and run pulumi up again to start the update. In the example above, you can change dbVersion to 15.13 to trigger an update to both the parameter group and the instance.

Once the update kicks off, you can watch on AWS as the blue/green deployment is created and the original settings are copied to the green instance.

Then, the green instance will be updated with the new settings and the program will switch over to the green instance and clean up.

After that, your update has been completed with minimal disruption!

Additional Considerations

General limitations and considerations for Amazon RDS blue/green deployments are listed in the AWS documentation, but there are a few other considerations that should be taken into account when using them for updates with infrastructure as code (IaC).

No Custom Checks: Because IaC will automatically perform the switchover when the update is complete, you will not have the opportunity to perform custom checks on the green instance before promoting it. RDS will run some basic guardrails checks before performing the switchover, but you will not be able to perform any additional checks.
No Cluster Support: This feature only works with database instances, not with clusters or instances that are in a cluster.
Long Update Times: Because the IaC program will deploy temporary resources before performing the update and destroy them after, blue/green updates will take considerably longer than their in-place counterparts.
Manual Cleanup: Because the green instance and blue/green deployment are temporary resources designed to decrease downtime during the update, they are not tracked in the IaC state. If the update fails partway through, these temporary resources may have to be cleaned up manually. If the update is interrupted, you can delete the blue/green deployment and green database to get back into a manageable state.
Resource ID Change: On an update, the resource ID of the database might change since a new instance has been created. The endpoint and other details about the database will be maintained by AWS during switchover, but the resource ID should be dynamically retrieved from the stack outputs whenever it is used to ensure it stays up to date. Usually, no application or connection details will need to be updated since they don’t rely on the resource ID itself.
Types Of Updates: The blue/green update strategy will be used for changes that require a maintenance window including updates to the engine version, parameter group, storage and performance settings, and optimized writes.