Publicado el Deja un comentario

AWS announces pricing for VPC Encryption Controls

AWS is launching pricing for VPC Encryption Controls, a security and compliance feature that enables you to audit and enforce encryption-in-transit of all traffic flows within and across Virtual Private Clouds (VPCs) in a region. VPC Encryption controls can be enabled in two modes: Monitor mode detects presence of any unencrypted traffic within your VPCs, and Enforce Mode ensures all data-in-transit is encrypted and prevents the bring up of any resources that allow unencrypted traffic within your VPC. 

Starting March 1, 2026, VPC Encryption Controls will transition from a free preview to a paid feature. You will be charged a fixed hourly rate for every non-empty VPC (VPC that has network interfaces in them) that has Encryption Controls enabled in either monitor or enforce mode. There will be no charge for empty VPCs that have encryption controls enabled. When you enable encryption support on a Transit Gateway, standard VPC Encryption Controls charges apply to all VPCs attached to that Transit Gateway irrespective of their encryption controls mode (monitor, enforce or off) even if they are empty. 

To learn more about VPC Encryption Controls and view detailed regional pricing, visit the VPC Encryption Controls documentation and VPC pricing page.

 

​AWS is launching pricing for VPC Encryption Controls, a security and compliance feature that enables you to audit and enforce encryption-in-transit of all traffic flows within and across Virtual Private Clouds (VPCs) in a region. VPC Encryption controls can be enabled in two modes: Monitor mode detects presence of any unencrypted traffic within your VPCs, and Enforce Mode ensures all data-in-transit is encrypted and prevents the bring up of any resources that allow unencrypted traffic within your VPC.  Starting March 1, 2026, VPC Encryption Controls will transition from a free preview to a paid feature. You will be charged a fixed hourly rate for every non-empty VPC (VPC that has network interfaces in them) that has Encryption Controls enabled in either monitor or enforce mode. There will be no charge for empty VPCs that have encryption controls enabled. When you enable encryption support on a Transit Gateway, standard VPC Encryption Controls charges apply to all VPCs attached to that Transit Gateway irrespective of their encryption controls mode (monitor, enforce or off) even if they are empty.  To learn more about VPC Encryption Controls and view detailed regional pricing, visit the VPC Encryption Controls documentation and VPC pricing page.  

Publicado el Deja un comentario

Amazon Lightsail expands blueprint selection with a new WordPress blueprint

Amazon Lightsail now offers a new WordPress blueprint, making it easier than ever to launch and manage a WordPress website on the cloud. With just a few clicks, you can create a Lightsail virtual private server (VPS) preinstalled with WordPress, and follow a guided setup wizard to get your site fully configured and running in minutes. This new blueprint has Instance Metadata Service Version 2 (IMDSv2) enforced by default.

With Lightsail, you can easily get started on the cloud by choosing a blueprint and an instance bundle to build your web application. Lightsail instance bundles include instances preinstalled with your preferred operating system, storage, and monthly data transfer allowance, giving you everything you need to get up and running quickly. The new WordPress blueprint includes a step-by-step setup workflow that walks you through connecting a custom domain, configuring DNS, attaching a static IP address, and enabling HTTPS encryption using a free Let’s Encrypt SSL/TLS certificate — all from within the Lightsail console.

This new blueprint is now available in all AWS Regions where Lightsail is available. For more information on blueprints supported on Lightsail, see Lightsail documentation. For more information on pricing, or to get started with your free trial, click here.

 

​Amazon Lightsail now offers a new WordPress blueprint, making it easier than ever to launch and manage a WordPress website on the cloud. With just a few clicks, you can create a Lightsail virtual private server (VPS) preinstalled with WordPress, and follow a guided setup wizard to get your site fully configured and running in minutes. This new blueprint has Instance Metadata Service Version 2 (IMDSv2) enforced by default. With Lightsail, you can easily get started on the cloud by choosing a blueprint and an instance bundle to build your web application. Lightsail instance bundles include instances preinstalled with your preferred operating system, storage, and monthly data transfer allowance, giving you everything you need to get up and running quickly. The new WordPress blueprint includes a step-by-step setup workflow that walks you through connecting a custom domain, configuring DNS, attaching a static IP address, and enabling HTTPS encryption using a free Let’s Encrypt SSL/TLS certificate — all from within the Lightsail console. This new blueprint is now available in all AWS Regions where Lightsail is available. For more information on blueprints supported on Lightsail, see Lightsail documentation. For more information on pricing, or to get started with your free trial, click here.  

