[$] Verifying the BPF verifier’s path-exploration logic

Post Syndicated from daroc original https://lwn.net/Articles/1021825/

Srinivas Narayana led a remote session about extending

Agni to prove the correctness of
the BPF verifier’s handling of different execution paths as part of the Linux Storage,
Filesystem, Memory Management, and BPF Summit. The problem of ensuring the
correctness of path exploration
is much more difficult than the problem of
ensuring the correctness of arithmetic operations
(which was

the subject of the previous session), however. Narayana’s plan to
tackle the problem makes use of a mixture of specialized techniques — and may
need some assistance from the BPF developers to make it feasible at all.

Control instance placement using Asset Level Capacity Management for AWS Outposts

Post Syndicated from Brianna Rosentrater original https://aws.amazon.com/blogs/compute/control-instance-placement-using-asset-level-capacity-management-for-aws-outposts/

AWS Outposts supports self-service capacity management at the entire Outpost level, or at the individual asset level, making it easy for you to view and manage compute capacity on your Outposts. This feature supports both Outposts rack (such as the recently announced second-generation Outposts rack) and Outposts server. A default capacity configuration for each new Outpost is determined during the ordering process. This default configuration can subsequently be modified to create a range of Amazon Elastic Compute Cloud (Amazon EC2) instance sizes and quantities to meet your changing business needs. For more information on performing Outposts level multi-asset reconfigurations, go to Dynamically reconfigure your AWS Outposts capacity using Capacity Tasks.

The release of Asset Level Capacity Management allows you to control the configuration of specific assets within your Outpost, which can be useful when planning strategies for EC2 Auto Scaling groups and host-level high availability. An Outpost asset can be a single server within an Outposts rack, or an Outposts server. This post focuses on how to use Asset Level Capacity Management to perform single-host reconfigurations, and how this can be used with Amazon EC2 placement groups to control instance placement on your Outpost.

Overview

When you place an Outposts order, you determine the capacity configuration of each Outpost based on the anticipated workload requirements. You can scale your Outposts up or out as needed during your commitment term. For further details on Outpost capacity planning including best practices, refer to the Capacity Planning – AWS Outposts High Availability Design and Architecture whitepaper. We recommend planning spare capacity for N+M host availability per instance family when making modifications to your Outpost capacity configuration for workloads that need to be highly available. To calculate, take the number of assets (N) you need to run all your workloads, and then add (M) additional assets to meet your requirements for server availability during failure and maintenance events.

You also need to plan for instance level high availability when deciding to reconfigure particular assets. For example, say you have two C5 assets, and each one is configured homogeneously to provide C5.2xlarge instances. If you have an Auto Scaling group that specifies C5.2xlarge in its launch template, and you perform an asset level reconfiguration of one of your C5 assets so that it only offers C5.4xlarge instances, then your Auto Scaling group can only launch instances on the one C5 host configured to provide C5.2xlarge instances. If that host fails, then the Auto Scaling group is unable to launch new C5.2xlarge instances on the other host unless the Auto Scaling group launch template is modified. Understanding failure scenario behavior and how much capacity you want to reserve for high availability is key to capacity management and disaster recovery planning. For highly available workloads, we recommend spreading your instances across as many assets as possible.

Understanding EC2 placement groups on AWS Outposts

Outposts rack supports EC2 placement groups, and two placement group options are available only on Outposts: rack level spread, and host level spread. This allows you to spread out instances across underlying hardware on an Outpost at your site. To use a rack level spread placement group, you must have two or more physical Outpost racks. Each spread strategy can be used to create resilient Outposts architectures that can withstand a rack or host failure depending on the respective strategy used.

Rack level spread

Figure 1: Outposts rack showing a rack level spread EC2 placement group

Figure 1: Outposts rack showing a rack level spread EC2 placement group

Using a multi-rack Outpost, you can spread your EC2 instances across multiple racks with a rack level spread EC2 placement group. When used with Auto Scaling groups, this allows you to withstand an individual rack or multi-asset failure. When your Auto Scaling group detects you’ve lost instances on one of your racks, it automatically relaunches the instances using the assets on your other racks if you have available capacity. To use this strategy to increase your workload resiliency, each rack would need to have assets that can support the instance type (C5 is used in the preceding figure) and size used in your Auto Scaling group launch template. The expanded functionality that asset level capacity management brings to capacity tasks allows you to configure your Outpost so that each rack has at least one asset that can support the instances used in your Auto Scaling groups. Configure your assets on each rack to meet your resiliency goals for host failure tolerance as well. This configuration can be done in an on-demand, self-service fashion to meet the needs of your evolving workloads if instance requirements change over time.

Host level spread

Figure 2: Outposts rack showing a host level spread EC2 placement group

Although rack level spread EC2 placement groups need a multi-rack Outpost, host level spread EC2 placement groups can be used within a single rack Outpost to provide resiliency for your workloads at the asset level. When used with Auto Scaling groups, this allows you to withstand an individual asset or multi-asset failure depending on your Outpost configuration. When your Auto Scaling group detects you’ve lost instances on one of your assets due to a hardware failure, it automatically relaunches the instances using your other assets on your Outpost if you have available capacity. To use this strategy to increase your workload resiliency, you would need to have at least two assets within your Outposts rack that can support the instance type (R5 and M5 are used in the preceding figure) and size used in your Auto Scaling group launch template. Outposts also supports using attribute-based instance type selection if multiple instance types meet your workload needs based on some minimum resource requirements. With the expanded functionality that asset level capacity management brings to capacity tasks, you can configure your Outposts rack so that each asset type can support the instance size used in your Auto Scaling groups. This configuration can be done in an on-demand, self-service fashion to meet the needs of your evolving workloads if instance requirements change over time.

Using asset level capacity tasks

Asset Level Capacity Management allows you to target a specific Outpost asset to change its capacity configuration directly, allowing granular control over instance capacity pool configurations. Outpost assets are referred to by a unique ten-digit Asset ID. The first step in this process is identifying a suitable asset on which to perform the capacity task. To do this, you can use the rack view within the Outposts console page to view each asset, its current capacity configuration, and its current usage. Choosing an asset with fewer running instances may increase the chances of the capacity task being successful without needing instances to be stopped.

In the following example, the rack view has been filtered by the R5 family resulting in the two R5 assets being displayed. The Show instance details option has also been chosen to show the instance IDs of the running instances on our Outposts rack.

Figure 3: Rack view of the Outposts console

When you have identified the asset to target for the capacity task, you can either choose the Modify option in the top right of the asset itself or go to Capacity Tasks from the console menu and choose the asset ID directly from the dropdown menu.

Figure 4: Capacity tasks console experience

From here, you have the option to use the capacity configuration builder to interactively modify your Outposts capacity layout, or you can upload a capacity configuration plan JSON document with the necessary configuration. When building the capacity task, you have two options to choose from when handling instances that are blocking the task from executing. The default option is set to fail the capacity task if this occurs. However, this can be set to wait for the instances to be stopped so that the task can continue. If this option is chosen, then the asset is placed into an isolated state until either the capacity task completes or is cancelled, thus preventing any further instances launches on the impacted asset.

If there are instances on the asset that can’t be stopped to complete the capacity task, then they can be chosen from the Instances to keep as-is section. Only the instances running on the impacted asset are listed. If a capacity task can’t be completed while leaving the chosen instances running, the capacity task fails.

In the following example, the capacity configuration requested for the asset results in the removal of one r5.4xlarge and two r5.2xlarge instances, which creates sufficient space for the creation of 12 r5.large instances. This asset also has three instances running on it which have all been chosen to keep as-is during the execution of the task.

Figure 5: Capacity task example showing r5 asset level capacity management

You can also execute capacity tasks programmatically If you prefer through CLI or API calls. For example, using the start-capacity-task CLI to submit the same configuration would look as follows:

aws outposts start-capacity-task \
--outpost-id op-07f6f537e0607d3f1 \
--asset-id 1702928095\
--instances-to-exclude '{
    "Instances": ["i- 03f53189ffedcc72c", "i-044383b9051299b50", "i-0dfd88574237a68a4"],
    "AccountIds": ["450360193046", "450360193046", "450360193046"],
    "Services": ["EC2", "EC2", "EC2"]
}' \
--task-action-on-blocking-instances FAIL_TASK \
--instance-pools '[
    {
        "InstanceType": "r5.large",
        "Count": 12
    },
    {
        "InstanceType": "r5.xlarge",
        "Count": 6
    },
    {
        "InstanceType": "r5.2xlarge",
        "Count": 4
    },
    {
        "InstanceType": "r5.4xlarge",
        "Count": 1
    }
]'

After defining the capacity task, you are presented with an overview of the requested changes before submitting the task for execution. When it’s submitted, the task first enters a Requested status while the configuration is evaluated, before either being moved to In Progress if the task is valid or Failed if it’s invalid or blocked by running instances.

When the capacity task has successfully completed and the capacity pools for the asset are updated, you can validate this by returning to the rack view within the Outpost console, or by using the CLI/API. The following is an example using the list-assets CLI command:

aws outposts list-assets --outpost-identifier op-07f6f537e0607d3f1 --query "Assets[?AssetId=='1702928095']"

[
    {
        "AssetId": " 1702928095",
        "RackId": "1702928115",
        "AssetType": "COMPUTE",
        "ComputeAttributes": {
            "State": "ACTIVE",
            "InstanceFamilies": [
                "R5"
            ],
            "InstanceTypeCapacities": [
                {
                    "InstanceType": "r5.2xlarge",
                    "Count": 4
                },
                {
                    "InstanceType": "r5.4xlarge",
                    "Count": 1
                },
                {
                    "InstanceType": "r5.xlarge",
                    "Count": 6
                },
                {
                    "InstanceType": "r5.large",
                    "Count": 12
                }
            ],
            "MaxVcpus": 96
        },
        "AssetLocation": {
            "RackElevation": 27.0
        }
    }
]

Only a single capacity task for an asset can be executing at any given time. If you attempt to create a second capacity task for the same asset while the original is still in a Requesting or In Progress status, then the submission of the task fails. However, you can submit multiple capacity tasks for unique assets within the same Outpost. For example, using the CLI commands, you could execute a single script to change the capacity configuration of all assets within an Outpost through individual asset level capacity tasks.

Considerations

  • Make sure that if you’re specifying instance type in your launch templates, then this instance type is available on multiple assets if your workload needs to be resilient against host failures.
  • Understand which failure scenarios could exist within your environment, and plan for how each one should be handled. Failure planning is essential for maintaining workload uptime in production environments.
  • Capacity tasks can only be executed from the AWS account that owns the Outpost. If Outpost resources are shared to workload accounts through AWS Resource Access Manager (AWS RAM), then these accounts can’t submit capacity tasks.
  • You can manipulate your capacity configuration to control instance placement at launch. If only certain assets support the instance size and type you want to deploy, then your instance must be launched on one of those assets.
  • If executing capacity tasks through CLI commands, make sure that your CLI has been updated to the latest version. We have updated our CLI with this feature release to include commands for capacity tasks, and they fail if running on outdated versions.

Conclusion

This post demonstrates how to use Asset Level Capacity Management with your AWS Outposts, and reviews considerations for maintaining a highly available capacity configuration. For more information on how to manage and monitor your capacity configuration on Outposts, see the Capacity management for AWS Outposts user guide and the Capacity planning section of the Outposts High Availability Design and Architecture Considerations whitepaper. Reach out to your AWS account team, or fill out this form to learn more about Outposts and self-service capacity management.

Amazon Aurora DSQL is now generally available

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/amazon-aurora-dsql-is-now-generally-available/

Today, we’re announcing the general availability of Amazon Aurora DSQL, the fastest serverless distributed SQL database with virtually unlimited scale, the highest availability, and zero infrastructure management for always available applications. You can remove the operational burden of patching, upgrades, and maintenance downtime and count on an easy-to-use developer experience to create a new database in a few quick steps.

When we introduced the preview of Aurora DSQL at AWS re:Invent 2024, our customers were excited by this innovative solution to simplify complex relational database challenges. In his keynote, Dr. Werner Vogels, CTO of Amazon.com, talked about managing complexity upfront in the design of Aurora DSQL. Unlike most traditional databases, Aurora DSQL is disaggregated into multiple independent components such as a query processor, adjudicator, journal, and crossbar.

These components have high cohesion, communicate through well-specified APIs, and scale independently based on your workloads. This architecture enables multi-Region strong consistency with low latency and globally synchronized time. To learn more about how Aurora DSQL works behind the scenes, watch Dr. Werner Vogels’ keynote and read about an Aurora DSQL story.

