Aws Cdk

3 posts

aws2 min readCurated summary

Accelerate your infrastructure deployments by up to 4x with AWS CloudFormation Express mode | Amazon Web Services

AWS CloudFormation Express mode speeds deployments by marking them complete once resource configuration is applied, rather than waiting for full stabilization checks. AWS says this can reduce deployment times by up to four times, while resources continue becoming operational in the background. It is intended for rapid infrastructure iteration and scenarios where eventual stabilization is acceptable, not workflows requiring resources to be fully ready before proceeding. ## How Express Mode Works - Standard CloudFormation deployments wait for post-configuration stabilization checks. - Express mode completes earlier, immediately after configuration is applied. - Resources continue stabilizing asynchronously. - CloudFormation retries dependent resources that encounter transient provisioning failures. - The provisioning process itself is unchanged; only the point at which deployment completion is reported changes. ## Performance Improvements - Creating an SQS queue with a dead-letter queue took: - Standard mode: 64 seconds - Express mode: up to 10 seconds - Deleting a Lambda function with attached network interfaces took: - Standard mode: 20–30 minutes - Express mode: up to 10 seconds in AWS’s benchmark ## Best Use Cases - Iteratively building infrastructure one component at a time. - Testing individual application components. - AI-assisted infrastructure development requiring sub-minute feedback. - Production workflows that can tolerate resources stabilizing after deployment completion. ## Enabling Express Mode - In the AWS Console, select **Enable** under stack deployment options. - With the CLI or SDKs, set the deployment configuration mode to `EXPRESS`: ```bash aws cloudformation create-stack \ --stack-name my-app \ --template-body file://template.yaml \ --deployment-config '{"mode": "EXPRESS", "disableRollback": true}' ``` - AWS CDK supports: ```bash cdk deploy --express ``` - No CloudFormation template changes are required. - Express mode supports existing templates, change sets, nested stacks, and IaC or AI tools such as Kiro. - Enabling it on a parent stack also applies it to nested stacks. ## Rollback and Operational Considerations - Rollback is disabled by default in Express mode to maximize iteration speed. - For production use, rollback can be restored with `"disableRollback": false`. - Teams should otherwise provide monitoring and cleanup procedures for failed deployments. - IAM templates should continue following least-privilege principles. ## Availability - Express mode is available at no additional cost in all AWS commercial Regions. - AWS recommends standard deployment behavior when resources must be fully operational before traffic shifting or testing. For fast development and AI-driven infrastructure iteration, Express mode is a useful optimization. Use it selectively, while retaining standard mode—or explicitly enabling rollback—when deployment readiness and failure recovery are critical.

Read original(opens in new tab)
aws3 min readCurated summary

The AWS MCP Server is now generally available | Amazon Web Services

The AWS MCP Server is now generally available as a managed way for AI agents to access AWS securely through IAM-authenticated tools. It combines live AWS documentation, access to more than 15,000 API operations, and sandboxed scripting so agents can produce more current, efficient, and production-ready results. The post concludes that this solves major limitations of model-only AWS assistance without granting agents unrestricted credentials. ## Why AI Agents Struggle with AWS - Models may lack knowledge of recently launched services such as Amazon S3 Vectors, Aurora DSQL, and Bedrock AgentCore. - Agents often default to the AWS CLI instead of AWS CDK or CloudFormation. - Generated IAM policies are frequently broader than necessary. - The resulting infrastructure may work in demos but fail production standards. ## Core AWS MCP Server Tools - `call_aws` can execute more than 15,000 AWS API operations using the user’s existing IAM credentials. - `search_documentation` and `read_documentation` retrieve current AWS documentation and best practices at query time. - The compact tool set reduces model context usage and is intended to support newly launched APIs within days. ## General Availability Improvements - IAM context keys allow fine-grained access control through standard IAM policies without requiring a separate server permission. - Documentation retrieval no longer requires authentication. - Reduced token consumption improves complex, multi-step workflows. - The `run_script` tool executes short Python scripts in a server-side sandbox. - The sandbox inherits IAM permissions. - It has no network access or access to the user’s local filesystem and shell. - It can combine multiple API calls, filter results, and calculate outputs in one round trip. ## Skills and AWS Best Practices - Skills replace Agent SOPs with curated guidance for common AWS tasks. - AWS service teams contribute and maintain the Skills. - They help agents avoid mistakes, use validated patterns, reduce hallucinations, and consume fewer tokens. - Keeping the tool list small makes agent behavior more predictable. ## Enterprise Security and Observability - IAM policies and Service Control Policies can separate human permissions from agent permissions. - For example, a user may perform write operations while the MCP server is restricted to read-only access. - CloudWatch metrics under the `AWS-MCP` namespace distinguish agent activity from direct human calls. - AWS CloudTrail records all API calls for auditing and compliance. ## Demonstration with Claude Code - Without the MCP Server, Claude Opus 4.6 suggested several valid ways to store embeddings on S3 but missed Amazon S3 Vectors because the service launched after its training cutoff. - With the MCP Server, Claude Code searched current AWS documentation and correctly identified S3 Vectors. - Claude Code can connect through the open-source `mcp-proxy-for-aws`, which bridges local IAM credentials and MCP’s OAuth 2.1 requirement. - The server works with Claude Code, Kiro, Cursor, Codex, and other MCP-compatible clients. ## Availability and Cost - The service is available in US East (N. Virginia) and Europe (Frankfurt). - It can make API calls across AWS Regions. - There is no additional charge for the MCP Server; users pay for AWS resources and applicable data transfer. The AWS MCP Server is a practical foundation for giving agents current AWS knowledge and controlled operational access. Teams should pair it with narrowly scoped IAM policies, read-only defaults where possible, and CloudWatch or CloudTrail monitoring.

