feat(core): add CDK-level VPC support - #277
Draft
svidgen wants to merge 25 commits into
Draft
Conversation
Phase 1 VPC integration for AWS Blocks: - Add BlocksVpcOptions types to packages/core/src/cdk/vpc-types.ts - Add registerVpcRequirements() method to CDK Scope class - Add VPC initialization and finalization to BlocksStack/BlocksBackend - Add vpc prop to BlocksStack.create() and BlocksBackend.create() - Lambda handler is placed in private subnets with security group when VPC enabled - Finalization step: walk scope tree → collect requirements → deduplicate → provision endpoints - SSM and CloudWatch Logs endpoints always included when VPC is enabled Per-BB VPC requirement declarations: - bb-kv-store: dynamodb (gateway) - bb-distributed-table: dynamodb (gateway) - bb-file-bucket: s3 (gateway) - bb-data: secretsmanager + rds-data (interface), subnet role: isolated - bb-distributed-data: none (DSQL uses public HTTPS) - bb-async-job: sqs (interface) - bb-agent: bedrock-runtime (interface) - bb-knowledge-base: bedrock-runtime (interface) - bb-email-client: ses (interface) - bb-app-setting: ssm (interface) - bb-realtime: execute-api (interface) - bb-auth-cognito: ssm (interface) - bb-auth-oidc: ssm (interface) bb-data refactor: - materialize() checks for VPC context before creating its own VPC - When shared VPC is available, Aurora is placed in isolated subnets - Security group rule: Lambda SG → Aurora on port 5432 - Falls back to creating isolated VPC when no shared VPC (backward compatible) Test infrastructure: - test-apps/vpc-smoke/ with inline VPC creation - Instantiates KVStore, DistributedTable, FileBucket, AsyncJob, AppSetting - Exercises auto endpoint detection Design doc added at docs/design/VPC-DESIGN.md
🦋 Changeset detectedLatest commit: 4213fe6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 22 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
…istent VPC 1. Remove string→endpoint mapping: BBs now call registerVpcEndpoint() with actual CDK service objects (GatewayVpcEndpointAwsService or InterfaceVpcEndpointAwsService). The collection layer deduplicates by service identity and provisions directly. No intermediate string mapping table. 2. Test ALL BBs in vpc-smoke: KVStore, DistributedTable, FileBucket, AsyncJob, AppSetting, Realtime, AuthCognito, Logger, Metrics, and Tracer all have at least one round-trip assertion in the vpc-smoke test app. 3. Persistent test VPC (test-infra/): Creates a VPC with 2 AZs, 1 NAT, public/private/isolated subnets, and pre-provisions common endpoints (DynamoDB, S3, SSM, Secrets Manager, CloudWatch Logs). Deployed once and NOT torn down between test runs. The vpc-smoke app references it via Vpc.fromLookup() using the VPC_TEST_VPC_ID env var.
…rora in test VPC - Add Database BB (Aurora via fromExisting) to vpc-smoke test app - Add Aurora Serverless v2 cluster + RDS Data API endpoint to test-infra VPC stack - Add Realtime client-side subscribe test (WebSocket within VPC) - Add Database smoke tests: SELECT 1 and create/insert/read/drop Verified: registerVpcEndpoint is correctly wired on Scope (protected method delegates to free function). BlocksBackend already accepts and wires vpc prop identically to BlocksStack. Design doc already matches latest draft.
- Split registerVpcEndpoint (instanceof-based) into two explicit methods:
registerVpcGatewayEndpoint / registerVpcInterfaceEndpoint
- Simplify BlocksVpcOptions to { vpc, subnets?, provisionEndpoints? }
- Rename lambdaSubnets → subnets
- Replace endpoints: 'auto' | 'none' with provisionEndpoints boolean
- Remove VpcEndpointRegistration type from public API
- Update all 12 BB packages to use new explicit registration methods
- Strip persistent test VPC (test-infra/vpc-test-stack.ts) to bare minimum:
VPC + subnets (2 AZs) + 1 NAT + VPC ID output only
- Update vpc-smoke Database test: no connection option, self-provisions Aurora
- Update VPC-DESIGN.md to reflect simplified API
- Add changeset (@aws-blocks/core: minor, all touched BBs: patch)
…ehensive suite) The test was importing BB instances directly which fails under the browser condition (-C browser). Now the backend exposes an ApiNamespace with methods that exercise each BB, and the test calls them via the generated RPC client — same as the comprehensive e2e suite.
…n smoke test Two fixes: 1. finalizeVpc now creates endpoints as standalone constructs in the app scope, not via vpc.addXxx() (which puts them in the VPC's own scope/stack) 2. vpc-smoke uses provisionEndpoints: false temporarily — the persistent test VPC has stale endpoints from earlier failed runs that conflict. Once account is cleaned up, re-enable to test auto-provisioning.
…port Avoids the workspace name conflict and module resolution issues entirely. The test reads the API URL from sandbox outputs and makes direct JSON-RPC calls to the deployed Lambda — no generated client.js needed.
…p vpc-ref minimal Root cause: the vpc-ref lookup stack persisted between runs because destroySandbox only targeted the main stack. Now: - sandbox-destroy uses 'cdk destroy --all' to clean up everything - vpc-ref stack tagged with destroy removal policy - after hook is still try/catch for safety but should now succeed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CDK-Level VPC Support (Phase 1)
Customer DX
That's it. Blocks handles:
How it works
Each BB registers its VPC requirements in its CDK constructor:
At finalization (after all BBs are constructed), the framework walks the scope tree, collects registered endpoints, deduplicates, and provisions them against the VPC. SSM + CloudWatch Logs are always included.
bb-data (Aurora) detects the VPC context on its scope chain. If present, it places Aurora in the shared VPC's isolated subnets and wires SG rules. If absent, it falls back to creating its own standalone VPC (existing behavior preserved).
API
What's included
vpcprop onBlocksStackandBlocksBackendregisterVpcGatewayEndpoint/registerVpcInterfaceEndpointon CDK Scopetest-infra/persistent test VPC stacktest-apps/vpc-smoke/E2E smoke suitedocs/design/VPC-DESIGN.mdWhat's NOT included (Phase 2, after configurable compute)
VpcNetworkBuilding Block (per-handler VPC opt-in)See
docs/design/VPC-DESIGN.mdfor the full design.