The architecture of Amazon Aurora DSQL
Your application can use the fastest distributed SQL reads and writes and scale to meet any workload demand without any database sharding or instance upgrades. With Aurora DSQL, its active-active distributed architecture is designed for 99.99 percent availability in a single Region and 99.999 percent availability across multiple Regions. This means your applications can continue to read and write with strong consistency, even in the rare case an application is unable to connect to a Region cluster endpoint.

In a single-Region configuration, Aurora DSQL commits all write transactions to a distributed transaction log and synchronously replicates all committed log data to user storage replicas in three Availability Zones. Cluster storage replicas are distributed across a storage fleet and automatically scale to ensure optimal read performance.

Multi-Region clusters provide the same resilience and connectivity as single-Region clusters while improving availability through two Regional endpoints, one for each peered cluster Region. Both endpoints of a peered cluster present a single logical database and support concurrent read and write operations with strong data consistency. A third Region acts as a log-only witness which means there is is no cluster resource or endpoint. This means you can balance applications and connections for geographic locations, performance, or resiliency purposes, making sure readers consistently see the same data.

Aurora DSQL is an ideal choice to support applications using microservices and event-driven architectures, and you can design highly scalable solutions for industries such as banking, ecommerce, travel, and retail. It’s also ideal for multi-tenant software as a service (SaaS) applications and data-driven services like payment processing, gaming platforms, and social media applications that require multi-Region scalability and resilience.

Getting started with Amazon Aurora DSQL
Aurora DSQL provides a easy-to-use experience, starting with a simple console experience. You can use familiar SQL clients to leverage existing skillsets, and integration with other AWS services to improve managing databases.

To create an Aurora DSQL cluster, go to the Aurora DSQL console and choose Create cluster. You can choose either Single-Region or Multi-Region configuration options to help you establish the right database infrastructure for your needs.

1. Create a single-Region cluster

To create a single-Region cluster, you only choose Create cluster. That’s all.

In a few minutes, you’ll see your Aurora DSQL cluster created. To connect your cluster, you can use your favorite SQL client such as PostgreSQL interactive terminal,  DBeaver, JetBrains DataGrip, or you can take various programmable approaches with a database endpoint and authentication token as a password. You can integrate with AWS Secrets Manager for automated token generation and rotation to secure and simplify managing credentials across your infrastructure.

To get the authentication token, choose Connect and Get Token in your cluster detail page. Copy the endpoint from Endpoint (Host) and the generated authentication token after Connect as admin is chosen in the Authentication token (Password) section.

Then, choose Open in CloudShell, and with a few clicks, you can seamlessly connect to your cluster.

After you connect the Aurora DSQL cluster, test your cluster by running sample SQL statements. You can also query SQL statements for your applications using your favorite programming languages: Python, Java, JavaScript, C++, Ruby, .NET, Rust, and Golang. You can build sample applications using a Django, Ruby on Rails, and AWS Lambda application to interact with Amazon Aurora DSQL.

2. Create a multi-Region cluster

To create a multi-Region cluster, you need to add the other cluster’s Amazon Resource Name (ARN) to peer the clusters.

To create the first cluster, choose Multi-Region in the console. You will also be required to choose the Witness Region, which receives data written to any peered Region but doesn’t have an endpoint. Choose Create cluster. If you already have a remote Region cluster, you can optionally enter its ARN.

Next, add an existing remote cluster or create your second cluster in another Region by choosing Create cluster.

Now, you can create the second cluster with your peer cluster ARN as the first cluster.

When the second cluster is created, you must peer the cluster in us-east-1 in order to complete the multi-Region creation.

Go to the first cluster page and choose Peer to confirm cluster peering for both clusters.

Now, your multi-Region cluster is created successfully. You can see details about the peers that are in other Regions in the Peers tab.

To get hands-on experience with Aurora DSQL, you can use this step-by-step workshop. It walks through the architecture, key considerations, and best practices as you build a sample retail rewards point application with active-active resiliency.

You can use the AWS SDKs, AWS Comand Line Interface (AWS CLI), and Aurora DSQL APIs to create and manage Aurora DSQL programmatically. To learn more, visit Setting up Aurora DSQL clusters in the Amazon Aurora DSQL User Guide.

What did we add after the preview?
We used your feedback and suggestions during the preview period to add new capabilities. We’ve highlighted a few of the new features and capabilities:

  • Console experience –We improved your cluster management experience to create and peer multi-Region clusters as well as easily connect using AWS CloudShell.
  • PostgreSQL features – We added support for views, unique secondary indexes for tables with existing data and launched Auto-Analyze which removes the need to manually maintain accurate table statistics. Learn about Aurora DSQL PostgreSQL-compatible features.
  • Integration with AWS services –We integrated various AWS services such as AWS Backup for a full snapshot backup and Aurora DSQL cluster restore, AWS PrivateLink for private network connectivity, AWS CloudFormation for managing Aurora DSQL resources, and AWS CloudTrail for logging Aurora DSQL operations.

Aurora DSQL now provides a Model Context Protocol (MCP) server to improve developer productivity by making it easy for your generative AI models and database to interact through natural language. For example, install Amazon Q Developer CLI and configure Aurora DSQL MCP server. Amazon Q Developer CLI now has access to an Aurora DSQL cluster. You can easily explore the schema of your database, understand the structure of the tables, and even execute complex SQL queries, all without having to write any additional integration code.

Now available
Amazon Aurora DSQL is available today in the AWS US East (N. Virginia), US East (Ohio), US West (Oregon) Regions for single- and multi-Region clusters (two peers and one witness Region), Asia Pacific (Osaka) and Asia Pacific (Tokyo) for single-Region clusters, and Europe (Ireland), Europe (London), and Europe (Paris) for single-Region clusters.

You’re billed on a monthly basis using a single normalized billing unit called Distributed Processing Unit (DPU) for all request-based activity such as read/write. Storage is based on the total size of your database and measured in GB-months. You are only charged for one logical copy of your data per single-Region cluster or multi-Region peered cluster. As a part of the AWS Free Tier, your first 100,000 DPUs and 1 GB-month of storage each month is free. To learn more, visit Amazon Aurora DSQL Pricing.

Give Aurora DSQL a try for free in the Aurora DSQL console. For more information, visit the Aurora DSQL User Guide and send feedback to AWS re:Post for Aurora DSQL or through your usual AWS support contacts.

— Channy

Transforming Maya’s API management with Amazon API Gateway

Post Syndicated from Arthi Jaganathan original https://aws.amazon.com/blogs/architecture/transforming-mayas-api-management-with-amazon-api-gateway/

In this post, you will learn how Amazon Web Services (AWS) customer, Maya, the Philippines’ leading fintech company and digital bank, built an API management platform to address the growing complexities of managing multiple APIs hosted on Amazon API Gateway. API Gateway is a fully managed service that you can use to create RESTful and WebSocket APIs.

At Maya, different teams build APIs to expose their services to merchants. As the number of applications grew, the overhead of managing APIs increased. An API platform is a set of tools to simplify and standardize across API management concerns such as security, governance, automated deployments, observability, and integrations with multiple AWS accounts. This frees up application teams to focus on features while offloading management concerns to the API platform.

Initial state

Prior to implementing the API platform, Maya used a decentralized API management approach, which created significant challenges. Individual teams operated independent API gateways, resulting in fragmented infrastructure, leading to several issues:

  1. Lack of standardization: Implementing consistent API standards across the organization proved difficult. Each team maintained its own configurations and practices, leading to inconsistencies in security and documentation.
  2. Security posture maintenance: While Maya maintained a strong security posture, doing so across the numerous independent gateways was unsustainable. The overhead of applying consistent security policies and updates across all gateways was becoming increasingly burdensome.
  3. Inconsistent operational visibility: Observability wasn’t inherently limited, rather inconsistently applied. Having multiple, different gateways makes it challenging to enforce a unified observability strategy and correlate data across the entire API ecosystem.

Solution overview

To address these challenges, Maya implemented an API platform, code-named Unified API Gateway. This centralized API management helps enforce consistent standards and improve overall security and observability. The following image illustrates the architecture of the Unified API Gateway and how it integrates with backend services managed and owned by different teams across different AWS accounts.

Enterprise-level AWS architecture diagram showing secured API gateway with multi-account EKS service distribution

API Platform Architecture

Maya chose to host all APIs in a central API account to centralize governance. This is managed by a dedicated shared services cloud team. Amazon CloudFront with AWS WAF and AWS Shield Advanced integration provides perimeter security. An AWS Lambda authorizer provides application security by managing authentication, authorization, and session management. This mitigates against the OWASP top 10 API security risks.

Integration to backend services is configured through API Gateway private integration and AWS Transit Gateway. In a decentralized API deployment strategy where APIs are co-hosted with the service in the respective AWS account, the integration will be simpler because you won’t need cross-account network connectivity. You will still benefit from the API management techniques covered in this post.

Standardization through structured service on-boarding

OpenAPI Specification (OAS) provides a structured definition for APIs. As shown in the following figure, service teams define the API OAS specification. This is embedded in Terraform infrastructure-as-code template for API Gateway. These are checked into source code repository and deployed using GitLab CI.

End-to-end API infrastructure pipeline showing specification integration through GitLab CI to AWS API Gateway

API Gateway Infrastructure-as-code (IaC) Pipeline

A configuration file used as a Terraform template supplies parameters for components of the solution such as backend integration, Lambda authorizer details, and additional headers for auditing. The following OAS snippets demonstrate this.

  1. Integration with the backend service 
    x-amazon-apigateway-integration:
   type: "http_proxy"
   connectionId: "${vpc_link_id}"
   httpMethod: "GET"
   uri: "http://$${stageVariables.url}:11620/v1/api/endpoint/{id}" # double $ is not a typo
  2. Adding headers to the request 
    x-amazon-apigateway-integration:
   type: "http_proxy"
   connectionId: "${vpc_link_id}"
   httpMethod: "GET"
   uri: "http://$${stageVariables.url}:11620/v1/api/endpoint/{id}"
   requestParameters:
      integration.request.header.x-requesting-service-id: "'api-gw'"
      integration.request.header.x-org-customer-id: "context.authorizer.x-org-customer-id"
  3. Security definition 
    securitySchemes:
   lambda-authorizer:
      type: "${authorizer_type}"  
      name: "${authorizer_name}"
      x-amazon-apigateway-authtype: "custom"
      x-amazon-apigateway-authorizer:
         type: "request"
         authorizerUri: "${authorizer_uri}"
         authorizerCredentials: "${authorizer_credentials}"
         identitySource: "${authorizer_identity_source}"

API Gateway supports most of the OpenAPI 2.0 specification and the OpenAPI 3.0 specification but there are a few exceptions. Maya uses a custom plugin in the pipeline to enforce necessary limiting rules to help ensure compatibility with API Gateway.

To simplify deployment for development teams, a custom Terraform module abstracts away the API Gateway implementation details.

module "test-microservice-api-gateway" {
  # module version parameters
  source = "gitlabinstance.com/platform-engineering/apigw-terraform-module/aws"
  version = "1.2.7"

  # module deployed infrastructure parameters
  api_name = var.api_name
  api_mapping_path = var.api_mapping_path
  environment = var.environment
  aws_region = var.aws_region
  account_id = var.account_id
  tags = var.tags
  domain_name = var.domain_name
  stage_name = var.stage_name

  oas_path = var.oas_path # this value is populated via environment variable in Gitlab CI/CD

  providers = {
     aws = aws.apigw
  }
  authorizer_credentials = var.authorizer_credentials
  authorizer_uri = var.authorizer_uri
  vpc_link_id = var.vpc_link_id
  endpoint_url = var.endpoint_url
}

To use multi-level prefixes for custom domains with REST API Gateway, you need the Terraform module for API Gateway v2.

resource "aws_api_gateway_rest_api" "apigw" {
   name = "${var.environment}-${var.api_name}"
   body = templatefile(
     local.oasFilePath,
     {
       vpc_link_id = var.vpc_link_id
       authorizer_uri = var.authorizer_uri
       authorizer_credentials = var.authorizer_credentials
     }
  )
  description = "API Gateway for ${var.api_name}"
  endpoint_configuration {
    types = ["REGIONAL"]
  }

   # Default endpoint needs to be disabled if CloudFront is used as entry point to API Gateway
  disable_execute_api_endpoint = true
  tags = local.tags
  }

  # Use apigatewayv2 in order to have multi level base path ex. /v1/service_name
  resource "aws_apigatewayv2_api_mapping" "this" {
     domain_name = var.domain_name
    api_id = aws_api_gateway_rest_api.apigw.id
    stage = aws_api_gateway_stage.apigw.stage_name
    api_mapping_key = var.api_mapping_path
  }

Simplify API security with automation

Maya’s Unified API Gateway implements a robust, multi-layered security strategy. This approach helps ensure comprehensive protection from external threats and enforces stringent access control policies.

