feat: add opt-in minimizeRdsVpcEndpoints to the SQL data source strategy by Simone319 · Pull Request #3449 · aws-amplify/amplify-category-api

Simone319 · 2026-03-26T14:25:40Z

Description of changes

Adds an opt-in minimizeRdsVpcEndpoints field to the SQL data source strategy (SQLLambdaModelDataSourceStrategy).

When a SQL (RDS) data source is installed into a VPC, the transformer provisions a set of interface VPC endpoints so the SQL Lambda can reach AWS services. Historically it always provisioned five endpoints — ssm, ssmmessages, ec2, ec2messages, kms — but at runtime the SQL Lambda only consumes the ssm endpoint (to read the database connection secret). The other four are unused and incur ongoing cost. minimizeRdsVpcEndpoints lets a customer opt into provisioning only the ssm endpoint:

`minimizeRdsVpcEndpoints`	Interface VPC endpoints provisioned
`false` (default)	`ssm`, `ssmmessages`, `ec2`, `ec2messages`, `kms` (5)
`true`	`ssm` (1)

The field lives next to vpcConfiguration on the SQL strategy and only takes effect when vpcConfiguration is set; it is a no-op for SQL data sources that are not installed into a VPC.

const strategy: SQLLambdaModelDataSourceStrategy = {
  name: 'MySqlStrategy',
  dbType: 'MYSQL',
  dbConnectionConfig: { /* ... */ },
  vpcConfiguration: { /* vpcId, securityGroupIds, subnetAvailabilityZoneConfig */ },
  minimizeRdsVpcEndpoints: true, // opt in: provision only the `ssm` endpoint
};

Why scope it to the SQL data source strategy (not a global flag)?

VPC-endpoint provisioning is a property of an individual SQL (RDS) data source — it is only meaningful for a SQL strategy that declares a vpcConfiguration. A backend can define multiple data sources, so a global TransformParameter / translationBehavior flag would apply indiscriminately and could not express "minimize endpoints for this RDS data source but not that one." Placing the field on SQLLambdaModelDataSourceStrategy keeps the option next to the vpcConfiguration it modifies and scopes it precisely to the resource it affects. An earlier revision of this PR plumbed the flag through TransformParameters / translationBehavior; this revision removes that global plumbing in favor of the data-source-scoped field.

Why does the default stay `false`? (breaking-change rationale)

The default remains false (all five endpoints) deliberately. Removing endpoints from an already-deployed API is a destructive CloudFormation change: on the next deploy CFN deletes the four now-unreferenced AWS::EC2::VPCEndpoint resources. Defaulting to true, or minimizing unconditionally, would silently delete those endpoints from every existing RDS-in-VPC stack on redeploy. Gating the behavior behind an explicit opt-in means existing stacks are untouched until the customer knowingly enables the optimization.

Coordinated changes

This is 1 of 3 coordinated repository changes that surface minimizeRdsVpcEndpoints end-to-end:

aws-amplify/amplify-category-api (this PR) — adds the field to SQLLambdaModelDataSourceStrategy and rewires the RDS transformer consumer.
aws-amplify/amplify-data — surfaces the field in data-schema-types.
aws-amplify/amplify-backend — surfaces the field through backend-data.

Summary of code changes

Add minimizeRdsVpcEndpoints?: boolean (@default false) to SQLLambdaModelDataSourceStrategy — both the public construct type (amplify-graphql-api-construct) and the internal transformer interface (amplify-graphql-transformer-interfaces).
Rewire RdsModelResourceGenerator to read strategy.minimizeRdsVpcEndpoints (instead of context.transformParameters.minimizeRdsVpcEndpoints) and thread it into getSsmEndpoint / createRdsLambda, which provision ['ssm'] when enabled and the full five-endpoint set otherwise.
Remove the earlier global plumbing: minimizeRdsVpcEndpoints is deleted from TransformParameters, defaultTransformParameters, TranslationBehavior, PartialTranslationBehavior, and defaultTranslationBehavior.
Regenerate the amplify-graphql-api-construct .jsii / API.md for the moved public API surface (the diff is limited to the minimizeRdsVpcEndpoints move).

CDK / CloudFormation Parameters Changed

No CDK/CFN template parameters are added. When minimizeRdsVpcEndpoints: true, the number of provisioned AWS::EC2::VPCEndpoint resources for a VPC-bound SQL data source drops from five to one (ssm only). With the default (false), generated resources are unchanged.

Issue #, if available

Related to #3409

Description of how you validated changes