Read original(opens in new tab)
toss3 min readCurated summary

Easy-to-use Toss Front SDK

The post argues that an SDK’s stability depends not only on its internal implementation but also on how safely users can interact with it. Low-level APIs may expose every operation clearly, yet still allow human errors such as missing event handlers or cleanup. The recommended solution is an intent-driven Facade interface that simplifies common workflows, prevents misuse, and still provides low-level escape hatches for advanced cases. ## Designing an SDK That Is Easy to Use - Toss Place develops an external SDK for Toss Front payment terminals. - The SDK allows third-party developers to build plugin apps that integrate with Toss services and run on the terminal. - A simple-looking server API might require users to: - Open a server. - Register connection, message, and error handlers. - Remove handlers. - Close the server. - This approach exposes implicit responsibilities to SDK users: - A message callback might never be registered after a connection. - Handlers might not be removed before shutdown. - Improper cleanup can cause memory leaks and operational issues. - Therefore, third-party implementation mistakes can directly affect platform reliability. - A safer interface hides unnecessary internal steps: ```ts const server = await sdk.start({ onConnection, onMessage }); await server.stop(); ``` ## Facade as an Intent-Driven Interface - The Facade pattern is commonly described as wrapping a complex subsystem with a simpler interface. - In SDK design, its deeper purpose is to reorganize complexity around user intent rather than merely hide functionality. - Users should express goals such as: - “Start a server” - “Upload a file” - “Request a payment” - Internal concerns—including authentication, retries, state management, listener registration, and cleanup—should be handled by the SDK. - AWS CDK illustrates this distinction: - **L1 constructs** closely represent raw CloudFormation resources and provide fine-grained control. - **L2 constructs** provide intent-based APIs, such as creating a versioned S3 bucket with `versioned: true`, while handling the underlying configuration automatically. - The goal of a Facade is to reduce cognitive load and coupling, not simply to conceal every lower-level capability. ## Combining High-Level and Low-Level APIs - A well-designed SDK should provide both abstraction levels: - **High-level Facade:** Handles the roughly 80% of common use cases through complete workflows. - **Low-level APIs:** Serve as escape hatches for the roughly 20% of specialized cases requiring precise control. - In the example: - The Facade’s `start()` method opens the server, registers listeners, coordinates connections, and returns a unified server handle. - Low-level APIs separately expose operations such as `open`, `close`, `send`, `disconnect`, and event listeners. - This layered design improves immediate developer experience while preserving long-term compatibility and extensibility. ## Trade-offs and Escape Hatches - Higher-level abstractions inevitably reduce some flexibility. - Specialized requirements—such as keeping one connection while closing others—may not fit the Facade workflow. - As orchestration becomes more sophisticated, the SDK maintainers inherit additional implementation and maintenance costs. - Low-level escape hatches are therefore essential: users should be able to bypass the Facade when they need detailed control. ## Practical Recommendation Design SDK APIs around user intent and automate error-prone lifecycle management wherever possible. Offer a concise Facade for common workflows, but retain well-defined low-level interfaces so advanced users are not blocked by the abstraction.

Read original(opens in new tab)