Publicado el Deja un comentario

EC2 Image Builder enhances lifecycle policies with wildcard support and simplified IAM

EC2 Image Builder, a service that helps you automate the creation, distribution, and management of customized Amazon Machine Images, now supports wildcard patterns in lifecycle policies and simplifies IAM role creation. You can now use wildcard patterns to manage images from multiple recipes within a single lifecycle policy, and create IAM roles with pre-populated default permissions directly from the console.

Previously, you had to create separate lifecycle policies for each new recipe or manually select individual recipes, making it difficult to scale as new recipes were added. Now with wildcard pattern support, you can specify patterns like my-recipe-1.x.x to automatically apply lifecycle policies to all matching recipes—including new recipes created in the future. Additionally, creating IAM roles for lifecycle management previously required manually configuring the required permissions. Now when creating a new role in the console, EC2 Image Builder automatically populates the required default permissions, reducing setup time and potential configuration errors. Together, these capabilities simplify onboarding and ongoing maintenance, enabling you to manage your image lifecycle at scale with less operational overhead.

Lifecycle Policies are available in all commercial AWS regions. To learn more, refer to the documentation.

 

​EC2 Image Builder, a service that helps you automate the creation, distribution, and management of customized Amazon Machine Images, now supports wildcard patterns in lifecycle policies and simplifies IAM role creation. You can now use wildcard patterns to manage images from multiple recipes within a single lifecycle policy, and create IAM roles with pre-populated default permissions directly from the console. Previously, you had to create separate lifecycle policies for each new recipe or manually select individual recipes, making it difficult to scale as new recipes were added. Now with wildcard pattern support, you can specify patterns like my-recipe-1.x.x to automatically apply lifecycle policies to all matching recipes—including new recipes created in the future. Additionally, creating IAM roles for lifecycle management previously required manually configuring the required permissions. Now when creating a new role in the console, EC2 Image Builder automatically populates the required default permissions, reducing setup time and potential configuration errors. Together, these capabilities simplify onboarding and ongoing maintenance, enabling you to manage your image lifecycle at scale with less operational overhead. Lifecycle Policies are available in all commercial AWS regions. To learn more, refer to the documentation.  

Publicado el Deja un comentario

ARC Region switch adds three new capabilities: post-recovery workflows, RDS orchestration and AWS provider support for Terraform

Amazon Application Recovery Controller (ARC) Region switch helps customers orchestrate the failover of their multi-Region applications to achieve a bounded recovery time in the event of a Regional impairment. It automates multi-Region disaster recovery, reducing engineering effort and eliminating operational overhead when recovering applications across multiple AWS accounts and Regions. Region switch now includes three new capabilities: post-recovery workflows, native RDS execution blocks, and AWS provider for Terraform support.

Post-recovery workflows. Disaster recovery doesn’t end when customers failover to a standby Region. After orchestrating a failover or failback, customers must prepare the other Region for the next recovery event. Today, this requires manual coordination of scaling, recreating read replicas, and validating configurations. Post-recovery workflows help customers automate these preparation steps. With this launch, post-recovery workflows support the custom action Lambda execution block, Amazon RDS create read replica execution block, ARC Region switch plan execution block, and the manual approval execution block. Customers can create read replicas, run custom logic via Lambda functions, add manual approval gates, and embed child plans for complex orchestration as part of post-recovery. Post-recovery workflows are available for active/passive deployments and can be triggered manually.

RDS execution blocks. Coordinating Amazon RDS database recovery during Regional failover requires manual steps to promote read replicas and recreate replication, introducing delays and errors. Region switch now natively supports two Amazon RDS execution blocks that automate RDS recovery orchestration. The RDS promote read replica execution block orchestrates promotion of a read replica to a standalone instance during failover. The RDS create read replica execution block orchestrates replica creation as part of post-recovery workflows.

AWS provider for Terraform support. Region switch is now supported by the AWS provider for Terraform, enabling customers to manage disaster recovery plans as Infrastructure-as-Code and integrate them into CI/CD pipelines alongside application deployments.

To learn more, about AWS provider support for Terraform, visit Terraform provider documentation. To learn about post-recovery workflows in action, read the post-recovery workflow tutorial. To get started with Region switch, read our launch blog or documentation.

 