AWS WAF inspects and filters incoming traffic to protect against common web exploits, including OWASP Top 10, such as SQL injection and cross-site scripting attacks. A combination of custom and managed rule sets blocks malicious requests and enforces security policies. AWS Shield Advanced mitigates distributed denial of service (DDoS) attacks and provides 24/7 access to the AWS Shield Response Team (SRT) for expert support during attack events. This helps ensure high availability and resiliency.

API Gateway is integrated with a Lambda authorizer for authentication and authorization. The custom function implements fine-grained access control based on several factors such as identity, roles, and scopes.

To help ensure the consistency and integrity of the API configurations, all updates and deployments are strictly managed through an automated infrastructure-as-code (IaC) pipeline. This helps eliminate the risk of unauthorized or accidental manual changes to the API Gateway and any underlying infrastructure. The IaC pipeline makes sure that all API configurations, including security settings, are deployed through a controlled and auditable process. This prevents configuration drift and makes sure that security policies are consistently applied across all APIs. This also means that all changes are subject to code reviews and version control, adding another layer of security and traceability.

End-to-end visibility with observability

Maya’s Unified API Gateway prioritizes comprehensive observability to proactively monitor API performance, identify potential issues, and provide a seamless user experience. It uses a combination of AWS services and integrated tools to achieve this.

Amazon CloudWatch is used to monitor key performance metrics, including latency, error rates, and requests counts. CloudWatch provides real-time insights into the health and performance of APIs. Alerts on P95 and P99 values help identify and address performance bottlenecks, ensuring responsiveness.

CloudWatch metrics are streamed to Dynatrace, an application performance monitoring (APM) tool. The centralized view helps correlate data from various sources, create custom dashboards, and configure intelligent alerts based on predefined thresholds.

To help ensure complete visibility into API activity, the Lambda authorizer and API Gateway access logs are centralized in Splunk. This provides a comprehensive audit trail to track authentication and authorization events, identify security incidents, and troubleshoot API requests. Headers generated after authentication and authorization are done are passed down to the backend services for proper log correlation.

Future roadmap

The Unified API Gateway will continue to evolve to meet the growing needs of the organization and its partners and customers. The following are the key future enhancements that will further streamline API management, improve the developer experience, and enhance security.

  1. Integration with the internal developer portal: This will provide a self-service UI for bootstrapping new APIs from scratch and further empower developers. This will also simplify documentation and discovery by cataloging all APIs
  2. A modular, extension-based design for enhanced processing: This will introduce custom processing of requests in-line in the gateway account before integrating with backend services. Examples include digital signature verification, message transformation, and custom business logic. A modular design will offer a flexible and scalable way to enhance the functionality of Maya’s APIs without modifying backend services.
  3. Bring your own (BYO) authorizer: Support a wider range of identity providers and authentication protocols, providing greater flexibility and control over API access.
  4. Centralizing schema validation: Moving schema validation to API Gateway to bring consistency and improve the robustness and security of APIs by preventing malformed or malicious requests from being processed.
  5. API monetization: Create new revenue streams by adding support for usage-based billing, tiered pricing, and subscription models.

Conclusion

This post has described the creation of Maya’s robust API management and governance solution, using a combination of native AWS services and powerful partner tools such as Terraform and Dynatrace. We’ve demonstrated how this Unified API Gateway has streamlined and automated core API processes, transforming Maya’s previously fragmented infrastructure into a secure and observable ecosystem. By establishing clear guardrails, the API solution team empowers developers to rapidly deploy APIs while maintaining consistent standards.

With the recent implementation of this solution across more teams, Maya is focused on defining and tracking key performance indicators (KPIs). We anticipate measuring critical metrics such as API onboarding efficiency, developer experience, API latency, and security incident rates. These insights will serve as a foundation for continuous improvement and optimization, ensuring the solution’s sustained effectiveness and evolution.

Visit the API platform guidance on Serverlessland to learn more about building API platforms. See the API Gateway pattern collection to learn more about designing REST API integrations on AWS.

About the Authors

Unify streaming and analytical data with Amazon Data Firehose and Amazon SageMaker Lakehouse

Post Syndicated from Kalyan Janaki original https://aws.amazon.com/blogs/big-data/unify-streaming-and-analytical-data-with-amazon-data-firehose-and-amazon-sagemaker-lakehouse/

Organizations are increasingly required to derive real-time insights from their data while maintaining the ability to perform analytics. This dual requirement presents a significant challenge: how to effectively bridge the gap between streaming data and analytical workloads without creating complex, hard-to-maintain data pipelines. In this post, we demonstrate how to simplify this process using Amazon Data Firehose (Firehose) to deliver streaming data directly to Apache Iceberg tables in Amazon SageMaker Lakehouse, creating a streamlined pipeline that reduces complexity and maintenance overhead.

Streaming data empowers AI and machine learning (ML) models to learn and adapt in real time, which is crucial for applications that require immediate insights or dynamic responses to changing conditions. This creates new opportunities for business agility and innovation. Key use cases include predicting equipment failures based on sensor data, monitoring supply chain processes in real time, and enabling AI applications to respond dynamically to changing conditions. Real-time streaming data helps customers make quick decisions, fundamentally changing how businesses compete in real-time markets.

Amazon Data Firehose seamlessly acquires, transforms, and delivers data streams to lakehouses, data lakes, data warehouses, and analytics services, with automatic scaling and delivery within seconds. For analytical workloads, a lakehouse architecture has emerged as an effective solution, combining the best elements of data lakes and data warehouses. Apache Iceberg, an open table format, enables this transformation by providing transactional guarantees, schema evolution, and efficient metadata handling that were previously only available in traditional data warehouses. SageMaker Lakehouse unifies your data across Amazon Simple Storage Service (Amazon S3) data lakes, Amazon Redshift data warehouses, and other sources, and gives you the flexibility to access your data in-place with Iceberg-compatible tools and engines. By using SageMaker Lakehouse, organizations can harness the power of Iceberg while benefiting from the scalability and flexibility of a cloud-based solution. This integration removes the traditional barriers between data storage and ML processes, so data workers can work directly with Iceberg tables in their preferred tools and notebooks.

In this post, we show you how to create Iceberg tables in Amazon SageMaker Unified Studio and stream data to these tables using Firehose. With this integration, data engineers, analysts, and data scientists can seamlessly collaborate and build end-to-end analytics and ML workflows using SageMaker Unified Studio, removing traditional silos and accelerating the journey from data ingestion to production ML models.

Solution overview

The following diagram illustrates the architecture of how Firehose can deliver real-time data to SageMaker Lakehouse.

This post includes an AWS CloudFormation template to set up supporting resources so Firehose can deliver streaming data to Iceberg tables. You can review and customize it to suit your needs. The template performs the following operations:

Prerequisites

For this walkthrough, you should have the following prerequisites:

After you create the prerequisites, verify you can log in to SageMaker Unified Studio and the project is created successfully. Every project created in SageMaker Unified Studio gets a project location and project IAM role, as highlighted in the following screenshot.

Create an Iceberg table

For this solution, we use Amazon Athena as the engine for our query editor. Complete the following steps to create your Iceberg table:

  1. In SageMaker Unified Studio, on the Build menu, choose Query Editor.

  1. Choose Athena as the engine for query editor and choose the AWS Glue database created for the project.

  1. Use the following SQL statement to create the Iceberg table. Make sure to provide your project AWS Glue database and project Amazon S3 location (can be found on the project overview page):
CREATE TABLE firehose_events (
type struct<device: string, event: string, action: string>,
customer_id string,
event_timestamp timestamp,
region string)
LOCATION '<PROJECT_S3_LOCATION>/iceberg/events'
TBLPROPERTIES (
'table_type'='iceberg',
'write_compression'='zstd'
);

Deploy the supporting resources

The next step is to deploy the required resources into your AWS environment by using a CloudFormation template. Complete the following steps:

  1. Choose Launch Stack.
  2. Choose Next.
  3. Leave the stack name as firehose-lakehouse.
  4. Provide the user name and password that you want to use for accessing the Amazon Kinesis Data Generator application.
  5. For DatabaseName, enter the AWS Glue database name.
  6. For ProjectBucketName, enter the project bucket name (located on the SageMaker Unified Studio project details page).
  7. For TableName, enter the table name created in SageMaker Unified Studio.
  8. Choose Next.

  1. Select I acknowledge that AWS CloudFormation might create IAM resources and choose Next.

  1. Complete the stack.

Create a Firehose stream

Complete the following steps to create a Firehose stream to deliver data to Amazon S3:

  1. On the Firehose console, choose Create Firehose stream.

  1. For Source, choose Direct PUT.
  2. For Destination, choose Apache Iceberg Tables.

This example chooses Direct PUT as the source, but you can apply the same steps for other Firehose sources, such as Amazon Kinesis Data Streams and Amazon Managed Streaming for Apache Kafka (Amazon MSK).

  1. For Firehose stream name, enter firehose-iceberg-events.

  1. Collect the database name and table name from the SageMaker Unified Studio project to use in the next step.

  1. In the Destination settings section, enable Inline parsing for routing information and provide the database name and table name from the previous step.

