Cloud Computing Köln

AWS announces general availability of Smithy-Java client framework

AWS today announced the general availability of Smithy-Java, an open-source Java framework for generating type-safe clients and standalone classes from Smithy models. Smithy-Java addresses one of the most consistently requested capabilities from enterprise Smithy users: production-grade Java SDK generation. The framework allows you to generate clients from models and async patterns that increase cognitive load and maintenance burden for developers building modern Java applications.
Built on Java 21’s virtual threads, Smithy-Java provides a blocking-style API that is both simpler to use and competitive in performance with complex async alternatives. Key benefits include auto-generated type-safe clients from Smithy, protocol flexibility with runtime protocol swapping for gradual migration paths. The GA release includes the Java client code generator, support for AWS SigV4 and all major AWS protocols (AWS JSON, REST-JSON, REST-XML, AWS Query, and Smithy RPCv2-CBOR), standalone type code generation for sharing types across multiple services or data modeling, and a dynamic client that can call Smithy services without a codegen step.
The framework pioneers two architectural innovations: schema-driven serialization that reduces SDK size while improving performance, and binary decision diagrams (BDD) for endpoint rules resolution delivering significant latency improvements. Internal Amazon teams have already built complete services in weeks rather than months using Smithy-Java, with service teams depending on it internally. The framework is ideal for organizations invested in the Smithy ecosystem, teams requiring protocol-agnostic development, and developers building new services with generated server stubs.
To learn more, visit our blog post and follow the Smithy Java Quickstart guide.
Quelle: aws.amazon.com

Amazon WorkSpaces Personal now supports unique DNS names for PrivateLink

Amazon WorkSpaces Personal now provides unique, publicly resolvable Domain Name System (DNS) names for each AWS PrivateLink Virtual Private Cloud (VPC) endpoint, enabling enterprise customers to deploy WorkSpaces across multiple AWS VPCs and accounts without DNS resolution conflicts. Each interface VPC endpoint now receives a globally unique AWS-managed DNS name in addition to the previous generic DNS name that was shared across all endpoints. This enhancement enables customers to route traffic appropriately in multi-account environments with centralized DNS infrastructure. Customers can now deploy WorkSpaces Personal directories across different VPCs and AWS accounts while maintaining proper security isolation, eliminating the DNS name collision that previously prevented customers from using separate interface VPC endpoints across accounts. The publicly resolvable DNS names simplify configuration while maintaining security, as they resolve to private IP addresses accessible only from within the respective VPC. The unique DNS names are automatically managed by AWS throughout their lifecycle, requiring no additional Route 53 configuration or custom DNS management. This feature is available in all AWS regions where PrivateLink is available in Amazon WorkSpaces Personal. To learn more, see Amazon WorkSpaces PrivateLink documentation. For configuration details, refer to the WorkSpaces Administration Guide. Existing customers will automatically benefit from this enhancement, as the system maintains backward compatibility with previous DNS configurations.
Quelle: aws.amazon.com

Amazon Verified Permissions now supports policy store aliases and named policies and policy templates

Today, AWS announces support for policy store aliases and named policies and policy templates in Amazon Verified Permissions, simplifying multi-tenant deployments and day-to-day policy management. Amazon Verified Permissions is a fine-grained authorization service that helps you manage and enforce permissions across your applications using Cedar policies. These new capabilities eliminate the need to maintain separate mapping tables for associating tenant identifiers with policy store IDs or tracking individual policy and template IDs.
With policy store aliases, multi-tenant application developers can assign a human-readable alias based on a tenant identifier and use it in any API call, removing the need for a lookup table. Similarly, named policies and policy templates let you reference policies by meaningful names instead of system-generated IDs, making it easier to manage authorization logic as your application grows.
Amazon Verified Permissions policy store aliases and named policies and templates are available in all AWS Regions where Amazon Verified Permissions is available. For a full list of supported Regions, see Amazon Verified Permissions endpoints and quotas.
To get started, see Policy store aliases and Creating static policies in the Amazon Verified Permissions User Guide, or visit the Amazon Verified Permissions API Reference.
Quelle: aws.amazon.com