​Amazon Application Recovery Controller (ARC) Region switch helps customers orchestrate the failover of their multi-Region applications to achieve a bounded recovery time in the event of a Regional impairment. It automates multi-Region disaster recovery, reducing engineering effort and eliminating operational overhead when recovering applications across multiple AWS accounts and Regions. Region switch now includes three new capabilities: post-recovery workflows, native RDS execution blocks, and AWS provider for Terraform support. Post-recovery workflows. Disaster recovery doesn’t end when customers failover to a standby Region. After orchestrating a failover or failback, customers must prepare the other Region for the next recovery event. Today, this requires manual coordination of scaling, recreating read replicas, and validating configurations. Post-recovery workflows help customers automate these preparation steps. With this launch, post-recovery workflows support the custom action Lambda execution block, Amazon RDS create read replica execution block, ARC Region switch plan execution block, and the manual approval execution block. Customers can create read replicas, run custom logic via Lambda functions, add manual approval gates, and embed child plans for complex orchestration as part of post-recovery. Post-recovery workflows are available for active/passive deployments and can be triggered manually. RDS execution blocks. Coordinating Amazon RDS database recovery during Regional failover requires manual steps to promote read replicas and recreate replication, introducing delays and errors. Region switch now natively supports two Amazon RDS execution blocks that automate RDS recovery orchestration. The RDS promote read replica execution block orchestrates promotion of a read replica to a standalone instance during failover. The RDS create read replica execution block orchestrates replica creation as part of post-recovery workflows. AWS provider for Terraform support. Region switch is now supported by the AWS provider for Terraform, enabling customers to manage disaster recovery plans as Infrastructure-as-Code and integrate them into CI/CD pipelines alongside application deployments.
To learn more, about AWS provider support for Terraform, visit Terraform provider documentation. To learn about post-recovery workflows in action, read the post-recovery workflow tutorial. To get started with Region switch, read our launch blog or documentation.  

Publicado el Deja un comentario

Amazon Bedrock batch inference now supports the Converse API format

Amazon Bedrock batch inference now supports the Converse API as a model invocation type, enabling you to use a consistent, model-agnostic input format for your batch workloads.

Previously, batch inference required model-specific request formats using the InvokeModel API. Now, when creating a batch inference job, you can select Converse as the model invocation type and structure your input data using the standard Converse API request format. Output for Converse batch jobs follows the Converse API response format. With this feature, you can use the same unified request format for both real-time and batch inference, simplifying prompt management and reducing the effort needed to switch between models. You can configure the Converse model invocation type through both the Amazon Bedrock console and the API.

This capability is available in all AWS Regions that support Amazon Bedrock batch inference. To get started, see Create a batch inference job and Format and upload your batch inference data in the Amazon Bedrock User Guide.

 

​Amazon Bedrock batch inference now supports the Converse API as a model invocation type, enabling you to use a consistent, model-agnostic input format for your batch workloads. Previously, batch inference required model-specific request formats using the InvokeModel API. Now, when creating a batch inference job, you can select Converse as the model invocation type and structure your input data using the standard Converse API request format. Output for Converse batch jobs follows the Converse API response format. With this feature, you can use the same unified request format for both real-time and batch inference, simplifying prompt management and reducing the effort needed to switch between models. You can configure the Converse model invocation type through both the Amazon Bedrock console and the API. This capability is available in all AWS Regions that support Amazon Bedrock batch inference. To get started, see Create a batch inference job and Format and upload your batch inference data in the Amazon Bedrock User Guide.  

Publicado el Deja un comentario

AWS Network Firewall now supports firewall state change notifications through Amazon EventBridge

AWS Network Firewall now integrates with Amazon EventBridge to provide real-time notifications for firewall state changes and configuration updates. This new capability enables you to monitor critical firewall operations including firewall configuration updates and endpoint status modifications across your network security infrastructure. You gain immediate visibility into changes affecting AWS Managed Rules, Partner Managed Rules, and firewall configurations.

With EventBridge integration, you gain enhanced visibility into your firewall operations in real-time. You can build automated workflows to send notifications through Amazon SNS, create tickets in your IT service management (ITSM) systems, or integrate with third-party security information and event management (SIEM) solutions. This integration helps you maintain better operational awareness of your network security infrastructure and respond quickly to configuration changes or potential issues.

AWS Network Firewall state change notifications through Amazon EventBridge are available in all AWS Regions where AWS Network Firewall and Amazon EventBridge is currently available.

To learn more about AWS Network Firewall EventBridge integration, visit the AWS Network Firewall documentation. For information about Amazon EventBridge, see the Amazon EventBridge documentation.

 