Make sure you enclose the database and table names in double quotes if you want to deliver data to a single database and table. Amazon Data Firehose can also route records to different tables based on the content of the record. For more information, refer to Route incoming records to different Iceberg tables.

  1. Under Buffer hints, reduce the buffer size to 1 MiB and the buffer interval to 60 seconds. You can fine-tune these settings based on your use case latency needs.

  1. In the Backup settings section, enter the S3 bucket created by the CloudFormation template (s3://firehose-demo-iceberg-<account_id>-<region>) and the error output prefix (error/events-1/).

  1. In the Advanced settings section, enable Amazon CloudWatch error logging to troubleshoot any failures, and in for Existing IAM roles, choose the role that starts with Firehose-Iceberg-Stack-FirehoseIamRole-*, created by the CloudFormation template.
  2. Choose Create Firehose stream.

Generate streaming data

Use the Amazon Kinesis Data Generator to publish data records into your Firehose stream:

  1. On the AWS CloudFormation console, choose Stacks in the navigation pane and open your stack.
  2. Select the nested stack for the generator, and go to the Outputs tab.
  3. Choose the Amazon Kinesis Data Generator URL.

  1. Enter the credentials that you defined when deploying the CloudFormation stack.

  1. Choose the AWS Region where you deployed the CloudFormation stack and choose your Firehose stream.
  2. For the template, replace the default values with the following code:
{
"type": {
"device": "{{random.arrayElement(["mobile", "desktop", "tablet"])}}",
"event": "{{random.arrayElement(["firehose_events_1", "firehose_events_2"])}}",
"action": "update"
},
"customer_id": "{{random.number({ "min": 1, "max": 1500})}}",
"event_timestamp": "{{date.now("YYYY-MM-DDTHH:mm:ss.SSS")}}",
"region": "{{random.arrayElement(["pdx", "nyc"])}}"
}
  1. Before sending data, choose Test template to see an example payload.
  2. Choose Send data.

You can monitor the progress of the data stream.

Query the table in SageMaker Unified Studio

Now that Firehose is delivering data to SageMaker Lakehouse, you can perform analytics on that data in SageMaker Unified Studio using different AWS analytics services.

Clean up

It’s generally a good practice to clean up the resources created as part of this post to avoid additional cost. Complete the following steps:

  1. On the AWS CloudFormation console, choose Stacks in the navigation pane.
  2. Select the stack firehose-lakehouse* and on the Actions menu, choose Delete Stack.
  3. In SageMaker Unified Studio, delete the domain created for this post.

Conclusion

Streaming data allows models to make predictions or decisions based on the latest information, which is crucial for time-sensitive applications. By incorporating real-time data, models can make more accurate predictions and decisions. Streaming data can help organizations avoid the costs associated with storing and processing large datasets, because it focuses on the most relevant information. Amazon Data Firehose makes it straightforward to bring real-time streaming data to data lakes in Iceberg format and unifying it with other data assets in SageMaker Lakehouse, making streaming data accessible by various analytics and AI services in SageMaker Unified Studio to deliver real-time insights. Try out the solution for your own use case, and share your feedback and questions in the comments.

About the Authors

Kalyan Janaki is Senior Big Data & Analytics Specialist with Amazon Web Services. He helps customers architect and build highly scalable, performant, and secure cloud-based solutions on AWS.

Phaneendra Vuliyaragoli is a Product Management Lead for Amazon Data Firehose at AWS. In this role, Phaneendra leads the product and go-to-market strategy for Amazon Data Firehose.

Maria Ho is a Product Marketing Manager for Streaming and Messaging services at AWS. She works with services including Amazon Managed Streaming for Apache Kafka (Amazon MSK), Amazon Managed Service for Apache Flink, Amazon Data Firehose, Amazon Kinesis Data Streams, Amazon MQ, Amazon Simple Queue Service (Amazon SQS), and Amazon Simple Notification Services (Amazon SNS).

Navigating the threat detection and incident response track at re:Inforce 2025

Post Syndicated from Nisha Amthul original https://aws.amazon.com/blogs/security/navigating-the-threat-detection-and-incident-response-track-at-reinforce-2025/

AWS re:Inforce 2025: June 16-18 in Philadelphia, PA

A full conference pass is $1,099. Register today with the code flashsale150 to receive a limited time $150 discount, while supplies last.

We’re counting down to AWS re:Inforce, our annual cloud security event! We are thrilled to invite security enthusiasts and builders to join us in Philadelphia, PA June 16–18, 2025, for an immersive three-day journey into cloud security learning. At AWS re:Inforce, you’ll have the chance to explore the breadth of the Amazon Web Services (AWS) security landscape, learn how to operationalize security services, and enhance your skills and confidence in cloud security to improve your organization’s security posture. As an attendee, you will have access to over 250 sessions across multiple topic tracks, including data protection; identity and access management; threat detection and incident response; network and infrastructure security; generative AI; governance, risk, and compliance; and application security. Plus, get ready to be inspired by our lineup of customer speakers, who will share their firsthand experiences of innovating securely on AWS.

In this post, we provide an overview of the key sessions that include lecture-style presentations featuring real-world use cases from our customers and interactive small-group sessions led by AWS experts that guide you through practical problems and solutions.

The threat detection and incident response track is designed to demonstrate how to detect and respond to security risks to help protect workloads at scale. AWS experts and customers will present key topics such as unified cloud security, threat detection, vulnerability management, cloud security posture management, integrated detection-to-response, threat intelligence, operationalization of AWS security services, container security, effective security investigation, security analytics, and incident response best practices. We’ll also explore both strengthening security through the use of generative AI and securing generative AI workloads.

Breakout sessions, chalk talks, and lightning talks

TDR301 | Breakout session | Innovations in AWS detection and response for integrated security outcomes
Discover how AWS’s latest detection and response capabilities can help secure your cloud environment more effectively. Learn practical ways to achieve integrated security outcomes through enhanced threat detection, automated vulnerability management, and streamlined response—all at scale. We’ll show you how to use AWS security services to protect workloads and data, centralize security monitoring, manage security posture continuously, and unify security data, while leveraging generative AI for security operations. Walk away with actionable insights on integrating AWS detection and response services to strengthen and simplify your security across AWS.

TDR302 | Breakout session | Multi-stage threat detection using GuardDuty and MITRE
Enhance your threat detection capabilities by leveraging Amazon GuardDuty Extended Threat Detection alongside MITRE frameworks. In this session, Shane Steiger Esq. from MITRE Corp demonstrates how to effectively identify and respond to multi-stage security events in your AWS environment. Learn practical strategies for implementing detection controls, developing response procedures, and building resilient cloud architectures. Discover how integrating GuardDuty with MITRE frameworks can strengthen your event detection and response strategy.

TDR303 | Breakout session | Building secure generative AI security tools, featuring Trellix
Learn how to build enterprise-grade generative AI security tools that unify security data and enable natural language investigations. This session demonstrates practical approaches for developing secure generative AI solutions, including implementation patterns for data privacy and compliance controls. Explore real-world architectures combining AWS foundation models with security orchestration. Hear how Trellix achieved 23x cost savings while maintaining 95% accuracy using Amazon Bedrock models. Leave with strategies to build secure AI assistants that support your security teams.

TDR304 | Breakout session | Scaling AWS threat intelligence to protect customers
Discover how AWS builds and operates threat intelligence at unprecedented scale to protect millions of customers. In this session, dive deep into two critical security functions: Amazon Threat Intelligence, which tracks and defends against sophisticated threats, and Active Defense, our security data processing architecture that analyzes over 4 billion records per second. Learn how these capabilities work together to power AWS security services and provide automated protection for your applications. See how AWS uses this intelligence to continuously enhance security services that help keep your workloads safe.

TDR305 | Breakout session | Scale Vulnerability Management Using Amazon Inspector
Want to strengthen Lambda security and streamline vulnerability management? Learn how Amazon Inspector uses generative AI to provide in-context code patches and automate SBOM management. Discover practical techniques for CI/CD integration, cross-account scanning, and automated remediation workflows. Explore built-in integrations with Security Hub and EventBridge to enhance security operations across your AWS environment.

TDR306 | Breakout session | Enterprise Security at Scale: SAP’s AWS Blueprint
How does SAP protect thousands of AWS accounts? Learn their blueprint for implementing Amazon GuardDuty protection plans alongside Extended Threat Detection to identify sophisticated threat patterns. Discover their framework for standardizing AWS Security Hub controls and automated remediation workflows at scale. Walk away with practical strategies to enhance enterprise security operations across AWS Organizations.

TDR331 | Chalk talk | Ask AWS: Your ransomware questions answered
Get answers to your most critical ransomware questions in this interactive Q&A session. Learn how AWS security features and best practices can help you detect, respond to, and recover from ransomware threats. Our experts will share practical guidance on identifying early warning signs, implementing effective incident response, and strengthening your overall ransomware resilience. Bring your toughest questions about emerging ransomware tactics and cloud protection strategies. Walk away with actionable insights to help secure your data and operations using AWS security capabilities.

TDR332 | Chalk talk | Decoding AWS CIRT tactics & techniques for proactive defense
Learn directly from AWS Customer Incident Response Team (CIRT) experts who help customers respond to critical security events. Discover real-world insights about emerging threat tactics and techniques observed across AWS environments. We’ll share practical detection and mitigation strategies that align with the Shared Responsibility Model, helping you strengthen your security posture. Walk away with actionable best practices from CIRT’s frontline experience defending against evolving threats, and learn how to apply these insights to protect your AWS workloads.

TDR333 | Chalk talk | Strategy for prioritization and response
Join this session to discuss managing security posture and risk across multiple accounts, regions, and resources. We will explore the decision-making process around how you prioritize security alerts and risk using AWS security services. After prioritization, we will discuss a framework for responding to and remediating security findings. We will talk through the decision-making process of responding to findings, considerations for auto-remediation, and how to facilitate a quick and thorough response to the most critical security findings.

TDR334 | Chalk talk | Strengthen Security: Making GuardDuty Protection Plans Work for You
Discover how to maximize your threat detection capabilities by selecting the right Amazon GuardDuty protection plans for your environment. Learn to evaluate protection features that matter most for your AWS workloads and understand the value each plan brings to your security strategy. Through practical scenarios, explore cost-effective implementation strategies across your AWS accounts. Leave with actionable insights for optimizing your Amazon GuardDuty deployment to enhance protection of your AWS workloads and data.

TDR431 | Chalk talk | Best practices for containing AWS resources during incident response
Learn best practices for implementing isolation controls for AWS resources and accounts during security events. Through practical scenarios, discover effective approaches for isolating Amazon EC2 instances, AWS Lambda functions, and Amazon ECS containers. Explore comprehensive strategies for account-level isolation including identity, resource, and network controls. This session provides guidance on implementing and safely removing isolation controls as part of your response procedures. Leave with actionable patterns for strengthening your AWS incident response capabilities. To help businesses move faster and deliver security outcomes, modern security teams need to identify opportunities to automate and simplify their workflows. One way of doing so is through generative AI. Join this chalk talk to learn how to identify use cases where generative AI can help with investigating, prioritizing, and remediating findings from Amazon GuardDuty, Amazon Inspector, and AWS Security Hub. Then find out how you can develop architectures from these use cases, implement them, and evaluate their effectiveness. The talk offers tenets for generative AI and security that can help you safely use generative AI to reduce cognitive load and increase focus on novel, high-value opportunities.

TDR336 | Chalk talk | Secure generative AI models and agents on AWS
Learn how to strengthen security controls for generative AI models and Amazon Bedrock agents in your AWS environment. This session explores implementation patterns for protecting API endpoints and securing agent interactions. Discover practical approaches for implementing protective controls and maintaining data security for your AI/ML workloads. Leave with actionable strategies for building secure generative AI implementations using AWS services.

TDR337 | Chalk talk | Implementing AWS security best practices: Insights & strategies
Learn how to optimize your AWS security services implementation including Amazon GuardDuty, AWS Security Hub, and AWS WAF. AWS security experts share practical insights and proven patterns derived from thousands of customer deployments. This session provides actionable strategies for operationalizing security services effectively in your environment. Discover implementation best practices and architectural approaches that help you maximize the value of your AWS security services.

TDR338 | Chalk talk | Building cloud-native forensic investigation architectures on AWS
Join this chalk talk to explore the advantages of cloud-native digital forensics and incident response on AWS. Engage in interactive discussions on best practices for establishing secure forensic investigation environments. We’ll explore architectural patterns for safely collecting and storing forensic artifacts, leveraging ephemeral resources to enhance security, and implementing effective network, account, and organizational designs. Bring your questions and scenarios as we collaboratively examine how to build scalable, standardized investigation processes using AWS services. Leave with practical strategies for enhancing your forensic and incident response capabilities in the cloud.

TDR231 | Chalk talk | Resilient security teams: Reduce burnout and boost performance
Learn strategies for building resilient security and incident response teams that prioritize wellbeing while maintaining high performance. This session explores approaches for implementing regular team check-ins, data-informed wellbeing initiatives, and a supportive team culture. Discover practical methods for fostering open communication, maintaining team engagement, and recognizing team contributions. Through real-world examples, develop actionable plans to enhance team resilience, improve retention, and sustain security excellence. Leave with strategies to build and maintain high-performing security teams.

TDR321 | Lightning talk | From Incidents to Insights: Creating a Security Learning Organization
Learn how to transform security events into organizational improvements. This session demonstrates practical approaches for building effective feedback loops, preserving institutional knowledge, and implementing sustainable enhancements to security operations. Discover AWS strategies for measuring the impact of improvements and fostering a culture of continuous learning. Leave with actionable frameworks for strengthening your security program through systematic learning and adaptation.

TDR322 | Lightning talk | How AWS uses generative AI to advance native security services
Discover how AWS leverages generative AI to enhance native security services. This session demonstrates how AWS implements AI capabilities across its security portfolio to improve threat detection, investigation, and response. Explore practical implementations in Amazon GuardDuty and Amazon Inspector that enable automated analysis and natural language security queries. Leave with insights into how AWS makes security more intelligent and efficient through generative AI.

TDR323 | Lightning talk | How Autodesk scales threat detection with Amazon GuardDuty
Learn how Autodesk elevated their threat detection strategy using Amazon GuardDuty. This lightning talk explores their implementation approach, operational insights, and best practices for leveraging the advanced detection capabilities of GuardDuty, including malware protection. Discover how they maintain robust security while efficiently managing their growing cloud footprint.

TDR421 | Lightning talk | Accelerating Incident Response with AWS Security Incident Response
Learn how AWS Security Incident Response helps security teams streamline investigation and response procedures. This session demonstrates service integration capabilities with Amazon GuardDuty, AWS CloudTrail, and AWS Security Hub to provide centralized incident management. Through customer examples and implementation patterns, discover practical approaches for building automated response strategies. Leave with actionable insights for enhancing your security operations using AWS services.

Interactive sessions (builders’ sessions, code talks, and workshops)

TDR251 | Builders’ session | Build your first AI security assistant with Amazon Q
Discover how to build your first AI-powered security assistant using Amazon Q Business—no AI expertise required. In this hands-on session, you’ll create three practical security workflows: an automated Amazon GuardDuty incident investigator that contextualizes security findings, an AWS Security Hub compliance report generator that streamlines policy assessments, and an Amazon Inspector-based vulnerability management helper that accelerates remediation. Perfect for security practitioners who want to enhance AWS security operations with generative AI while mastering core AWS security services through practical application.

TDR252 | Builders’ session | Detect ransomware events in Amazon S3 using Amazon GuardDuty
In this builders’ session, join the AWS Customer Incident Response Team (CIRT) to implement Amazon S3 ransomware detection using Amazon GuardDuty. Through hands-on scenarios, learn to identify unauthorized encryption operations and implement effective response procedures. Build detection patterns using AWS CloudTrail, Amazon Athena, Amazon GuardDuty, and Amazon CloudWatch. Practice investigating events and implementing preventive measures aligned with AWS Security’s latest guidance for Amazon S3 object protection. You must bring your laptop to participate.

TDR351 | Builders’ session | Build an OCSF security log pipeline with AWS
Build a complete security log pipeline that leverages the Open Cybersecurity Schema Framework (OCSF) in this hands-on session. Work alongside AWS experts to ingest, transform, and enrich your security data. Learn practical techniques to standardize security logs, whether using your own schema or our provided examples. Walk away with implementable solutions to enhance your threat detection capabilities through normalized security data flows. Bring your laptop and optional custom log samples to create solutions tailored to your use cases.

TDR451 | Builders’ session | Automate incident response for Amazon EC2 and Amazon EKS
Learn how to streamline incident response using the Automated Forensics Orchestrator solution for Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Kubernetes Service (Amazon EKS). This session demonstrates how to implement automated workflows triggered by AWS Security Hub findings. Explore implementation prerequisites, customization options, and best practices for enhancing your security operations through automated forensics capabilities. Discover how to standardize response procedures across your Amazon EC2 and Amazon EKS environments.

TDR452 | Builders’ session | Build generative AI security runbooks with Amazon Bedrock
In this builders’ session, learn how to enhance security operations using generative AI-powered runbooks with Amazon Bedrock and Bedrock Agents. Create intelligent workflows that analyze AWS Security Hub findings and provide contextual remediation guidance. Through hands-on exercises, build Bedrock Agents that leverage AWS documentation and implement natural language interfaces for security investigations. Learn how to configure knowledge bases with organization-specific content and implement appropriate guardrails. Leave with a practical solution for streamlining security operations using generative AI. You must bring your laptop to participate.

TDR341 | Code talk | Build AI security agents with Amazon Bedrock and Security Lake
In this code talk, explore how to enhance security operations by creating AI agents using Amazon Bedrock and Amazon Security Lake. Through live coding demonstrations, learn to build automated workflows that combine autonomous decision-making capabilities with generative AI for security analysis and response. See how to implement agents that analyze logs, provide contextual insights, and execute response procedures. Discover practical approaches for integrating custom tools and leveraging large language models in your security workflows.

TDR342 | Code talk | Operationalizing Amazon Security Lake with analytics and generative AI
Roll up your sleeves for this hands-on coding session where we’ll build modern security analytics tools on top of Amazon Security Lake. Through interactive demos, we’ll craft queries and visualizations to operationalize your security data using AWS services like Amazon OpenSearch Service, Amazon QuickSight, Amazon Athena, and Amazon Bedrock. Leave with practical code samples and architectures to analyze security data. Get inspired with ideas on how to transform your threat detection and incident response stack.

TDR343 | Code talk | From detection to code: GuardDuty attack sequences with Amazon Q
In this code talk, explore how Amazon GuardDuty attack sequence detection capabilities work alongside Amazon Q to enhance security operations. Through live coding demonstrations, learn hoGuardDuty machine learning models identify connected security events and create comprehensive event sequences. See how to build automated response procedures using Amazon Q AI-assisted development capabilities. Discover practical approaches for implementing context-aware security automation. Leave with implementation patterns for enhancing your security operations using generative AI tools.

TDR371 | Workshop | Hands-on Threat Detection & Response using AWS Security
Get hands-on experience with AWS security services in this interactive workshop. Learn to detect and respond to simulated threats using Amazon GuardDuty, Amazon Inspector, AWS Security Hub, and Amazon Detective. Practice both manual and automated response techniques with AWS Lambda as you investigate security events across different resource types. Walk away with practical skills to operationalize threat detection and response in your AWS environment. Bring your laptop to participate in this hands-on workshop.

TDR372 | Workshop | Secure container workloads with AWS security services
In this workshop, learn how to implement AWS security services to protect container workloads end-to-end from code to operations. Gain hands-on experience with static code analysis, detective controls, threat detection, vulnerability management, and incident response for Amazon Elastic Kubernetes Service (Amazon EKS) and Amazon Elastic Container Service (Amazon ECS). Through guided scenarios, discover how to use AWS security services to enhance your container security posture. Leave with practical strategies for implementing security controls in your container environments. You must bring your laptop to participate.

TDR471 | Workshop | AWS Security Incident Response Challenge: Defense in action
Put your AWS security incident response skills to the test in this interactive session. Assume the role of an AWS Security Engineer responding to a time-sensitive scenario. Using provided intelligence, you’ll have a limited time to implement security controls in your AWS environment. Learn to prioritize actions and leverage AWS security services effectively under realistic conditions. This hands-on exercise helps you practice rapid decision-making and security implementation in AWS environments. Leave with practical experience in incident response strategies. You must bring your laptop to participate.

TDR472 | Workshop | Active defense strategies using AWS AI/ML services
This workshop will help you learn how to develop and deploy active defense strategies, such as deception, using Amazon Bedrock and Amazon SageMaker. Gain hands-on experience developing AI-driven responses for security operations. You will learn how to develop adaptive responses that mimic what an actor may be trying use against you. You will Learn implementation patterns for prompt engineering, deployment strategies, and monitoring methodologies. You must bring your laptop to participate.

Browse the full re:Inforce catalog to learn more about sessions in other tracks, plus gamified learning, innovation sessions, partner sessions, and labs. Discover how to optimize your re:Inforce journey with our attendee guides—your essential resource for selecting perfect learning sessions and getting the greatest value from your experience.

Our comprehensive track content is designed to help arm you with the knowledge and skills needed to securely manage your workloads and applications on AWS. Don’t miss out on the opportunity to stay updated with the latest best practices in threat detection and incident response. Join us in Philadelphia for re:Inforce 2025 by registering today. We can’t wait to welcome you!

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Nisha Amthul

Nisha Amthul

Nisha is a Senior Product Marketing Manager at AWS Security, specializing in detection and response solutions. She has a strong foundation in product management and product marketing within the domains of information security and data protection. When not at work, you’ll find her cake decorating, strength training, and chasing after her two energetic kiddos.

[$] Cory Doctorow on how we lost the internet

Post Syndicated from jake original https://lwn.net/Articles/1021871/

Cory Doctorow wears many hats:
digital activist, science-fiction author, journalist, and more. He has
also written many books, both fiction and non-fiction, runs the Pluralistic blog, is a visiting
professor, and is an advisor to the Electronic
Frontier Foundation (EFF); his Chokepoint Capitalism
co-author, Rebecca Giblin, gave a 2023 keynote
in Australia that we covered. Doctorow gave a rousing keynote on
the state of the “enshitternet”—today’s internet—to kick
off the recently held PyCon US
2025 in Pittsburgh, Pennsylvania.

Retail Under Siege: What Recent Cyber Attacks Tell Us About Today’s Threat Landscape

Post Syndicated from Emma Burdett original https://blog.rapid7.com/2025/05/27/retail-under-siege-what-recent-cyber-attacks-tell-us-about-todays-threat-landscape/

Retail Under Siege: What Recent Cyber Attacks Tell Us About Today’s Threat Landscape

When several major UK organizations, including well-known retail brands, found themselves caught in a cyber attack earlier this year, it made headlines. But this incident wasn’t the first, and it won’t be the last. It reflects a growing trend where attackers exploit third-party vendors to breach multiple businesses through a single point of entry.

In one case, the compromise stemmed from a vulnerability in MOVEit Transfer, a widely used file transfer tool. Attackers exploited the flaw through Zellis, a payroll provider servicing organisations such as Boots, the Co-op, and parts of the NHS. From that single access point, they were able to exfiltrate sensitive employee data, including names, dates of birth, national insurance numbers, and in some cases, bank details. Some customer data was also affected, although not financial information.

This wasn’t just a breach. It was a blueprint—and a clear signal that even the most trusted brands are vulnerable when third-party risk is left unaddressed.

A back door into the business

The MOVEit vulnerability, first exposed in mid-2023, has become a favoured entry point for criminal groups looking to conduct high-volume, high-impact attacks. In this instance, attackers reportedly linked to the group Scattered Spider moved quickly, exploiting the flaw to access data at scale.

They didn’t need to phish credentials, crack passwords, or trick users. They found a vulnerable service buried in the supply chain and used automation and speed to do the rest.

This type of breach is becoming alarmingly common. Attackers increasingly target third-party software and services, i.e. vendors with connections to dozens or hundreds of organisations, because it maximises the potential return on effort. Instead of breaching one business at a time, they go upstream and compromise a shared dependency.

Scattered Spider in particular has shown a keen focus on the retail sector, where high transaction volumes, rich identity data, and complex supply chains create an attractive threat surface. As noted in Dark Reading, these groups are playing the long game—building persistent access, quietly exfiltrating data, and returning to monetise later.

This is third-party risk in action. And it’s only becoming more sophisticated.

Modern threat actors, old-school outcomes

Rapid7’s threat intelligence teams have tracked how ransomware groups and data extortion crews have professionalised their operations over the past two years. These groups are no longer operating in the shadows. They’re mimicking enterprise structures, with revenue sharing models, support desks, marketing channels, and on-demand tooling.

Groups like DragonForce, for instance, use a white-label ransomware-as-a-service model built on LockBit code, offering affiliates a fully managed platform for launching attacks. As Raj Samani, SVP and Chief Scientist at Rapid7, noted in recent research, these groups provide their affiliates with everything they need to run sophisticated campaigns: prebuilt infrastructure, encryption tools, data leak sites, and communication channels. Their tactics often involve dual extortion – stealing data and threatening to publish it unless a ransom is paid, adding public pressure to the private pain of a breach.

This business-like approach is exactly why ransomware remains one of the most dominant threats in 2025. Ransomware today is less about disruption and more about strategy. Our recent analysis explores how these attacks have evolved from smash-and-grab to long-game economics, with extortion tactics designed to exert maximum pressure over time.

But the financial hit is only one part of the damage. As Raj explores in this piece for the Cyber Threat Alliance, the broader impact of cybercrime often goes uncounted—from reputational fallout and operational disruption to the long-term toll it takes on people and trust. These are the consequences organisations must now plan for, not just respond to.

These tactics are playing out across the retail sector and beyond. Attackers are using known exploits, moving efficiently, and causing maximum disruption—not by inventing new techniques, but by taking advantage of weaknesses businesses continue to overlook.

The visibility gap

The obvious takeaway is that third-party risk is real, and growing. But there’s a deeper issue beneath the surface: many organisations lack the visibility they need to see where their risk truly lies.

As we’ve argued before, proactive visibility is foundational to strong cybersecurity. If you don’t have a live, accurate view of your external exposure across infrastructure, vendors, applications, and user behaviour, you’re already behind. And if you don’t understand how your systems interact with those of your partners, you can’t realistically assess the blast radius of a third-party breach.

This is where a Continuous Threat Exposure Management (CTEM) approach is essential. CTEM isn’t about reacting to every vulnerability alert. It’s about identifying which exposures are most likely to be exploited and putting the processes in place to resolve them before attackers take advantage.

That means:

  • Mapping your external attack surface, including shadow assets and forgotten systems
  • Actively monitoring your vendors and data flows, not just annually but continuously
  • Understanding exploitability, not just vulnerability, to focus on risk, not noise
  • Running simulations, tabletops, and breach-and-attack testing to stress-test your response before the real thing hits

The goal isn’t perfection. It’s preparedness.

From theory to action

The real takeaway for security leaders isn’t “this could happen to us.” It’s the recognition that some version of this is already happening—whether they know it or not.

Attackers are scanning your environment. They’re probing your vendors. They’re replaying leaked credentials and looking for unpatched services. What they find, and how quickly you detect and respond defines the outcome.

This is why we encourage organisations to move from reactive defence to proactive control. You don’t need to boil the ocean. But you do need a plan that accounts for real-world attacker behaviour, not just compliance checklists.

At Rapid7, we advocate for a layered, risk-informed approach. That includes:

  • Exposure management that gives you live insight into where your business is vulnerable
  • Attack surface management that helps you find and fix weaknesses before they’re exploited
  • Managed detection and response (MDR) services that augment your team’s ability to act quickly and effectively

But more than any product or service, the most important element is mindset. Security is no longer something you install or outsource. It’s something you practice every day, across every level of the business.

Shared responsibility in a connected world

Breaches like this one also raise important questions for consumers.

As Rapid7 CTO EMEA Thom Langford recently pointed out, individuals can take practical steps to reduce their risk. That includes using a password manager to store strong, unique passwords, enabling multi-factor authentication (MFA), and avoiding the storage of card details in retail accounts. For frequent online shoppers, virtual or disposable cards offer an extra layer of protection.

Still, the burden cannot rest on individuals alone. Organisations must design systems that make secure choices the default. That means encrypting data at rest and in transit, enforcing MFA by default, and never storing sensitive credentials in plaintext.

In a hyper-connected digital economy, trust is everything. And trust is built through transparency, responsiveness, and consistent investment in security—even when there’s no breach in the headlines.

A final word

These attacks aren’t happening because a single business made a mistake. They’re happening because attackers are evolving and because the systems we all rely on are more interconnected than ever.

Security leaders can’t control every vendor or patch every flaw in someone else’s software. But they can control how they prepare, how they prioritise, and how they respond.

The organisations that come out stronger are the ones that treat security as a continuous discipline – one rooted in visibility, resilience, and readiness.

Because in 2025, the question isn’t whether you’ll be targeted.

It’s whether you’ll be ready.

Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/1022703/

Security updates have been issued by AlmaLinux (gstreamer1-plugins-bad-free, libsoup, and python-tornado), Debian (libavif and pgbouncer), Red Hat (gstreamer1-plugins-bad-free, mingw-freetype and spice-client-win, and webkit2gtk3), SUSE (firefox, govulncheck-vulndb, and python310-setuptools), and Ubuntu (flask, intel-microcode, openjdk-17-crac, tika, and Tomcat).

Chinese-Owned VPNs

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/05/chinese-owned-vpns.html

One one my biggest worries about VPNs is the amount of trust users need to place in them, and how opaque most of them are about who owns them and what sorts of data they retain.

A new study found that many commercials VPNS are (often surreptitiously) owned by Chinese companies.

It would be hard for U.S. users to avoid the Chinese VPNs. The ownership of many appeared deliberately opaque, with several concealing their structure behind layers of offshore shell companies. TTP was able to determine the Chinese ownership of the 20 VPN apps being offered to Apple’s U.S. users by piecing together corporate documents from around the world. None of those apps clearly disclosed their Chinese ownership.

Beyond phone bans: Empowering students to critically navigate and reimagine technology

Post Syndicated from Laura Kirsop original https://www.raspberrypi.org/blog/beyond-phone-bans-empowering-students-to-critically-navigate-and-reimagine-technology/

Amidst heated discussion of smartphones and their impacts on young people’s lives, it’s become a frequent recommendation to ban phones in schools. Below I summarise the research evidence on smartphone bans (it’s mixed) and share tips for computing educators on how to constructively address the topic with their learners and empower them to think critically about technology design.

Photo of a young person showing their mobile phone to a peer.

A turning tide

2024 was the year the tide turned against smartphones. Across the world, parents, teachers, and governments highlighted the risks of excessive phone use among young people. In the UK, the ‘Smartphone Free Childhood’ movement emerged, quickly growing to 100,000 members who advocate for keeping smartphones away from children due to concerns about addiction, harmful content, and mental health. Jonathan Haidt’s global bestseller The Anxious Generation has further fuelled the movement, linking smartphone use to adolescent mental health issues and recommending phonefree schools. Meanwhile, countries including England, France, and Finland have urged schools to adopt strict phone bans, hoping to reduce classroom distractions and enhance student safety.

Photo of a young person in a classroom showing their phone screen to their friends.

Despite widespread support, academic research on phone bans remains limited and inconclusive. Given this situation, computing educators are uniquely positioned to offer an alternative approach.

Evaluating evidence on phone bans 

The rapid spread of school smartphone bans is a straightforward response to complex issues around personal technology use in education. Teachers and parents frequently view phones as inherently disruptive, a perspective supported by studies that show phones can impair students’ focus and engagement in lessons. Concerns about cyberbullying and addiction contribute to this view, with many educators seeing bans as a practical solution to mitigate risks. Surveys in England reveal that nearly half of all secondary schools now enforce all-day bans. This trend was supported by teachers participating in my master’s degree research, who see these policies as necessary to reduce distractions and maintain control in the classroom. 

“Calls for outright bans may oversimplify the conversation.”

Yet calls for outright bans may oversimplify the conversation, limiting opportunities to examine both the benefits and the risks of smartphone use in schools. Evidence on the impact of phone restrictions is mixed: while some studies suggest restrictions may benefit learning, especially for students who struggle the most, others indicate no significant impact on academic outcomes. Additionally, recent findings show that cyberbullying is not directly linked to time spent online, with traditional bullying still more prevalent in schools. Even the narrative around smartphone addiction is contested, with some researchers suggesting that concerns about addiction may be overstated. And some places schools do not have access to digital devices for learners and then smartphones may play a crucial role in teaching and learning digital literacy skills.

Photo of four young people sitting at their desks, on their mobile phones.

As the debate over smartphone bans continues, educators have an opportunity to move beyond restrictions and engage students in understanding the technology that shapes their lives. This is where computing educators can really make a difference. How can they guide students to understand why technology is designed to capture attention and what lies behind these design choices?

Understanding and questioning the design of technology 

School smartphone bans can feel like a hopeless act that suggests phones and social media are inherently incompatible with learning and student well-being. This approach assumes the only solution is to remove them, rather than considering how these technologies might be better managed or reimagined to support young people. What if, instead of banning phones, educators worked with students to explore why they are so captivating and how they could be designed differently? Computing educators can lead this exploration. With digital literacy as part of their curriculum, computing teachers can help students question the motives behind their devices, fostering a critical understanding of the forces shaping their digital world.

“With digital literacy as part of their curriculum, computing teachers can help students question the motives behind their devices, fostering a critical understanding of the forces shaping their digital world.”

At the heart of how social media platforms are designed is their business models. Tech companies rely on features such as notifications, autoplay, and infinite scrolling to maximise user engagement and revenue. This is part of what the writer Shoshana Zuboff calls “surveillance capitalism”, where companies gather vast amounts of behavioural data by keeping users engaged on their platforms for as long as possible.

In the classroom, educators can open discussions with students on the motives behind technology design, exploring questions such as why platforms want users to stay engaged, and what data they are collecting. Activities might include analysing popular apps to identify which features encourage prolonged use, or debating how social media could be designed to prioritise user wellbeing. By critically examining these design choices, students can better understand the forces driving their digital interactions and consider ways in which technology could be reimagined to serve them, rather than just profiting from them. 

Collaborative policymaking 

Once young people understand why phones and social media are designed the way they are, educators can work with students to create phone policies that reflect shared values and goals. This collaborative approach encourages students to take ownership of their technology use, and computing teachers, drawing on their knowledge of technology design and digital literacy, are ideally positioned to facilitate these discussions.

Photo of three school pupils together looking at a mobile phone.

Research suggests that policies developed with student input are more effective, as they foster responsibility and engagement. By involving students in policymaking, educators can encourage them to consider how phones could support rather than hinder learning. For example, students might agree that phones should stay off during certain times, or in certain spaces, but that they might be useful in other scenarios where access benefits learning. This kind of flexibility ensures that phones are used thoughtfully, allowing for both practical boundaries and opportunities for educational use.

Critical skills for navigating the digital world

As debate around smartphone use in schools continues, academic research remains inconclusive on the effectiveness of phone bans. This uncertainty presents computing educators with an opportunity to move beyond restrictive policies and foster deeper understanding. By guiding students to explore why phones and social media are designed to capture attention, we can help to equip them with the critical skills needed to navigate their digital world thoughtfully. Involving students in crafting flexible, meaningful phone policies reinforces this understanding, giving them a sense of agency in shaping technology’s role in their lives.

Close up photo of a desk with school books, various coloured pens and a mobile phone in shot.

Computing educators are uniquely positioned to empower students, not just as users, but as active challengers of technology design norms. Embracing a collaborative approach allows computing educators to inspire students to envision a future where technology genuinely serves their growth and their learning, rather than commercial interests.

More on digital literacy for young people

A version of this article appears in the newest issue of Hello World magazine, which is all about teaching digital literacy. Explore issue 26 and download your free PDF copy today.

You can also listen to our recent Hello World podcast episode discussing the myth of the ‘digital native’ and whether today’s young people are tech-savvy or tech-dependent.

The post Beyond phone bans: Empowering students to critically navigate and reimagine technology appeared first on Raspberry Pi Foundation.

Next-Level Alert Analysis with DeepSeek and Zabbix

Post Syndicated from Zhe Cheng original https://blog.zabbix.com/next-level-alert-analysis-with-deepseek-and-zabbix/30424/

As IT infrastructures grow increasingly complex, efficiently analyzing monitoring data and accelerating incident response have become critical challenges for operations teams. This post explores a few innovative applications of DeepSeek when integrated with Zabbix.

Requirements:

– Zabbix server 7.0 or higher
– DeepSeek API (Alternatively, other AI APIs can be used if needed)

1. Scenario One: One-Click Intelligent Alert Analysis

By integrating DeepSeek Analytics into the Zabbix frontend, users can conduct intelligent alert analysis with just one click. This integration facilitates the swift generation of comprehensive fault analyses and solution suggestions, markedly decreasing the MTTR (Mean Time to Resolution). Consequently, it streamlines the troubleshooting process, alleviates the workload on IT personnel, ensures system stability, and conserves both time and resources.

1.1  On the Zabbix home page, navigate to “Alerts” > “Scripts”, and click on the “Create script” button.

1.2  Configuration script:

  • Name: Can be customized
  • Scope: Select “Manual event action”
  • Menu path: Customize menu paths for quick access
  • Type: Select “Script”
  • Execute on: Select “Zabbix proxy or server”

1.3 Enter the following command in the command bar:

/etc/zabbix/scripts/send_alert_to_ai.sh "{TRIGGER.NAME}" "{TRIGGER.SUBJECT}"  "{HOST.NAME}" "{HOST.IP}" "{EVENT.TIME}" "{TRIGGER.SEVERITY}"

1.4  Create an API call script on zabbix-server.

1.4.1 Modify the Zabbix Server Configuration File and Enable Global Scripts:

Open the Zabbix server configuration file for editing:

vi /etc/zabbix/zabbix_server.conf

Set the EnableGlobalScripts option to 1:

EnableGlobalScripts=1

Save the changes and exit the editor. Then, restart the Zabbix server service to apply the changes:

systemctl restart zabbix-server

1.4.2 Create an API Call Script.

Create a directory for custom scripts if it does not already exist:

mkdir -p /etc/zabbix/scripts && cd /etc/zabbix/scripts

Note: If the frontend prompts that the script file cannot be found, try moving the script to the directory used by the Nginx agent. Create a new script file named send_alert_to_ai.sh:

vi send_alert_to_ai.sh

Add the following content to the script, replacing DeepSeek KEY with your actual API key. Make sure you adjust the API call method if using a different AI service:

#!/bin/bash

# DeepSeek API configuration
API_URL="https://api.deepseek.com/chat/completions"
API_KEY="xxxxxxxxxxxxxxxxxxxx"

# Obtain the parameters to be passed as alarm information
TRIGGER_NAME="$1"
ALERT_SUBJECT="$2"
HOSTNAME="$3"
HOST_IP="$4"
EVENT_TIME="$5"
TRIGGER_SEVERITY="$6"

# Build a more concise JSON format for alarm information
alert_info=$(cat <<EOF
{
"model": "deepseek-chat",
"messages": [
{"role": "system", "content": "You are an assistant focused on responding quickly to system alarms。"},
{"role": "user", "content": "The following alarm information is received：\n\n: $TRIGGER_NAME\n: $ALERT_SUBJECT\n: $HOSTNAME\n: $HOST_IP\n: $EVENT_TIME\n: $TRIGGER_SEVERITY\n\nPlease tell me the cause of the alarm and the handling measures in a short and professional language with a word limit of 300 words。"}
],
"stream": false
}
EOF
)

# Send the POST request and capture the response and HTTP status code
response=$(curl -s -w "\n%{http_code}" -X POST "$API_URL" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $API_KEY" \
-d "$alert_info")

# Separate HTTP status codes from response bodies
http_code=$(echo "$response" | tail -n1)
response_body=$(echo "$response" | sed '$d')

# Parse and extract the content field
if [ "$http_code" -eq 200 ]; then
# Parse JSON using the jq tool
if ! command -v jq &> /dev/null; then
echo "jq could not be found, please install it first."
exit 1
fi

# Extract the content field and format the output
content=$(echo "$response_body" | jq -r '.choices[0].message.content')
echo -e "Analysis result:\n$content"
else
echo "failure: HTTP status code $http_code, respond: $response_body"
fi

Make the script executable:

chmod +x send_alert_to_ai.sh

Note: The script provided invokes the official DeepSeek API. Replace DeepSeek KEY with your actual API_KEY. If you are using another AI service, please confirm the appropriate API invocation method.

Important Notes:

Note: The script relies on jq to process and parse JSON data for tasks such as filtering, mapping, aggregating, and formatting. If jq is not installed on your system, follow these instructions to install it.

For Debian/Ubuntu Systems:

apt-get update
apt-get install jq

For CentOS/RHEL Systems:

yum install epel-release
yum install jq

1.5 Actual Effect Display:

1.6  Optional Optimization Items.

1.6.1 Adjust Output Box Size for Better Browsing.

After executing the script, you may find that the output box is too small and inconvenient to browse. To optimize this, you can modify the front-end CSS file as follows.

Back up the existing CSS File:

cd /usr/share/nginx/html/assets/styles/
cp blue-theme.css blue-theme.css.bak

Edit the CSS File:

vi /usr/share/nginx/html/assets/styles/blue-theme.css

Add Custom Styles at the End of the File.

Add the following CSS rules to adjust the size and behavior of the output box:

#execution-output {
height: 500px; /* Adjust to your desired height */
width: 540px; /* Optional: Adjust the width as required */
overflow-y: auto; /* Displays scrollbar when content exceeds the set height */
}

Save and exit the editor. At this point, clear the browser cache and reload the page to see the changes take effect.

1.6.2 How to Optimize Slow Output Response after Executing the One-Click Analysis Script.

During actual testing, it was estimated that returning a 300-word result takes approximately 20 to 30 seconds. While you can improve the response speed by adjusting the preset prompt words in the script, this approach may reduce the richness of the analysis content. Therefore, it is recommended to balance speed and content depth by adjusting the number of replies in the script’s prompt words according to your actual needs.

Actual effect display:

2. Scenario Two: Zabbix Documentation Knowledge Base Assistant

In today’s fast-paced IT environment, managing and retrieving information efficiently is crucial. To address this need, we’ve developed the Zabbix KB Assistant, an intelligent knowledge base solution built on MaxKB—an open-source Q&A system leveraging large language models.

This assistant streamlines access to Zabbix’s extensive documentation, making it easier than ever for users to find the information they require.
MaxKB stands out for its seamless integration capabilities, allowing for quick uploads of documents and automatic crawling of online content.

Its flexibility means it can be effortlessly embedded into third-party systems, including our very own Zabbix platform. The project is available at the GitHub repository.

The development process of Zabbix KB Assistant involved configuring MaxKB to recognize and parse the official Zabbix documentation. By utilizing this URL, we ensured that the latest updates and comprehensive guides are always accessible within our assistant. After setting up the core model configurations, we created a dedicated knowledge base tailored to Zabbix’s rich content.

With the knowledge base in place, we proceeded to integrate Zabbix KB Assistant into the Zabbix frontend. This step was essential for providing instant access to users navigating the Zabbix interface. By embedding a floating window mode, users can interact with the assistant without leaving their current page—a feature that significantly enhances user experience.

Actual effect display:

3. Scenario Three: DingTalk Alert Enhancement

By integrating DeepSeek’s deep analysis capabilities, DingTalk can automatically analyze alarm information upon receiving alerts. This integration provides precise fault diagnosis and solutions, aiding IT operations and maintenance personnel in quickly identifying and resolving issues. Consequently, this improves the efficiency of system maintenance and reduces downtime.

3.1 Create a Bot and Configure Security Settings.

First, create a new bot within the DingTalk group and ensure that the keyword “Alarm” is properly configured in the security settings. Next, retrieve the webhook URL for this bot and keep it safe for later use.

3.2 Install Python3 and Necessary Libraries.

Ensure that Python3 along with the required libraries are installed on your system. Depending on your operating system, follow these instructions.

For Ubuntu/Debian systems:

sudo apt update
sudo apt install python3 python3-pip
pip3 install requests

For CentOS/RHEL systems:

sudo dnf install python3
pip3 install requests

3.3 Below is an example script (deepseekdingding.py) located at /usr/lib/zabbix/alertscripts/.

Replace the placeholder webhook URL and DeepSeek API key in the script with your actual values:

#!/usr/bin/env python3
#coding:utf-8
import requests
import sys
import json

class DingTalkBot(object):
    # Send an alarm
    def send_news_message(self, webhook_url, subject, content, ai_response):
        url = webhook_url
        data = {
            "msgtype": "markdown",
            "markdown": {
                "title": subject,
                "text": f"{subject}\n{content}\n\n【DeepSeek analysis】:\n\n{ai_response}"  
            }
        }
        headers = {'Content-Type': 'application/json'}
        response = requests.post(url, headers=headers, data=json.dumps(data))
        return response

if __name__ == '__main__':
    WEBHOOK_URL = 'https://oapi.dingtalk.com/robot/send?access_token=224c1ff0c6df60a809b3c5b69b8448486b780d292e9d395ac8fbf84980214e30'  # Webhook
    API_URL = 'https://api.deepseek.com/chat/completions'
    API_KEY = "xxxxxxxxxxxxxxxxxxxx"  # DeepSeek API

    if len(sys.argv) < 3:
        print("Error: Not enough arguments provided.")
        sys.exit(1)

    subject = str(sys.argv[1])  
    content = str(sys.argv[2])  

    print(f"Received subject: {subject}")
    print(f"Received content: {content}")

    try:
        headers = {
            'Authorization': f'Bearer {API_KEY}',
            'Content-Type': 'application/json',
        }
        payload = {
            "model": "deepseek-chat",  # DeepSeek
            "messages": [
                {"role": "user", "content": f"If you are a professional IT operation and maintenance expert, please tell me the cause of these alarms and handling suggestions in a concise and professional language with a word limit of 100 words{content}"}
            ]
        }
        ai_response = requests.post(API_URL, headers=headers, json=payload)
        ai_response.raise_for_status()  
        ai_response_content = ai_response.json().get('choices', [{}])[0].get('message', {}).get('content', '')
    except Exception as e:
        ai_response_content = "\nThe interface call timed out or an error occurred. Please check the configuration and try again"

    bot = DingTalkBot()
    response = bot.send_news_message(WEBHOOK_URL, subject, content, ai_response_content)

    if response.status_code == 200:
        print("successfully")
    else:
        print(f"failed: {response.text}")

3.5 On the Zabbix home page, go to Alerts – Media types – Create Media type and then enter the following information:

  • Name: aiAlarm-Dingtalk
  • Type: script
  • Script name: deepseekdingding.py
  • Script parameter: {ALERT.MESSAGE} {ALERT.SUBJECT}

3.6 Create an alarm action.

Go to Alarm – Action – Trigger actions – Create action and set the name to Alarm -deepseek. Select this parameter as required:

Edit the action options as follows:

Send to media type aiAlarm-Dingtalk
Topic fault alarm: {EVENT.NAME}
message
【Zabbix Alarm Notification 】

Alarm group: {TRIGGER.HOSTGROUP.NAME}

Alarm host: {HOSTNAME1}

Alarm time: {EVENT.DATE} {EVENT.TIME}

Alert level: {TRIGGER.SEVERITY}

Problem information: {TRIGGER.NAME}

Confirm the update.

3.7 Configure notification rights for users.

The following item is added to the “User-User-Alarm” media dialog box. Once added, click Update.

Actual effect display：

4. Scenario Four: One-Click System Service Deep Analysis

Our solution integrates DeepSeek analysis to offer a one-click intelligent inspection tool that automates the collection of service configurations, logs, and status from within your system. This information is then sent via API to DeepSeek for comprehensive analysis.

Our approach begins by extracting relevant configuration data, recent log entries, and current service statuses. These pieces of information are combined with predefined prompts and submitted to DeepSeek through its API. For instance, a prompt might look like this:

“Here are the current logs for XXX service:\n\n${recent_logs}\n\nService. Status is as follows:\n${service_status}\n. Please analyze the following four aspects based on this information and provide a concise report within 500 words: service status analysis, configuration review, historical issue examination, and troubleshooting recommendations.”

DeepSeek processes this input to perform a detailed breakdown across these four areas, delivering structured feedback and actionable insights.
This integration offers deep system analysis and precise optimization suggestions, enabling swift responses to system changes or anomalies. It aids administrators in promptly identifying and addressing issues.

In addition, it’s easily integrated into existing monitoring systems, allowing adjustments to the depth and scope of analysis as needed. The solution boasts high scalability and flexibility, catering to evolving business requirements.

Actual effect display ：

The post Next-Level Alert Analysis with DeepSeek and Zabbix appeared first on Zabbix Blog.

„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс

Post Syndicated from original https://www.toest.bg/kiberpunk-2077-udovolstvie-i-ludonarativen-disonans/

„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс

Миглена Николчина: Всички сме играли в прехлас „Киберпънк“ (Cyberpunk 2077), така че, надявам се, да ви привлека в обща дискусия за една особеност на видеоигрите, която в предишен разговор Северина Станкева въведе чрез понятието „лудонаративен дисонанс“. Лудонаративният дисонанс назовава несъвпадението на повествованието и игровата механика, което е доста чест, дори преобладаващ момент. Северина дава като типичен пример „Последните от нас“ (The Last of Us),

където разказът се концентрира върху моралните дилеми на главния герой в постапокалиптичен свят на зомби зараза, а в същото време играчът прекарва времето си, поемайки контрол над този герой, да убива всичко живо и неживо, без въобще да е поставен в позиция да се двоуми.

Понякога този дисонанс е вграден в иманентната морална двусмисленост на света на играта – „Древните скрижали“ (The Elder Scrolls) с техните инфантилни и отмъстителни богове ми се виждат пример за това. Дисонансът разцепва сериозните и дори мрачни послания (не само наративни – те могат да включват визията, музиката и пр.) от чисто удоволствения компонент на приключението, битките, преодоляването на препятствия и опасности, търсенето на разни потайности, решаването на ребуси и пр.

В случая с „Киберпънк“ този дисонанс ми се видя – за разлика от други случаи, когато просто го приемам – като особено скандален. Играта е мрачна, много мрачна. Тя ни въвежда в един ужасяващ свят, който дори не е съвсем дистопиен, а си е реалистично кошмарен с днешна дата. И заедно с това играта е хипнотично удоволствена – не просто увлекателна, потапяща и пр., а сладко омайваща като прелъстителните чудовища, които среща Одисей. С часове зарязвах всякакви сюжетни драми, за да се плъзгам по магистралите, да обхождам бордеите, да участвам в улични схватки. Създателите на играта съзнават този дисонанс, който приписват на самата ни епоха на „обществото на зрелището“ (да го кажем по Ги Дебор).

Като пример – който може да бъде разглеждан като изоморфен, умален вариант на играта като цяло – ще дам страничната линия на „Грешника“ (Sinnerman). Убиец, претърпял религиозно преображение в затвора, по собствено желание е заснет в „невротанц“ (braindance), в който е прикован на кръст и умира. Играчът може чрез аватара си да закове пироните. За Грешника това е абсолютно сериозно, той поема ролята си на жертва и като изкупление, и като религиозно послание. За екипа, който снима, това е артистична амбиция и финансов удар. За хората, които ще гледат – вълнуващ спектакъл. Жертвата е илюзорно зрелище, разядена е от всички възможни грехове (от сребролюбието до убийството, до сатанинската гордост), но във всичко това тя е истинска и покъртителна. Този епизод ми се струва метакоментар на играта като цяло.

Въпросът все пак си стои –

не изяжда ли зрелището сериозността на смисъла?

Северина Станкева: Лудонаративният дисонанс е много интересно понятие – хем улавя много типичен за игрите проблем, хем ми се струва подвеждащо, доколкото противопоставя лудическите аспекти (онова, което играчът прави в играта, плюс менюта, механики и др.) на наративните, все едно това са различни неща. По този въпрос аз съм съгласна с Еньо Стоянов, който в един ваш разговор¹, както и в други свои текстове² много ясно показва, че лудическото е също разказ, доколкото, много опростено казано, е код, който получава репрезентация вътре в играта. Някои игри се възползват хитроумно от това, за да усилят ефекта от вживяването.

Поредицата „Кредото на убиеца“ (Assassin’s Creed) постоянно прави това. Всички HUD³ елементи (миникарта, посока на движение, точки живот, нива и прочее) тя представя като част от интерфейса на Анимус – машина за виртуална реалност, която позволява да изживееш генетичните спомени на предците си. Тоест по-коректно е да говорим за противоречие или липсата на такова между две нива на повествованието.

Колкото до „Киберпънк“, според мен тя е доста резонантна игра и това, което описваш, е доказателство в тази посока. Фигурата на града е дистопична не въпреки удоволствията му, а именно заради тях, както и придружаващите ги експлоатация, мизерия и страдание. Градът всмуква и омайва персонажа с необятните си възможности за наслаждение и легендарна слава, с образа си (Ги Дебор твърди, че спектакълът подменя действителността с репрезентацията), но омайва и играчa по аналогичен начин – винаги има какво още да се прави, да се види, да се открие. В същото време славата и игралното любопитство реално се състоят в извършването на предимно отвратителни дела, типични за един наемник. В този смисъл мисля, че играта е изключително самосъзнателна и използва пълноценно потенциала на изразните си средства. Един от въпросите ѝ е възможно ли е да се създаде и преживее онова, което Дебор нарича ситуация – живи, автентични моменти, които излизат отвъд пасивната консумация. Дали закованият на кръста все пак не преживява нещо такова?

Миглена Николчина: Аз мисля, че ти отместваш смисъла на собствената си реплика от предишния ни диалог. Концепцията лудонаративен дисонанс ми се вижда интересна, ако минава през лудическото и наративното, а не между тях. Игрите изострено поставят една стара естетическа дилема, която у Боало изглежда така:

Изкуството дори чудовище най-зло
като приятно да представи би могло.

Дилемата тогава е, че забавното може да вземе връх над поучителното… но проблемът е интересен, когато те работят едно срещу друго.

„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс
„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс
„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс
„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс

Кадри от „Киберпънк”

Еньо Стоянов: Моето допускане за обичайния начин, по който се говори за „лудонаративния дисонанс“, както подсказва и Северина, е, че не става въпрос за нещо, което остава външно на наратива. Струва ми се, че не бива да мислим „лудическото“ и „наративното“ като някакви идеални същности, които после лесно се въплъщават съответно в игровата механика и наратива на играта. „Лудическото“ може би не е нищо друго, освен това, че участваме с действия в събитията, които дисплеят на играта показва последователно, тоест които се оказват разказани там за нас покрай участието ни. Тъкмо затова предпочитам да говоря просто за „наративен дисонанс“ при видеоигрите.

Разказът, сюжетостроенето в игрите изобщо, се поема от различни системи, между които може да се породи напрежение. Има аспекти на разгръщащата се по време на игра история, които се контролират от дизайнерите, от техните писатели, те са фиксирани за играча и неподдаващи се на пряка манипулация от неговите действия, позволено му е само евентуално да ги реконтекстуализира смислово. От гледна точка на производството тъкмо тези елементи са наричани твърде рестриктивно „разказ“. Може би тук е по-редно да говорим за „основен сюжет“, „основа наративна ос“ или нещо подобно. Игровата механика е друга система, обособено „перо“ от производствени дейности на дизайнерите, различно от писането, с което те снабдяват играта, което е отворено към действията на играчите, отдаващо им ограничени вариативни възможности за намеса насред тези фиксирани форми⁴.

Но не бива да забравяме, че „действието“ и неговото представяне са ядрото на историческия ни опит за сюжетност поне от времето на Аристотел. Действията, включително тези на играча, но и тези в обичайното ни всекидневие, сa обрамчени от цяла мрежа смислови ориентири, те имат смислов хоризонт: правя х, за да y, та да z и т.н., нещо, което се случва в играенето, дори играта да не контролира еднозначно поведението на играчите с предпоставена за тях цел (в тези случаи те са стимулирани сами да си я набавят). Но действията на играчите, ставащи част от наратива на играта с това, че дисплея им ги „представя“ в самото им извършване, могат да се окажат в смислов разнобой с написаното от дизайнерите.

В „Киберпънк“ основният сюжет предпоставя незаобиколима от играча мотивация за управлявания от него герой – героят е заплашен от изличаване на собственото му аз заради софтуер, който пренаписва психиката му с тази на друг човек, и трябва да се бори за своето оцеляване. Същевременно тази мотивация се разколебава от това, че игровата механика тласка играча към множество разпръснати из света на играта дейности без пряка връзка с този основен сюжет: например разпределените из пространството на града множество полицейски сигнали, съобщаващи за престъпление в ход, в което играчите са индиректно „подканени“ да се намесят, за да го предотвратят. От гледна точка на основния сюжет подобни дейности са разхищения на усилия, подкопаващи собствената му спешност. Центростремителността на основния сюжет се разминава с центробежността на подобни форми на второстепенни интеракции в играта. Доколкото разминаването тук е смислово, то е във наратива на играта. Появява се нещо като сблъсък между два сюжета: в единия имаме герой, който се бори всячески да оживее, в другия – герой, който пренебрегва собственото си оцеляване, занимавайки се с тривиални по своя залог неща.

Редом с това обаче Миглена не без основание настоява на някаква принципна роля на нещо като наслада, подкопаваща самия наративен строеж на игрите. Игровата механика е съвкупност от действия, които са предоставени на играчите, но те са краен брой и обемат по-голямата част от времето на взаимодействие в играта. Затова и дизайнерите се стараят да привилегироват действия, които сами по себе си са приятни дори когото рутинно се повтарят. Когато тези действия се окажат на голяма дистанция от мотивационните смислови структури на основния сюжет, възниква възможност за тяхното изолиране и обособяване от тях. Те стават сякаш автономни, почват настоятелно да вписват своеобразна забрава относно наративните смислови рамки, които иначе ги определят, забрава, която психологически се превръща в нещо като самозабрава в преживяването на играча.

Тоест докато в „Киберпънк“ механично минаваш от един полицейски сигнал към следващия, самият въпрос „Защо моят герой се занимава с това?“ започва да глъхне за сметка на едно наслаждаване в голото повторение и неговите микрозадоволявания. Това, разбира се, може добре да се опише посредством психоаналитичен речник. Но дали това е аспект, произтичащ въз основа на някаква сила на „лудическото“? Не съм сигурен, все пак има игри, развиващи пародиен или абсурдистки основен сюжет, сам подкопаващ възможността за смислова организираност на съвкупността от случвания в играта, например „Притчата за Стенли“ (The Stanley Parable) и игрите от поредицата „Сейнтс Роу“ (Saints Row)⁵. Не бива да забравяме опита от други изкуства – например многобройните форми на литературно писанe, в които езикът от стожер на смислова организация се превръща в самоцелна „игра на означаващото“. Казано иначе, някакво дезинтегриране на наратива може да се въвежда и чрез писането, което влагат самите дизайнери в играта.

„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс
„Киберпънк 2077“. Удоволствие и лудонаративен дисонанс

Кадри от „Киберпънк“

Николай Генов: Дисонансът, предизвикан от употребата на самото понятие за лудонаративен дисонанс, ми се струва любопитен. Вече има и статии, които се стремят да обхванат разнородните интерпретации на термина6. Аз обаче трябва да призная, че в случая се изкушавам да го мисля през един въздействащ пример, защото играта предлага чудесни възможности за това. По-конкретно искам да се спра на споменатата вече от Миглена сюжетна нишка, проследяваща последния ден на Грешника.

Въпросът за автентичността, повдигнат в края на изказването на Северина, е наистина ключов тук. Не знам дали може да се смята за съвпадение7, но в своите добиващи все по-голяма популярност занимания с т.нар. фантоматика (или виртуална реалност) Станислав Лем се спира именно на този казус: може ли изобщо да се пресъздаде по автентичен начин Христовото разпятие в режим на дигитална симулация, или в това, което „Киберпънк“ нарича braindance (и което аз съм склонен да разглеждам като протофантомат). Трудността според полския фантаст би произлязла именно от едно, да го наречем, лудонаративно разминаване: закачката е, че няма да знаем какво да правим с мазохист на кръста.

Джошуа Стивънсън очевидно не е такъв; той е само една матрица, която трябва да произведе добър продукт за консумация. Колко „добър“ ще е този продукт, в случая зависи от степента на синхронизация между вътрешния свят на протагониста и сценария, който той следва. От разговорите и действията на играча резултатите могат да варират в зависимост от това дали Ви успява да разколебае Стивънсън, но това не е толкова важно; по-скоро се спирам на случая, за да насоча вниманието ни към обратния ефект – този на лудонаративната хармонизация, тъй като си мисля, че взаимодействието ѝ с лудонаративния дисонанс по принцип стои в основата на самото игрово преживяване. Краткият разказ за Грешника наративизира тези два аспекта и ни превръща в свидетели на оголването на поне едно тайнство.

(Следва продължение.)

1 Николчина, М., Стоянов, Е. Наратив, алгоритъм и „многодействие“ при видеоигрите. – Във: Видеоигрите. Опасната муза, София: ВС Пъблишинг, 2023, 353–363.

2 Вж. напр. Стоянов, Е. Наратив и алгоритъм при видеоигрите. – Във: Видеоигрите. Опасната муза, София: ВС Пъблишинг, 2023, 88–117.

3 HUD, или Head-up display, се нарича всеки прозрачен дисплей, който предоставя информация, без да е необходимо отместване на погледа.

4 Системата на написаната за играта история и тази на игровата механика не изчерпват мултисистемния ѝ строеж – може да добавим например и т.нар. потребителски интерфейс, който сам може да бъде зададен като част от разказа (да се представя като елемент от света, показван на дисплея) или не.

5 Това са все примери, в които някакво разглобяване на основния сюжет става явно преднамерено. Вероятно бихме могли да намерим безброй примери за непреднамерено вкарване на елементи на абсурд и самопародиране в игровите сюжети на разнородни дизайнери.

6 Вж. например Fantoli, D., Heinz, D., Wetzel, D. Ludonarrative Dissonance and Gamification: A Systematic Literature Review, 2019.

7 Нека не забравяме, че CD Project Red е полско студио, което вече е доказвало, че много добре познава литературните произведения и може да работи с тях.

В рубриката „Игромислие“ публикуваме разговори, в които се срещат, съпоставят и противопоставят различни гледни точки към многоизмерния, многожанров феномен на видеоигрите – не толкова като електронен спорт, колкото като нов синтез на изкуствата и като ново поле на общуване и социалност. 

AWS Weekly Roundup: Claude 4 in Amazon Bedrock, EKS Dashboard, community events, and more (May 26, 2025)

Post Syndicated from Veliswa Boya original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-claude-4-in-amazon-bedrock-eks-dashboard-community-events-and-more-may-26-2025/

As the tech community we continue to have many opportunities to learn and network with other like-minded folks. This past week AWS customers attended the AWS Summit Dubai for an action-packed day featuring live demos, hands-on experiences with cutting-edge AI/ML tools, and more. Right here in South Africa I attended the Data & AI Community in Durban for a day of inspiration and learning from the community. In India, the AWS Community Day Bengaluru brought together hundreds of passionate tech enthusiasts for a day of learning and networking.

Last week’s launches
Here are the launches that got my attention:

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS? page.

Additional updates
Here are some additional projects, blog posts, and news items that you might find interesting:

Upcoming AWS events
Check your calendars and sign up for these upcoming AWS events:

  • AWS Summits – Join free online and in-person events that bring the cloud computing community together to connect, collaborate, and learn about AWS. Register in your nearest city: Tel Aviv (May 28), Singapore (May 29), Stockholm (June 4), Sydney (June 4–5), Washington (June 10-11), and Madrid (June 11).
  • AWS re:Inforce – Mark your calendars for AWS re:Inforce (June 16–18) in Philadelphia, PA. AWS re:Inforce is a learning conference focused on AWS security solutions, cloud security, compliance, and identity.
  • AWS Community Days – Join community-led conferences that feature technical discussions, workshops, and hands-on labs led by expert AWS users and industry leaders from around the world: Milwaukee, USA (June 5), and Nairobi, Kenya (June 14).

That’s all for this week. Check back next Monday for another Weekly Roundup!

– Veliswa.

[$] Development statistics for the 6.15 kernel

Post Syndicated from corbet original https://lwn.net/Articles/1022414/

The 6.14 kernel development cycle only brought in 11,003 non-merge
changesets, making it the slowest cycle since 4.0, which was released in
2015. The 6.15 kernel, instead, brought in 14,612 changesets, making it
the busiest release since 6.7, released at the beginning of 2024. The
kernel development process, in other words, is back up to full speed. The
6.15
release happened on May 25, so the time has come for the
obligatory look at where the changes in this release came from.

Security updates for Monday

Post Syndicated from jake original https://lwn.net/Articles/1022639/

Security updates have been issued by AlmaLinux (389-ds-base, ghostscript, grafana, kernel, and osbuild-composer), Debian (intel-microcode, kernel, libphp-adodb, and openssl), Fedora (dotnet8.0, ghostscript, iputils, nbdkit, open-vm-tools, thunderbird, and vyper), Mageia (chromium-browser-stable, glibc, iputils, microcode, nodejs, and zsync), Oracle (.NET 8.0, .NET 9.0, 389-ds-base, avahi, buildah, compat-openssl11, expat, firefox, ghostscript, gimp, git, grafana, gvisor-tap-vsock, libsoup, libxslt, mod_auth_openidc, nginx, nodejs:20, osbuild-composer, podman, skopeo, thunderbird, vim, webkit2gtk3, xdg-utils, xterm, and yelp), Red Hat (kernel, kernel-rt, libsoup, libsoup3, python-tornado, and ruby), Slackware (ffmpeg), SUSE (audiofile, firefox, glibc, govulncheck-vulndb, grafana, kernel, kind, kubo, libecpg6, postgresql13, postgresql14, python-Django, python-setuptools, python-tornado6, python311-Flask, python311-tornado6, python313, python36-setuptools, thunderbird, transfig, and xen), and Ubuntu (glib2.0, linux-bluefield, linux-ibm, linux-raspi, and openjdk-21-crac).

The collective thoughts of the interwebz