amplify-graphql-model-transformer unit tests — amplify-sql-resource-generator.test.ts: 12/12 pass, including:
- "provisions all five VPC endpoints by default (minimizeRdsVpcEndpoints defaults to false)"
- "provisions only the ssm VPC endpoint when minimizeRdsVpcEndpoints is enabled"
amplify-graphql-api-construct functional tests — sql-model-definition.test.ts: 7/7 pass, including "ssm as credential store with minimizeRdsVpcEndpoints enabled" (asserts the strategy-scoped field, not translationBehavior).
tsc builds pass for the affected packages (amplify-graphql-transformer-interfaces, amplify-graphql-transformer-core, amplify-graphql-transformer-test-utils, amplify-graphql-model-transformer); jsii regenerates cleanly for amplify-graphql-api-construct.

Checklist

PR description included
yarn test passes
E2E test run linked
Tests are changed or added
Relevant documentation is changed or added (and PR referenced)
New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
Any CDK or CloudFormation parameter changes are called out explicitly

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

…2e assertion [#3449] Released transformer (graphql-model-transformer@2.14.2) still emits all 5 endpoints in the Gen1 amplify-push e2e. The reduction to only 'ssm' is covered by the unit test sql-model-definition.test.ts. Re-enable once >=3.x ships.

…evert [#3449] Runs only the 4 affected RDS groups + prerequisites. Remove before merge.

sarayev · 2026-06-30T16:31:53Z

Nice cleanup — thanks for tracking this down! Removing those four unused VPC endpoints is a real cost win for customers, and the root-cause writeup in #3409 makes it easy to see why only ssm is actually needed. The diff is tight and the unit test update is spot-on.

I’ve got two things I’d like us to sort out before merging — one about communicating this to existing users, and one about the e2e tests. Details inline. 🙏

sarayev · 2026-06-30T16:31:54Z

-  // Although the Lambda function will only invoke SSM directly, internally the SDK makes calls to other services as well
-  const services = ['ssm', 'ssmmessages', 'ec2', 'ec2messages', 'kms'];
+  // Only the SSM VPC endpoint is needed for Lambda to access Parameter Store
+  const services = ['ssm'];


One thing worth calling out: for anyone who already has an RDS-in-VPC API deployed, the next amplify push / cdk deploy after they pick up this change will have CloudFormation delete these four endpoints from their live stack. Functionally that’s fine since nothing was using them — but it does mean an upgrade silently modifies their infrastructure.

Could we add a CHANGELOG / release-note entry flagging this? Folks running cost-anomaly alerts or compliance tooling on their VPCs will see four resources disappear and may wonder why. A one-liner like “RDS-in-VPC deployments will have four unused VPC endpoints (ssmmessages, ec2, ec2messages, kms) removed on next deploy — this is expected and safe” would save someone a confused investigation later.

Implemented as feature flag instead to avoid breaking existing user experience.

sarayev · 2026-06-30T16:31:54Z

    expect(rdsLambdaFunction.Properties.VpcConfig.SecurityGroupIds.length).toBeGreaterThan(0);

    expect(getResource(resources, `${resourceNames.sqlVpcEndpointPrefix}ssm`, CDK_VPC_ENDPOINT_TYPE)).toBeDefined();
+    // TODO(#3449): re-enable the reduced VPC-endpoint assertion (only 'ssm' expected) once graphql-model-transformer >=3.x ships in the released @aws-amplify/cli-internal that this Gen1 amplify-push e2e installs. The reduction is validated by the unit test sql-model-definition.test.ts (endpoints.length === 1).


I think these e2e assertions are a bit of a time bomb. They still expect all 5 endpoints (toBeDefined()), and they only pass today because the installed CLI pulls @aws-amplify/graphql-model-transformer from npm at 2.14.2, which still emits 5. Once this change ships and the published package updates, these will start failing on their own without anyone touching them.

The TODO points at graphql-model-transformer >=3.x, but I couldn’t find a timeline for a 3.x release — so this could sit as latent CI breakage for a while. Could we either:

flip the four assertions to toBeUndefined() now (with a short note on the Gen1 CLI version lag), or

gate them on the installed transformer version if that’s detectable?

Either way, a concrete tracking issue would be better than a version that may not land soon.

The feature flag approach no longer require the e2e trick.

…2e assertion [#3449] Released transformer (graphql-model-transformer@2.14.2) still emits all 5 endpoints in the Gen1 amplify-push e2e. The reduction to only 'ssm' is covered by the unit test sql-model-definition.test.ts. Re-enable once >=3.x ships.

…evert [#3449] Runs only the 4 affected RDS groups + prerequisites. Remove before merge.

Only the SSM VPC endpoint is needed for Lambda to access Parameter Store. The other 4 endpoints (ssmmessages, ec2, ec2messages, kms) are never used by the code but cost customers ~$350/year per AZ. Fixes #3409

…2e assertion [#3449] Released transformer (graphql-model-transformer@2.14.2) still emits all 5 endpoints in the Gen1 amplify-push e2e. The reduction to only 'ssm' is covered by the unit test sql-model-definition.test.ts. Re-enable once >=3.x ships.

…evert [#3449] Runs only the 4 affected RDS groups + prerequisites. Remove before merge.

…ts feature flag (default off)

svidgen

Looks good to me if @sarayev is also happy.

sarayev

LGTM as well 👍

Simone319 requested a review from a team as a code owner March 26, 2026 14:25

Simone319 added a commit that referenced this pull request Jun 30, 2026

ci(amplify-category-api-e2e-tests): add throwaway buildspec for RDS r…

d34b80b

…evert [#3449] Runs only the 4 affected RDS groups + prerequisites. Remove before merge.

Simone319 requested a review from a team as a code owner June 30, 2026 14:27

Simone319 added a commit that referenced this pull request Jun 30, 2026

chore: remove throwaway verify_rds_assertions.yml e2e spec [#3449]

7fdee35

sarayev reviewed Jun 30, 2026

View reviewed changes

Simone319 changed the title ~~fix: remove unnecessary VPC endpoints for RDS connections~~ feat: add minimizeRdsVpcEndpoints flag to opt into reduced RDS VPC endpoints Jul 3, 2026

Simone319 added a commit that referenced this pull request Jul 7, 2026

ci(amplify-category-api-e2e-tests): add throwaway buildspec for RDS r…

70d1fac

…evert [#3449] Runs only the 4 affected RDS groups + prerequisites. Remove before merge.

Simone319 added a commit that referenced this pull request Jul 7, 2026

chore: remove throwaway verify_rds_assertions.yml e2e spec [#3449]

5833a78

Simone319 force-pushed the fix/remove-unnecessary-vpc-endpoints branch from 71227ca to 4d59cd7 Compare July 7, 2026 23:09

Simone319 changed the title ~~feat: add minimizeRdsVpcEndpoints flag to opt into reduced RDS VPC endpoints~~ feat: add opt-in minimizeRdsVpcEndpoints to the SQL data source strategy Jul 7, 2026

Simone319 added 7 commits July 9, 2026 10:09

fix: remove unnecessary VPC endpoints for RDS connections

3a844e0

Only the SSM VPC endpoint is needed for Lambda to access Parameter Store. The other 4 endpoints (ssmmessages, ec2, ec2messages, kms) are never used by the code but cost customers ~$350/year per AZ. Fixes #3409

test: update sql-model-definition VPC endpoint count assertion to 1

6d879ef

ci(amplify-category-api-e2e-tests): add throwaway buildspec for RDS r…

cf15db1

…evert [#3449] Runs only the 4 affected RDS groups + prerequisites. Remove before merge.

chore: remove throwaway verify_rds_assertions.yml e2e spec [#3449]

fccb2ab

feat: gate RDS VPC endpoint minimization behind minimizeRdsVpcEndpoin…

430deed

…ts feature flag (default off)

feat: scope minimizeRdsVpcEndpoints to the SQL data source strategy

de5d4fd

Simone319 force-pushed the fix/remove-unnecessary-vpc-endpoints branch from 4d59cd7 to de5d4fd Compare July 9, 2026 10:33

chore: regenerate API report for minimizeRdsVpcEndpoints

eda5033

svidgen approved these changes Jul 9, 2026

View reviewed changes

Simone319 merged commit 6693c8f into main Jul 9, 2026
7 of 8 checks passed

Simone319 deleted the fix/remove-unnecessary-vpc-endpoints branch July 9, 2026 20:41

sarayev reviewed Jul 10, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: add opt-in minimizeRdsVpcEndpoints to the SQL data source strategy#3449

feat: add opt-in minimizeRdsVpcEndpoints to the SQL data source strategy#3449
Simone319 merged 8 commits into
mainfrom
fix/remove-unnecessary-vpc-endpoints

Simone319 commented Mar 26, 2026 •

edited

Loading

Uh oh!

sarayev commented Jun 30, 2026

Uh oh!

sarayev Jun 30, 2026

Uh oh!

Simone319 Jul 9, 2026

Uh oh!

sarayev Jun 30, 2026

Uh oh!

Simone319 Jul 9, 2026

Uh oh!

svidgen left a comment

Uh oh!

Uh oh!

sarayev left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Simone319 commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of changes

Why scope it to the SQL data source strategy (not a global flag)?

Why does the default stay false? (breaking-change rationale)

Coordinated changes

Summary of code changes

CDK / CloudFormation Parameters Changed

Issue #, if available

Description of how you validated changes

Checklist

Uh oh!

sarayev commented Jun 30, 2026

Uh oh!

sarayev Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

Simone319 Jul 9, 2026

Choose a reason for hiding this comment

Uh oh!

sarayev Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

Simone319 Jul 9, 2026

Choose a reason for hiding this comment

Uh oh!

svidgen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sarayev left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Simone319 commented Mar 26, 2026 •

edited

Loading

Why does the default stay `false`? (breaking-change rationale)