​AWS Network Firewall now integrates with Amazon EventBridge to provide real-time notifications for firewall state changes and configuration updates. This new capability enables you to monitor critical firewall operations including firewall configuration updates and endpoint status modifications across your network security infrastructure. You gain immediate visibility into changes affecting AWS Managed Rules, Partner Managed Rules, and firewall configurations. With EventBridge integration, you gain enhanced visibility into your firewall operations in real-time. You can build automated workflows to send notifications through Amazon SNS, create tickets in your IT service management (ITSM) systems, or integrate with third-party security information and event management (SIEM) solutions. This integration helps you maintain better operational awareness of your network security infrastructure and respond quickly to configuration changes or potential issues. AWS Network Firewall state change notifications through Amazon EventBridge are available in all AWS Regions where AWS Network Firewall and Amazon EventBridge is currently available. To learn more about AWS Network Firewall EventBridge integration, visit the AWS Network Firewall documentation. For information about Amazon EventBridge, see the Amazon EventBridge documentation.  

Publicado el Deja un comentario

AWS Resource Access Manager now supports maintaining shares when accounts change organizations

AWS Resource Access Manager (RAM) now supports a resource share configuration that allows you to maintain resource sharing continuity when accounts move between AWS Organizations. With the new RetainSharingOnAccountLeaveOrganization parameter and corresponding ram:RetainSharingOnAccountLeaveOrganization condition key, security administrators can configure resource shares to retain access when accounts leave the organization and enforce consistent policies across their organization using Service Control Policies (SCPs).

This capability helps organizations undergoing mergers, acquisitions, or restructuring maintain access to shared resources like Route53 Resolver Rules, Transit Gateways, and IPAM pools without disruption. Security teams can use SCPs to enforce the RetainSharingOnAccountLeaveOrganization configuration organization-wide. When enabled, RAM treats organization accounts as external accounts, requiring explicit invitation acceptance and preserving resource access during account transitions between organizations.

This feature is available in all AWS commercial Regions at no additional cost. To learn more about resource share configurations, see the AWS RAM documentation or visit the AWS RAM product page.

 

​AWS Resource Access Manager (RAM) now supports a resource share configuration that allows you to maintain resource sharing continuity when accounts move between AWS Organizations. With the new RetainSharingOnAccountLeaveOrganization parameter and corresponding ram:RetainSharingOnAccountLeaveOrganization condition key, security administrators can configure resource shares to retain access when accounts leave the organization and enforce consistent policies across their organization using Service Control Policies (SCPs). This capability helps organizations undergoing mergers, acquisitions, or restructuring maintain access to shared resources like Route53 Resolver Rules, Transit Gateways, and IPAM pools without disruption. Security teams can use SCPs to enforce the RetainSharingOnAccountLeaveOrganization configuration organization-wide. When enabled, RAM treats organization accounts as external accounts, requiring explicit invitation acceptance and preserving resource access during account transitions between organizations. This feature is available in all AWS commercial Regions at no additional cost. To learn more about resource share configurations, see the AWS RAM documentation or visit the AWS RAM product page.  

Publicado el Deja un comentario

Amazon CloudWatch logs centralization rules now support customizable destination log group structure

Amazon CloudWatch now supports customizing destination log group names when creating CloudWatch log centralization rules. Organizations managing logs across multiple accounts can now use attributes to organize centralized logs into meaningful hierarchies — by account ID, region, organizational unit, or other AWS Organizations metadata — that match how their organization operates and what their compliance requirements demand.

You can define a destination log group name structure using attributes that CloudWatch Logs automatically replaces with actual values when logs are copied. For example, using the pattern ${source.accountId}/${source.region}/${source.logGroup} creates destination log groups like 123456789012/us-east-1/cloudtrail/managementevent, making it easy to identify which account and region logs originated from. You can use attributes, including source account ID, region, log group name, organization ID, organizational unit ID, root ID, and the full organizational path.

Customizable destination log group names are available in all centralization rules supported regions.

Customers can use centralization rules to centralize one copy of logs for free (ingestion). Additional copies are charged at $0.05/GB of logs centralized (the backup region feature is considered an additional copy). Storage charges apply. To learn more, visit the CloudWatch Logs Centralization documentation.

 

​Amazon CloudWatch now supports customizing destination log group names when creating CloudWatch log centralization rules. Organizations managing logs across multiple accounts can now use attributes to organize centralized logs into meaningful hierarchies — by account ID, region, organizational unit, or other AWS Organizations metadata — that match how their organization operates and what their compliance requirements demand.
You can define a destination log group name structure using attributes that CloudWatch Logs automatically replaces with actual values when logs are copied. For example, using the pattern ${source.accountId}/${source.region}/${source.logGroup} creates destination log groups like 123456789012/us-east-1/cloudtrail/managementevent, making it easy to identify which account and region logs originated from. You can use attributes, including source account ID, region, log group name, organization ID, organizational unit ID, root ID, and the full organizational path.
Customizable destination log group names are available in all centralization rules supported regions.
Customers can use centralization rules to centralize one copy of logs for free (ingestion). Additional copies are charged at $0.05/GB of logs centralized (the backup region feature is considered an additional copy). Storage charges apply. To learn more, visit the CloudWatch Logs Centralization documentation.  

Publicado el Deja un comentario

Amazon RDS for PostgreSQL supports minor versions 18.3, 17.9, 16.13, 15.17, and 14.22

Amazon Relational Database Service (RDS) for PostgreSQL now supports the latest minor versions 18.3, 17.9, 16.13, 15.17, and 14.22. These versions address the regression from the February 12, 2026 PostgreSQL community release. We recommend that you upgrade to the latest minor versions to fix known security vulnerabilities in prior versions of PostgreSQL, and to benefit from the bug fixes added by the PostgreSQL community.

You can upgrade your databases during scheduled maintenance windows using automatic minor version upgrades. To simplify operations at scale, enable automatic minor version upgrades and use the AWS Organizations Upgrade Rollout Policy to orchestrate thousands of upgrades in phases, first to development environments before upgrading production systems. You can also use Amazon RDS Blue/Green deployments with physical replication to minimize downtime for minor version upgrades.

Amazon RDS for PostgreSQL makes it simple to set up, operate, and scale PostgreSQL deployments in the cloud. See Amazon RDS for PostgreSQL Pricing for pricing details and regional availability. Create or update a fully managed Amazon RDS database in the Amazon RDS Management Console or by using the AWS Command Line Interface (CLI).

 

​Amazon Relational Database Service (RDS) for PostgreSQL now supports the latest minor versions 18.3, 17.9, 16.13, 15.17, and 14.22. These versions address the regression from the February 12, 2026 PostgreSQL community release. We recommend that you upgrade to the latest minor versions to fix known security vulnerabilities in prior versions of PostgreSQL, and to benefit from the bug fixes added by the PostgreSQL community. You can upgrade your databases during scheduled maintenance windows using automatic minor version upgrades. To simplify operations at scale, enable automatic minor version upgrades and use the AWS Organizations Upgrade Rollout Policy to orchestrate thousands of upgrades in phases, first to development environments before upgrading production systems. You can also use Amazon RDS Blue/Green deployments with physical replication to minimize downtime for minor version upgrades. Amazon RDS for PostgreSQL makes it simple to set up, operate, and scale PostgreSQL deployments in the cloud. See Amazon RDS for PostgreSQL Pricing for pricing details and regional availability. Create or update a fully managed Amazon RDS database in the Amazon RDS Management Console or by using the AWS Command Line Interface (CLI).  

Publicado el Deja un comentario

El Prompt: Usen la IA para motivarse

El Prompt: Usen la IA para motivarse

Collage de figuras geométricas coloridas con un papel rasgado donde se lee: "The prompt"

A veces, todos necesitamos un pequeño recordatorio de lo increíbles que somos. Por suerte, la IA está aquí para ayudarlos. Pueden usar Microsoft 365 Copilot para encontrar los elogios que se esconden en su bandeja de entrada o en los chats de Teams. ¡Así que adelante, anímense! Se lo han ganado.

Entren a Microsoft 365 Copilot y dejen esto en el chat:

Usando los correos en mi carpeta de Outlook [Nombre de la carpeta], resume el reconocimiento que he recibido. Para cada correo, proporciona un breve resumen que incluya el proyecto o tema, el reconocimiento otorgado y quién lo proporcionó. Luego, compila un párrafo pulido destacando los temas clave de mis contribuciones e impacto.

Pueden cambiar un poco el prompt si quieren sacar a la luz las cosas brillantes que la gente ha dicho sobre ustedes en Teams.

El Prompt es una sección habitual de Signal que les ofrece formas específicas y súper rápidas de usar la IA para resolver problemas, potenciar su creatividad y hacer más en el trabajo.

Aprendan más sobre Microsoft 365 Copilot.

Texto publicado en Signal.

The post El Prompt: Usen la IA para motivarse appeared first on Source LATAM.

 

​The post El Prompt: Usen la IA para motivarse appeared first on Source LATAM.