Post Syndicated from jake original https://lwn.net/Articles/1037788/
The VMScape
vulnerability is a Spectre variant that “allows a malicious KVM guest to
“. Greg Kroah-Hartman has announced
leak sensitive information such as encryption/decryption keys from a
userspace hypervisor such as QEMU
the 6.16.7, 6.12.47, 6.6.106, 6.1.152, 5.15.193, and 5.10.244 stable kernels, which add a
mitigation for the hardware bug.
Post Syndicated from Laquie TN Campbell original https://www.backblaze.com/blog/archiving-the-steady-driver-of-media-entertainment-storage/
Industry research consistently shows that archiving and preservation remain the largest drivers of storage demand in media and entertainment workflows. As of 2024, archiving—including both new and historical assets—accounts for the majority of digital storage capacity.
This reflects an ongoing reality: Every production adds new terabytes of content, and studios/vendors are responsible for keeping it safe and usable long-term. And, for many M&E teams, traditional LTO tape libraries represent a cumbersome way to manage vast (and growing) archives.
Increasingly, the decision is less whether to adopt cloud, and more how to use it responsibly. For some, that means hybrid systems that balance performance and scalability. For others, particularly smaller studios, cloud may become the backbone of both active and deep archives.
Cloud media workflows are quick to promise a solution, but it’s more important for you to learn how to navigate. Read our ebook on how to use the cloud to best serve you and your team.
Long-term preservation isn’t a “set-and-forget” task—technology evolves, file formats age, and migration becomes as essential as storage itself. Meanwhile, the shift to 4K, 8K, HDR, and immersive content means productions routinely generate petabytes of material.
The challenge isn’t just volume, but ensuring ongoing integrity, accessibility, and migration compatibility over decades. That makes both current trends in file creation and future-proofing archives an active task.
While the challenge can look different to different types of M&E teams, there are benefits for all of them:
Still, a recent NAB survey showed that archive capacity remains a challenge for 85% of respondents. Searchability is another weak spot, with some teams still relying on spreadsheets.
Although cloud storage offers flexibility, adoption in the M&E industry has been measured. Common concerns include:
The shift from “traditional” production to newer technologies in content filming and creation—including both hardware and software tools—leaves many M&E teams with several, competing demands for their tech stacks. Cloud workflows can offer significant benefits for scalability, searchability, and budget management.
Cloud removes the need for large upfront capital investments and scales as archives grow. For organizations with fluctuating storage needs, this flexibility is particularly valuable.
Cloud services now offer multiple archival tiers—from “hot” to “deep archive”—allowing teams to balance cost with access needs. Combined with lifecycle management policies, this helps align budgets with actual usage.
The most common strategy today is hybrid: keeping frequently accessed assets on-premises or in private cloud, while offloading less active content to public cloud. Surveys show hybrid adoption has grown significantly in the last five years, with expectations that it will continue to rise.
For global teams, cloud improves accessibility. Editors, producers, and marketing teams in different regions can access the same archival assets without relying on physical transfers, VPNs, or duplicated storage.
Cloud platforms also support AI and ML services that enrich metadata. This transforms archives from passive repositories into searchable, discoverable libraries—unlocking new value from existing content.
The move to cloud is gradual, shaped by cost, performance, and workflow realities. Yet the volume and importance of archives—and cloud-based workflows—continue to grow. When paired with thoughtful strategies, cloud storage offers a flexible way to manage that growth while unlocking new creative value.
By designing storage approaches that balance innovation with practicality, M&E teams can ensure archives remain accessible, secure, and ready to support the next generation of storytelling.
The post Archiving: The Steady Driver of Media & Entertainment Storage appeared first on Backblaze Blog | Cloud Storage & Cloud Backup
Post Syndicated from corbet original https://lwn.net/Articles/1037069/
The Git source-code management system stores a lot of information about
changes to code — but it does not hold everything that might be of interest
to a developer who needs to investigate a specific change in the future.
Commits in a repository are the end result of a (sometimes extended)
discussion; often, that discussion will result in changes to the code that
are not explained in the changelog. For some years now, many maintainers
have followed the convention of applying a Link tag to commits that points
back to the mailing-list posting of the change. Linus Torvalds has been
expressing his dislike for this convention for a while, though, and its
time appears to be coming to an end.
Post Syndicated from jake original https://lwn.net/Articles/1037777/
Security updates have been issued by AlmaLinux (python3.12-cryptography), Debian (chromium, hsqldb1.8.0, and imagemagick), Fedora (bustle, cef, maturin, rust-busd, rust-crypto-auditing-agent, rust-crypto-auditing-client, rust-crypto-auditing-event-broker, rust-monitord, rust-monitord-exporter, rustup, tuigreet, and wireshark), Oracle (kernel, microcode_ctl, and python3.12-cryptography), Red Hat (httpd:2.4 and multiple packages), SUSE (coreutils, curl, dpkg, ffmpeg-4, glib2, gnutls, go1.23-openssl, go1.24-openssl, go1.25-openssl, grub2, ImageMagick, jbigkit, kernel, libxslt, Mesa, opensc, opera, perl-JSON-XS, polkit, postgresql16, protobuf, python311, python311-deepdiff, sqlite3, ucode-intel, and warewulf4), and Ubuntu (bind9 and libxml2).
Post Syndicated from Crosstalk Solutions original https://www.youtube.com/watch?v=07ZQJisOt4w
Post Syndicated from The Hook Up original https://www.youtube.com/watch?v=GqvYUjkVONQ
Post Syndicated from corbet original https://lwn.net/Articles/1037703/
The F-Droid project has some
advice for free-software projects on how to deal with takedown
requests.
As part of our legal resilience research, we spoke with a range of
legal experts, software freedom advocates, and maintainers of
mature FOSS infrastructure to understand how others manage these
moments. In this article, we share what we learned, and how F-Droid
is incorporating these lessons into its own approach.
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/shorts/Bur0KeMrv7A
Post Syndicated from Claire Johnson original https://www.raspberrypi.org/blog/promoting-young-peoples-agency-in-the-age-of-ai/
Part of teaching young people AI literacy skills is teaching them to critically think about AI, and to design AI applications that address problems they care about. How to do this was the focus of our June research seminar.
Our June research seminar was delivered by Netta Iivari, Professor in Information Systems at the University of Oulu’s INTERACT Research Unit.
The INTERACT research group focuses on understanding and supporting participatory design, user-centered design, user-driven innovation, and human interaction with technology in everyday life contexts. From this perspective, “users” aren’t considered as passive consumers, but as valuable co-creators and content producers. This calls for different approaches that place emphasis on empowerment and inclusion in designing, shaping, and co-creating information technology in everyday life.
As part of this work, Netta introduced the idea of ‘transformative agency’ — empowering children to believe they can solve problems they care about — and its application in secondary computing education. She showed examples of how to foster young people’s transformative agency within computing, specifically focusing on transdisciplinary approaches to learning about AI and inviting young people to critically analyse and design their futures with AI tools in it.
Netta began by giving an overview of two of the INTERACT Research Unit’s projects:
Netta explained that these projects give young people an opportunity to begin to address the problems they care about, even though they may be very complex problems. From this problem-solving perspective, children are introduced (or ‘sensitised’) to emerging technologies as tools for social good.
She then went on to outline the key pedagogical approaches that underpin these projects:
The projects follow 3 design phases and include a range of plugged and unplugged activities, as shown in Figure 1.
Netta then described in more detail some of the activities that have been used to address these different project phases and the design process involved. For example, to explore what are the problems that children really care about, they are asked to imagine ‘carrying a stone in your pocket for one week, as if it was a magic tool. Where could it be used in your everyday life? What problems could it solve? What problems would you like it to solve and how?’
Young people are then introduced to a range of novel technologies, for example, VR headsets, robots, and emulators of AI-driven social media platforms, such as “Somekone”, developed as part of the Generative AI project at the University of Eastern Finland. They deconstruct and reconstruct generative AI tools by prompting large language model chatbots such as ChatGPT, Gemini, Claude, etc. and exploring bias in their outputs. They perform small-scale algorithmic auditing and create mini language models (with Google Colab), using the text in Alice in Wonderland to train their models, and then open datasets (books as text files from Project Gutenberg). In exploring the responses generated, they experience the potential and the limitations of such tools and gain an important understanding of the human activity involved in the development of AI technologies.
Once they have had this ‘sensitising‘ exposure to a range of tools, they then work in groups on a project that makes use of AI to solve the societal problem they have chosen. These problems could encompass a range of topics, such as racism, animal rights, the impact of AI, war, mental health, bullying. The young people are prompted to think about how large language models can be used to solve the problem, or parts of the problem. But importantly, they are also asked to consider the different motives and perspectives of the multiple stakeholders involved in the problem and its solution and whether their model ideas will create new problems when deployed.
They follow the 3 project phases shown in Figure 1 to design and make a range of digital (robots, apps, videos) and non-digital artefacts to solve their problem. Netta emphasised that although it could take 10 weeks or more to implement all the suggested activities, it is also possible to pick and choose individual tasks from the 3 phases to suit available curriculum timescales.
Other project tasks involve:
These projects situate learning about data-driven technologies in real-world contexts and promote a transdisciplinary approach, teaching and learning about AI from a problem-solving perspective.
This perspective conveys important messages to young people — that they do have agency and can take action in the face of many of the world’s problems, that they can and should be active, critical users of the new technologies that surround them, and that these technologies can be used to change the world for good.
Netta ended the seminar by asking viewers to consider how they could foster transformative agency in the young people they teach and whether or not they consider it to be important in computing education.
Resources relating to the projects can be found at interact.oulu.fi.
In our current seminar series, we’re exploring teaching about AI and data science. Join us at our next seminar on Tuesday 14 October from 17:00 to 18:30 GMT to hear Viktoriya Olari talk about data-related concepts and practices for AI education in K–12.
To sign up and take part, click the button below. We’ll then send you information about joining. We hope to see you there.
The schedule of our upcoming seminars is online. You can catch up on past seminars on our previous seminars page.
The post Promoting young people’s agency in the age of AI appeared first on Raspberry Pi Foundation.
Post Syndicated from Grover Taipe original https://blog.zabbix.com/revolutionizing-zabbix-maintenance-with-artificial-intelligence/31284/
Can you imagine being able to schedule maintenance in Zabbix by simply telling a program: “I need to put the web server in maintenance tomorrow from 8 to 10 with ticket 100-178306”? That’s exactly what the Artificial Intelligence (AI) Scheduler Zabbix project I’ve developed does!
Anyone who has worked with Zabbix knows that scheduling maintenance can sometimes be tedious, especially when you need to:
This project eliminates that friction by allowing the use of natural language to create both one-time and routine maintenance.
Conversational artificial intelligence
The system integrates both OpenAI GPT-4 and Google Gemini to interpret natural language requests. The AI doesn’t just understand what you want to do, but automatically:
Advanced routine maintenance
What really stands out is its ability to handle complex patterns. Here are some practical examples that work:
Elegant architecture
The project uses a three-layer architecture:
One of the best features is how easy it is to get it running:
cp .env.example .env
You only need to configure your Zabbix URL and AI API key:
docker compose up -d --build
And that’s it! You have an AI assistant working.
For organizations with multiple Zabbix servers, the project includes configuration for up to 5 simultaneous instances, each with its own configuration.
Intelligent date detection
The system understands natural expressions like:
Automatic Bitmask management
Zabbix API bitmasks can be notoriously complicated. This system calculates them automatically:
This project represents a natural evolution in systems administration. Instead of memorizing complex syntax or navigating multiple menus, you simply describe what you need in natural language. It’s especially valuable for:
Projects like this demonstrate how artificial intelligence can make complex technical tools more accessible without sacrificing functionality. It’s not just automation – it’s intelligence applied to real infrastructure problems. If you work with Zabbix and are tired of manually configuring maintenance, this project is definitely worth checking out. It’s open source, well documented, and solves a real problem that many of us face every day. You can find the complete project on GitHub.
The post Revolutionizing Zabbix Maintenance with Artificial Intelligence appeared first on Zabbix Blog.
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=e9vawj5xtXo
Post Syndicated from corbet original https://lwn.net/Articles/1036683/
Inside this week’s LWN.net Weekly Edition:
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/shorts/vcXiFQWk7AA
Post Syndicated from Let's Encrypt original https://letsencrypt.org/2025/09/11/native-acme-for-nginx.html
NGINX and Let’s Encrypt share a common vision of an open and secure web. Now, with built-in support for ACME, the world’s most popular web server, reverse proxy and ingress controller for Kubernetes can simplify certificate management for everyone. From the home lab to scaled-out, mission-critical enterprise deployments.
Our ideal has always been that server software could get and renew Let’s Encrypt certificates automatically, with minimal human intervention.
Over time, more and more web servers and hosting environments have become capable of that, often via native ACME and Let’s Encrypt integrations that allow users to manage certificates without third-party tools. On August 12, the popular open source web server NGINX announced support for ACME with their official ngx_http_acme module (implemented with memory safe Rust code!).
NGINX is one of the most widely used pieces of software for operating a web server or proxy. In directly supporting ACME, NGINX joins other web servers like Traefik, Caddy and Apache httpd that can directly take advantage of certificates from Let’s Encrypt and other ACME Certificate Authorities. NGINX’s new support for ACME, together with other servers, means a significant majority of sites can now have native ACME support. Many other software environments, hosting plans, and devices also offer built-in official support for ACME.
Users have a wide range of choices to achieve integrations for their particular hosting environments. Native support in web servers is an option alongside third-party clients that can integrate with many of those same web servers. Native support typically provides more seamless integration, and it’s less work for operators since they don’t have to manage a separate ACME client. Having more tools that take care of certificates automatically helps us achieve our goal of encrypting more and more of the web, while reducing the amount of time and energy site operators have to spend.
Other project developers interested in integrating ACME more directly can read about the ACME protocol, find existing ACME library implementations and other reusable software components, and join the Client Dev conversation on our Community Forum.
We’d like to thank NGINX and their parent company, F5, for their sponsorship of Let’s Encrypt. This financial support helps us provide a trusted and reliable service to nearly 700 million websites.
Post Syndicated from Mahak Arora original https://aws.amazon.com/blogs/compute/disa-stig-for-amazon-linux-2023-is-now-available/
Today, we announce the availability of a Security Technical Implementation Guide (STIG) for Amazon Linux 2023 (AL2023), developed through collaboration between Amazon Web Services (AWS) and the Defense Information Systems Agency (DISA). The STIG guidelines are important for U.S Department of Defense (DOD) and Federal customers needing strict security compliance derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. This new technical implementation guide provides detailed Operating System (OS) security hardening configurations for organizations deploying AL2023 in DOD environments and other agencies requiring DISA STIG alignment. The AL2023 STIG provides customers with access to an OS guide that complies with stringent government security standards. This guide for implementing STIG configurations will streamline security processes for organizations seeking robust cybersecurity controls, whether they are needed to maintain DOD compliance or voluntarily adopting these best security practices to enhance their security posture.
Implementing the AL2023 DISA STIG with AWS
AWS Systems Manager (SSM) and EC2 Image builder offer native solutions for implementing the AL2023 DISA STIG configurations in your environment. For customers with existing AL2023 EC2 workload, they can utilize AWS Systems Manger (SSM) to streamline the STIG implementation. For customers who would like to build STIG compliant AL2023 EC2 instances to use for deployment, they can utilize EC2 Image Builder and automate the application of the AL2023 DISA STIG.
Customers can utilize EC2 Image builder to enhance and streamline their implementation of the AL2023 DISA STIG. This integrated approach significantly reduces the operational overhead traditionally associated with maintaining STIG compliance. Therefore, our customers can focus on their core missions while maintaining the highest security standards. Our customers can use AWS EC2 Image Builder’s existing Linux hardening components, which now support AL2023 Category I, II, and III findings to automatically create STIG-compliant AL2023 EC2 images with minimal manual intervention. This automation significantly reduces the time and effort typically needed for security hardening implementations. The EC2 Image Builder Linux hardening component extends its proven capabilities to AL2023, providing the same streamlined security configuration process available for other Linux distributions. For more information, refer to the Image Builder documentation.
Automating the STIG for Existing Fleets via Systems Manager
For existing AL2023 EC2 instances, you can use AWS-managed SSM command documents to automate the implementation of the STIG configurations. . These command documents can be executed through the SSM console, API, or AWS Command Line Interface (AWS CLI). The key mechanism here is the AWS managed Systems Manager command document, which contains the pre-defined STIG configurations. By leveraging these command documents through Systems Manager execution capabilities, customers can systematically deploy and maintain AL2023 STIG configurations across their fleet of EC2 instances. This generates consistent security baselines that meet government and enterprise requirements. This solution is particularly effective for environments with existing AL2023 EC2 instances as it allows customers to implement STIG controls without rebuilding or redeploying instances. For more information about the command document, refer to Apply STIG settings with Systems Manager in the EC2 User Guide.
The AL2023 STIG represents the continued commitment of Amazon Linux to providing customers with the security tools and guidance they need to succeed in highly regulated environments. Amazon Linux, in collaboration with DISA is providing their customers with access to authoritative, government-validated security configurations that meet the most demanding compliance requirements.
Ready to implement AL2023 STIG in your environment? Explore our comprehensive documentation and begin streamlining your security compliance journey today. To learn more about STIG hardening for your EC2 instances, refer to STIG compliance for your EC2 instance and for STIG settings that are applied to EC2 Linux instances, refer to the STIG settings for EC2 Linux instances. To apply STIG settings to your AL 2023 EC2 instance, download the AL2023 DISA STIG.
Post Syndicated from Lakshmi VP original https://aws.amazon.com/blogs/security/overview-of-security-services-available-in-aws-dedicated-local-zones/
When modernizing applications, customers in regulated industries like government, financial, and research face a critical challenge: how to transform their systems while meeting strict digital sovereignty and security compliance requirements. A common misconception tied to this is that data must be moved to an AWS Region to fully use Amazon Web Services (AWS) security services.
In this blog post, we dispel that misconception by addressing how to use the following Region-based AWS security services while keeping your data within AWS Dedicated Local Zones.
Dedicated Local Zones are AWS-managed on-premises infrastructure configured for your exclusive use. They help meet specific regulatory requirements while providing cloud benefits such as elasticity, scalability, and pay-as-you-grow pricing. You can place data in your chosen location and use it with enhanced security and governance features provided by AWS to monitor and control application access while maintaining data isolation, in-country data residency, digital sovereignty, and meeting compliance requirements.
Many organizations with strict compliance and data sovereignty requirements are understandably hesitant about moving confidential workloads to the cloud. Their concerns are legitimate and specific: they need a solution that provides independently verifiable protection and isolation from data access by privileged parties, including cloud provider personnel. These organizations also require assurance that unauthorized data access through the cloud control plane is technically impossible, not just contractually prohibited.
Perhaps most critically, they need side-channel protection to help make sure that sensitive data cannot leak through memory or other means to other hypervisor tenants sharing the same physical infrastructure. Traditional cloud security approaches often rely on operational controls and promises rather than technical impossibility, which doesn’t meet the stringent requirements these organizations face.
The AWS Nitro System, which is the foundation of AWS next generation Amazon Elastic Compute Cloud (Amazon EC2) instances that run in a Dedicated Local Zone and its parent Region, addresses each of these concerns through its architecture. This purpose-built combination of specialized hardware and software creates a secure enclave that shields your data from unauthorized access during processing on EC2 instances.
The EC2 instances that run in your Dedicated Local Zones are based on AWS Nitro System, which is designed to provide robust security for compute workloads. It uses specialized hardware and software components to help protect your data from unauthorized access during processing on Amazon EC2.
The three key components of Nitro System include a purpose-built Nitro cards, the Nitro Security Chip, and a Nitro Hypervisor. Together, these three components are designed to enforce restrictions and provide physical and logical security boundaries so that no one, including AWS employees, can access customer workloads or data running on Amazon EC2 without your explicit authorization.
The Nitro System whitepaper details how the Nitro System, by design, removes the possibility of administrator access to an EC2 instance, the overall passive communications design of the Nitro System, and the Nitro System change management process. The security design of the Nitro System has also been independently validated by the NCC Group in a public report.
Working with customers, we’ve noticed that one of the most persistent sources of confusion and concern isn’t just about whether their data is encrypted, but about who controls the keys that protect that encryption. Many organizations struggle with a fundamental tension: they want the operational benefits of cloud computing, but they also need to maintain strict control over their encryption keys to meet compliance requirements.
This concern is particularly acute for organizations in regulated industries, which often ask pointed questions like “Where exactly are my encryption keys stored?” and “Who can access my keys?” AWS KMS addresses this by offering multiple approaches to key management, each designed for different security and operational requirements. The service provides centralized control over the lifecycle and permissions of encryption keys, so you can create new keys whenever needed and control key management access separate from key policies
By default, Dedicated Local Zones customers can use the integration with AWS KMS in the parent Region to store and control encryption keys. You can then use these encryption keys to encrypt your data stored locally in Amazon EBS, and Amazon S3 in the Dedicated Local Zones.
If your use cases require an external encryption key store to maintain strict data sovereignty requirements, then the combination of Dedicated Local Zones and an AWS KMS external key store can provide a robust solution.
Using an external key store in Dedicated Local Zones, you can host the external hardware security module (HSM) that stores your encryption keys on-premises or colocated with your other infrastructure. By doing this, you maintain full control over the physical security and management of the HSM, while benefiting from the low-latency access and data processing capabilities of Dedicated Local Zones.
The main components of AWS KMS external key store architecture are:
Figure 1: AWS KMS external key store in a Dedicated Local Zone
The workflow is as follows:
Note: The on-premises HSM only participates in the initial root key generation to protect the data encryption key, not in the high-volume encrypt/decrypt operations on the data itself.
This architecture delivers two key benefits:
It’s important to note that using an AWS KMS external key store requires you to manage additional operational tasks beyond standard AWS KMS. To maintain continuous access to your encrypted data, you must provide 24/7 availability of your on-premises HSM, monitor XKS proxy infrastructure performance, implement robust security controls, and create backup and recovery procedures.
Because system outages can prevent access to your encrypted data, we recommend that you develop detailed operational runbooks, set up comprehensive monitoring, test your recovery procedures regularly, and maintain redundant systems where possible.
For more information about the interactions between AWS KMS and the external key store, see Announcing AWS KMS External Key Store (XKS).
Another common concern we hear from organizations evaluating Dedicated Local Zones is whether they’ll need to compromise on security capabilities to maintain data residency. The reality is that AWS security services running in a Region, such as Amazon Inspector, are specifically designed to provide comprehensive protection while respecting your data location requirements.
Organizations running regulated applications in Dedicated Local Zones require robust protection from zero-day vulnerabilities, prioritized patch remediation, and automated vulnerability management to meet compliance requirements. Amazon Inspector addresses these needs by continuously scanning your workloads to detect software vulnerabilities and unintended network exposure without requiring data movement from your chosen location.
Amazon Inspector helps protect your workloads through two distinct scanning modes: hybrid scanning and agent-based scanning. However, for the context of this blog, let’s consider only agent-based scanning mode.
To securely meet data residency requirements in Dedicated Local Zones, enable agent-based scanning mode on AWS Systems Manager (AWS SSM)-managed instances in your account. It’s the default mode for new accounts offering enhanced security through continuous scanning, immediately responding to new common vulnerabilities and exposures (CVEs) and instance changes. It also enables deep inspection capabilities for eligible instances, providing comprehensive vulnerability assessment.
The reference architecture in Figure 2 shows:
Figure 2: Amazon Inspector in Dedicated Local Zones
Maintaining data sovereignty with Dedicated Local Zones doesn’t mean sacrificing advanced security capabilities. GuardDuty demonstrates how sophisticated threat detection can operate effectively while honoring strict data residency requirements.
Protecting your AI workloads from ransomware and advanced security threats requires an AI and machine learning (AL/ML)-integrated threat intelligence solution that can detect suspicious activity and respond proactively. GuardDuty uses AI/ML-based threat detection and integrated threat intelligence from AWS and leading third parties to protect your AWS accounts, workloads, and data. It continuously monitors malicious activity, delivers detailed security findings, and you can use the information it provides to respond quickly to threats.
With GuardDuty EKS Protection, monitors Kubernetes audit logs to detect threats. The key point to note is that your data is stored in your chosen location and the parent Region only processes log data.
GuardDuty Runtime Monitoring observes and analyzes operating system, networking, and file events to detect potential threats in your AWS workloads. The parent Region receives only threat reports while Dedicated Local Zones retain your data.
The reference architecture in Figure 3 shows how GuardDuty helps protect your data in a Dedicated Local Zones:
Figure 3: Amazon GuardDuty in Dedicated Local Zones
Organizations frequently express concern about certificate management complexity when deploying applications in Dedicated Local Zones. AWS Certificate Manager (ACM), which operates in the parent Region, addresses these challenges by serving as the primary service that customers use to provision, manage, and deploy certificates for use in both public-facing and private Dedicated Local Zones workloads.
ACM integrates seamlessly with ALBs in Dedicated Local Zones to manage your complete certificate lifecycle, as shown in Figure 4.
Figure 4: ACM in Dedicated Local Zones
Follow these steps to implement TLS certificates in Dedicated Local Zones:
ACM renews certificates automatically, avoids manual management tasks, and maintains continuous HTTPS service availability. This integration delivers enterprise-grade security with your data residing locally in Dedicated Local Zones. It also provides enhanced performance and reduced latency through proximity to users.
Business-critical applications in Dedicated Local Zones need maximum availability and responsiveness. AWS Shield Standard, a managed distributed denial of service (DDoS) protection service that runs at the AWS edge, automatically helps protect your applications by detecting and mitigating network (Layer 3) and transport (Layer 4) DDoS attacks even before they reach your workloads.
A common concern when deploying workloads in Dedicated Local Zones is whether organizations can maintain the same level of governance and compliance oversight they expect from traditional AWS deployments. CloudTrail demonstrates how comprehensive auditing capabilities can extend seamlessly across distributed infrastructure while respecting data residency requirements.
CloudTrail, running in the parent Region, enables governance, compliance, operational auditing, and risk auditing of your AWS account providing you aggregated and consolidated record of multisource events in a single place. This includes a detailed history of AWS API calls for your account, including API calls made using the AWS Management Console, the AWS SDKs, the command line tools, and higher-level AWS services used by the applications running in your Dedicated Local Zones. Only the logs are stored in the parent Region, while your data remains within the Dedicate Local Zones. AWS CloudTrail helps you to enable operational and risk auditing, governance, and compliance of your AWS accounts.
Dedicated Local Zones provide a robust solution for running regulated workloads for all industries, to meet strict data residency and digital sovereignty. Through integrated security services like AWS Nitro System, AWS KMS External Key Store, ACM, AWS Shield, Amazon GuardDuty, Amazon Inspector, and AWS CloudTrail, your organization can achieve stronger security compliance for their mission-critical applications running in AWS Dedicated Local Zones.
To learn more about implementing these security solutions in your Dedicated Local Zones deployment, contact your AWS account team.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Post Syndicated from Rohit Kumar original https://www.servethehome.com/vimin-vm-s251602p-16-port-2-5g-poe-switch-review-cyperf/
In our Vimin VM-S251602P PoE+ switch review, we found something important in this fanless, cheap, 16-port 2.5GbE and 2-port 10G switch
The post Vimin VM-S251602P 16-Port 2.5GbE PoE with 2x 10G Switch Review appeared first on ServeTheHome.
Post Syndicated from Natalie White original https://aws.amazon.com/blogs/devops/aws-cloud-development-kit-cdk-launches-refactor/
We are excited to announce a new AWS Cloud Development Kit (CDK) feature that makes it easier and safer to refactor your infrastructure as code. CDK Refactor aims to preserve your AWS resources as you rename constructs, move resources between stacks, and reorganize your CDK applications – operations that previously risked resource replacement.
When writing infrastructure as code with the CDK, developers occasionally need to rename Constructs or move them between Stacks or directories. Whether they need to better organize their code, adhere to coding best practices, or take advantage of object-oriented programming patterns like class inheritance, these changes can be risky in environments with deployed resources, because they change the CDK-generated logical ID of those resources. During a CDK deploy, AWS CloudFormation interprets these changes as new resources, which often requires deletion of the existing resource and creation of a new resource with the new logical ID. For stateful resources, this could cause potential downtime and even data loss. To mitigate this effect of ID changes, developers had to stage their changes to create new resources, create a data or network migration plan, and then delete the old resources to prevent these refactoring effects. Sometimes, developers decide the risk of these changes outweigh the benefit of the refactor and choose not perform the refactor at all.
Today, developers can use the new CDK refactor command to detect, review, confirm, and safely apply refactored changes to their resources without resource replacement. This feature leverages the recently-launched AWS CloudFormation refactor feature, but the CDK automatically computes the mappings that CloudFormation needs to redefine the refactored resources, providing a layer of abstraction that allows developers to focus on code rather than resource configuration. Let’s walk through an example to demonstrate the benefits of this refactor capability.
Prerequisites
Along with the usual CDK prerequisites, if you bootstrapped your CDK project before this launch, you need to re-bootstrap your environment to obtain the new permissions associated with the CDK refactor capabilities before attempting your refactor.
Monolith to micro-service example
For this example, let’s say that we have a legacy CDK App that deploys a monolithic Stack with Amazon DynamoDB tables for users, products, and orders, and an AWS Lambda function that implements CRUD operations on all entities.
Monolithic application
function monolithApp() {
const monolith = new CdkAppStack(app, monolithStackName, {env});
const usersTable = makeTable(monolith, 'users');
const productsTable = makeTable(monolith, 'products');
const ordersTable = makeTable(monolith, 'orders');
// We have a single Lambda function in our application
const func = new Function(monolith, `MonolithFunction`, {
code: Code.fromInline(`Some code that accesses all three tables`),
runtime: Runtime.NODEJS_22_X,
handler: 'index.handler',
});
usersTable.grantReadWriteData(func);
productsTable.grantReadWriteData(func);
ordersTable.grantReadWriteData(func);
// This function creates a REST API, resources, methods, and links
// everything together to the functions. Right now, we are passing
// the same function in three places.
makeApi(monolith, {
usersFunction: func,
productsFunction: func,
ordersFunction: func,
});
}
monolithApp();We’ve been asked to adhere to Well Architected Framework best practices and break up the monolith into separate Lambda functions so they can scale independently. Because they’re so similar, we’re also going to create an inheritable Lambda class that we can reuse to improve readability and maintainability of the code, and avoid having to re-define Lambda configuration settings that are consistent across all of the functions.
Finally, the monolith uses only L1 CDK Constructs. To further abstract our code and take advantage of helper functions, we’re going to start using L2 CDK Constructs for DynamoDB, Lambda, and API Gateway. This change will allow the IAM Roles and permissions to be defined automatically, further simplifying our code.
Proposed refactored application into separate stacks for each domain.
Without the refactor feature, CloudFormation would delete and re-create the Lambda and DynamoDB resources, which would cause all of the data in the latter to be lost. Alternatively, you could create net-new Lambdas and Amazon DynamoDB tables in one deployment, execute an out-of-band, point-in time and streaming data migration from the old tables to the new ones, update the API Gateway configuration to target the new Lambdas in a second deploy, and turn off the streaming migration process.
With the refactor feature, we can move the resource definitions to new files, update them to L2 Constructs, and leave the stateful resources in place!
Replace stateless resources
First, let’s refactor our CDK code to break the monolithic Lambda into 3 domain-specific Lambdas. CloudFormation’s refactor capability doesn’t support creating new resources or updating configuration of existing resources, so we will deploy these changes as usual, without using the new refactor feature. All resources will stay inside the monolithic stack for now.
Refactor stateless single lambda function into 3 functions as a prerequisite to the refactor of stateful DynamoDB tables.
function singleStackMicroservicesApp() {
// We still have a single stack
const monolith = new CdkAppStack(app, monolithStackName, {env});
// makeFunctionAndTable creates a different Lambda function and a DynamoDB table
// for each domain that is passed as a parameter.
// In a real CDK application, you would probably define each of them independently.
makeApi(monolith, {
usersFunction: makeFunctionAndTable(monolith, 'users'),
productsFunction: makeFunctionAndTable(monolith, 'products'),
ordersFunction: makeFunctionAndTable(monolith, 'orders'),
});
}
singleStackMicroservicesApp();Refactor stateful resources
Now we can refactor the stateful DynamoDB tables and their respective Lambdas to their own stacks, using cdk refactor to map their new IDs without replacing the resources.
Before refactoring, though, we need to create the new stacks that will receive the functions and tables:
singleStackMicroservicesApp();
const usersStack = new Stack(app, 'Users', {env});
const productsStack = new Stack(app, 'Products', {env});
const ordersStack = new Stack(app, 'Orders', {env});Refactored Lambda functions and DynamoDB tables into their own separate stacks.
function fullMicroservicesApp() {
const monolith = new Stack(app, monolithStackName, {env});
const usersStack = new Stack(app, 'Users', {env});
const productsStack = new Stack(app, 'Products', {env});
const ordersStack = new Stack(app, 'Orders', {env});
makeApi(monolith, {
// Now each pair function + table is in its own stack
usersFunction: makeFunctionAndTable(usersStack, 'users'),
productsFunction: makeFunctionAndTable(productsStack, 'products'),
ordersFunction: makeFunctionAndTable(ordersStack, 'orders'),
});
}
fullMicroservicesApp();Running cdk refactor –unstable=refactor starts the process. (The unstable flag is required as this feature is still subject to breaking changes.) The CDK will compare the current state of your application (the deployed monolithic app) with the new state (the output of your refactored CDK application).
CDK refactor confirmation dialog
As expected, it shows a table of resources that were moved from the Monolith stack to their respective refactored stacks. By default, the CLI asks for confirmation before proceeding. Bypass the confirmation by passing the –force flag, or confirm the changes and execute the refactor:
All resources, including the stateful tables, were safely moved to other stacks, and we now have our well-architected application.
CDK refactor results
Conclusion
With the CDK refactor feature, developers can take full advantage of the object-oriented definition of AWS resources, including the ability to change the structure and layers of abstraction without orchestrating complex migration mechanisms or scheduled downtime. Since the CDK is open source, you can learn more about how the CDK automatically determines what resources need to be refactored via the README. Understanding when resources need to be replaced and refactored will help you plan your infrastructure as code roadmap and when you should use this new refactoring capability.
If you’ve got a refactor that you’ve been waiting to execute, read more about the feature set in the CDK refactor documentation and start refactoring your own CDK App today!
Authors
Post Syndicated from Felix John original https://aws.amazon.com/blogs/big-data/build-a-streaming-data-mesh-using-amazon-kinesis-data-streams/
Organizations face an ever-increasing need to process and analyze data in real time. Traditional batch processing methods no longer suffice in a world where instant insights and immediate responses to market changes are crucial for maintaining competitive advantage. Streaming data has emerged as the cornerstone of modern data architectures, helping businesses capture, process, and act upon data as it’s generated.
As customers move from batch to real-time processing for streaming data, organizations are facing another challenge: scaling data management across the enterprise, because the centralized data platform can become the bottleneck. Data mesh for streaming data has emerged as a solution to address this challenge, building on the following principles:
A streaming mesh applies these principles to real-time data movement and processing. This mesh is a modern architectural approach that enables real-time data movement across decentralized domains. It provides a flexible, scalable framework for continuous data flow while maintaining the data mesh principles of domain ownership and self-service capabilities. A streaming mesh represents a modern approach to data integration and distribution, breaking down traditional silos and helping organizations create more dynamic, responsive data ecosystems.
AWS provides two primary solutions for streaming ingestion and storage: Amazon Managed Streaming for Apache Kafka (Amazon MSK) or Amazon Kinesis Data Streams. These services are key to building a streaming mesh on AWS. In this post, we explore how to build a streaming mesh using Kinesis Data Streams.
Kinesis Data Streams is a serverless streaming data service that makes it straightforward to capture, process, and store data streams at scale. The service can continuously capture gigabytes of data per second from hundreds of thousands of sources, making it ideal for building streaming mesh architectures. Key features include automatic scaling, on-demand provisioning, built-in security controls, and the ability to retain data for up to 365 days for replay purposes.
A streaming mesh can deliver the following benefits:
The following personas have distinct responsibilities in the context of a streaming mesh:
The streaming mesh establishes a common platform that enables seamless collaboration between producers, consumers, and governance teams. By clearly defining responsibilities and providing self-service capabilities, it removes traditional integration barriers while maintaining security and compliance. This approach helps organizations break down data silos and achieve more efficient, flexible data utilization across the enterprise.A streaming mesh architecture consists of two key constructs: stream storage and the stream processor. Stream storage serves all three key personas—governance, producers, and consumers—by providing a reliable, scalable, on-demand platform for data retention and distribution.
The stream processor is essential for consumers reading and transforming the data. Kinesis Data Streams integrates seamlessly with various processing options. AWS Lambda can read from a Kinesis data stream through event source mapping, which is a Lambda resource that reads items from the stream and invokes a Lambda function with batches of records. Other processing options include the Kinesis Client Library (KCL) for building custom consumer applications, Amazon Managed Service for Apache Flink for complex stream processing at scale, Amazon Data Firehose, and more. To learn more, refer to Read data from Amazon Kinesis Data Streams.
This combination of storage and flexible processing capabilities supports the diverse needs of multiple personas while maintaining operational simplicity.
When building a streaming mesh, you should consider data ingestion, governance, access control, storage, schema control, and processing. When implementing the components that make up the streaming mesh, you must properly address the needs of the personas defined in the previous section: producer, consumer, and governance. A key consideration in streaming mesh architectures is the fact that producers and consumers can also exist outside of AWS entirely. In this post, we examine the key scenarios illustrated in the following diagram. Although the diagram has been simplified for clarity, it highlights the most important scenarios in a streaming mesh architecture:
Building a streaming mesh on a self-managed streaming solution that facilitates internal and external sharing can be challenging because producers and consumers require the appropriate service discovery, network connectivity, security, and access control to be able to interact with the mesh. This can involve implementing complex networking solutions such as VPN connections with authentication and authorization mechanisms to support secure connectivity. In addition, you must consider the access pattern of the consumers when building the streaming mesh.The following are common access patterns:
The following diagram illustrates these access patterns.
When building a streaming mesh that involves internal and external sharing, you can use Kinesis Data Streams. This service offers a built-in API layer that deliver secure and highly available HTTP/S endpoints accessible through the Kinesis API. Producers and consumers can securely write and read from the Kinesis Data Streams endpoints using the AWS SDK, the Amazon Kinesis Producer Library (KPL), or Kinesis Client Library (KCL), alleviating the need for custom REST proxies or additional API infrastructure.
Security is inherently integrated through AWS Identity and Access Management (IAM), supporting fine-grained access control that can be centrally managed. You can also use attribute-based access control (ABAC) with stream tags assigned to Kinesis Data Streams resources for managing access control to the streaming mesh, because ABAC is particularly helpful in complex and scaling environments. Because ABAC is attribute-based, it enables dynamic authorization for data producers and consumers in real time, automatically adapting access permissions as organizational and data requirements evolve. In addition, Kinesis Data Streams provides built-in rate limiting, request throttling, and burst handling capabilities.
In the following sections, we revisit the previously mentioned common access patterns for consumers in the context of a streaming mesh and discuss how to build the patterns using Kinesis Data Streams.
Kinesis Data Stream has built-in support for the shared data access with replay pattern. The following diagram illustrates this access pattern, focusing on same-account, cross-account, and external consumers.
When you create your data mesh with Kinesis Data Streams, you should create a data stream with the appropriate number of provisioned shards or on-demand mode based on your throughput needs. On-demand mode should be considered for more dynamic workloads. Note that message ordering can only be guaranteed at the shard level.
Configure the data retention period of up to 365 days. The default retention period is 24 hours and can be modified using the Kinesis Data Streams API. This way, the data is retained for the specified retention period and can be replayed by the consumers. Note that there is an additional fee for long-term data retention fee beyond the default 24 hours.
To enhance network security, you can use interface VPC endpoints. They make sure the traffic between your producers and consumers residing in your virtual private cloud (VPC) and your Kinesis data streams remain private and don’t traverse the internet. To provide cross-account access to your Kinesis data stream, you can use resource policies or cross-account IAM roles. Resource-based policies are directly attached to the resource that you want to share access to, such as the Kinesis data stream, and a cross-account IAM role in one AWS account delegates specific permissions, such as read access to the Kinesis data stream, to another AWS account. At the time of writing, Kinesis Data Streams doesn’t support cross-Region access.
Kinesis Data Streams enforces quotas at the shard and stream level to prevent resource exhaustion and maintain consistent performance. Combined with shard-level Amazon CloudWatch metrics, these quotas help identify hot shards and prevent noisy neighbor scenarios that could impact overall stream performance.
You can build producer applications using the AWS SDK or the KPL. Using the KPL can facilitate the writing because it provides built-in functions such as aggregation, retry mechanisms, pre-shard rate limiting, and increased throughput. The KPL can incur an additional processing delay. You should consider integrating Kinesis Data Streams with the AWS Glue Schema Registry to centrally control discover, control, and evolve schemas and make sure produced data is continuously validated by a registered schema.
You must make sure your producers can securely connect to the Kinesis API whether from inside or outside the AWS Cloud. Your producer can potentially live in the same AWS account, across accounts, or outside of AWS entirely. Typically, you want your producers to be as close as possible to the Region where your Kinesis data stream is running to minimize latency. You can enable cross-account access by attaching a resource-based policy to your Kinesis data stream that grants producers in other AWS accounts permission to write data. At the time of writing, the KPL doesn’t support specifying a stream Amazon Resource Name (ARN) when writing to a data stream. You must use the AWS SDK to write to a cross-account data stream (for more details, see Share your data stream with another account). There are also limitations for cross-Region support if you want to produce data to Kinesis Data Streams from Data Firehose in a different Region using the direct integration.
To securely access the Kinesis data stream, producers need valid credentials. Credentials should not be stored directly in the client application. Instead, you should use IAM roles to provide temporary credentials using the AssumeRole API through AWS Security Token Service (AWS STS). For producers outside of AWS, you can also consider AWS IAM Roles Anywhere to obtain temporary credentials in IAM. Importantly, only the minimum permissions that are required to write the stream should be granted. With ABAC support for Kinesis Data Streams, specific API actions can be allowed or denied when the tag on the data stream matches the tag defined in the IAM role principle.
You can build consumers using the KCL or AWS SDK. The KCL can simplify reading from Kinesis data streams because it automatically handles complex tasks such as checkpointing and load balancing across multiple consumers. This shared access pattern can be implemented using standard as well as enhanced fan-out consumers. In the standard consumption mode, the read throughput is shared by all consumers reading from the same shard. The maximum throughput for each shard is 2 MBps. Records are delivered to the consumers in a pull model over HTTP using the GetRecords API. Alternatively, with enhanced fan-out, consumers can use the SubscribeToShard API with data pushed over HTTP/2 for lower-latency delivery. For more details, see Develop enhanced fan-out consumers with dedicated throughput.
Both consumption methods allow consumers to specify the shard and sequence number from which to start reading, enabling data replay from different points within the retention period. Kinesis Data Streams recommends to be aware of the shard limit that is shared and use fan-out when possible. KCL 2.0 or later uses enhanced fan-out by default, and you must specifically set the retrieval mode to POLLING to use the standard consumption model. Regarding connectivity and access control, you should closely follow what is already suggested for the producer side.
Although Kinesis Data Streams doesn’t provide built-in filtering capabilities, you can implement this pattern by combining it with Lambda or Managed Service for Apache Flink. For this post, we focus on using Lambda to filter messages.
Governance and producer personas should follow the best practices already defined for the shared data access with replay pattern, as described in the previous section.
You should create a Lambda function that consumes (shared throughput or dedicated throughput) from the stream and create a Lambda event source mapping with your filter criteria. At the time of writing, Lambda supports event source mappings for Amazon DynamoDB, Kinesis Data Streams, Amazon MQ, Managed Streaming for Apache Kafka or self-managed Kafka, and Amazon Simple Queue Service (Amazon SQS). Both the ingested data records and your filter criteria for the data field must be in a valid JSON format for Lambda to properly filter the incoming messages from Kinesis sources.
When using enhanced fan-out, you configure a Kinesis dedicated-throughput consumer to act as the trigger for your Lambda function. Lambda then filters the (aggregated) records and passes only those records that meet your filter criteria.
When distributing streaming data to multiple subscribers without the ability to replay, Kinesis Data Streams supports an intermediary pattern that’s particularly effective for web and mobile clients needing real-time updates. This pattern introduces an intermediary service to bridge between Kinesis Data Streams and the subscribers, processing records from the data stream (using a standard or enhanced fan-out consumer model) and delivering the data records to the subscribers in real time. Subscribers don’t directly interact with the Kinesis API.
A common approach uses GraphQL gateways such as AWS AppSync, WebSockets API services like the Amazon API Gateway WebSockets API, or other suitable services that make the data available to the subscribers. The data is distributed to the subscribers through networking connections such as WebSockets.
The following diagram illustrates the access pattern of fan-out to subscribers without replay. The diagram displays the managed AWS services AppSync and API Gateway as intermediary consumer options for illustration purposes.
Governance and producer personas should follow the best practices already defined for the shared data access with replay pattern.
This consumption model operates differently from traditional Kinesis consumption patterns. Subscribers connect through networking connections such as WebSockets to the intermediary service and receive the data records in real time without the ability to set offsets, replay historical data, or control data positioning. The delivery follows at-most-once semantics, where messages might be lost if subscribers disconnect, because consumption is ephemeral without persistence for individual subscribers. The intermediary consumer service must be designed for high performance, low latency, and resilient message distribution. Potential intermediary service implementations range from managed services such as AppSync or API Gateway to custom-built solutions like WebSocket servers or GraphQL subscription services. In addition, this pattern requires an intermediary consumer service such as Lambda that reads the data from the Kinesis data stream and immediately writes it to the intermediary service.
This post highlighted the benefits of a streaming mesh. We demonstrated why Kinesis Data Streams is particularly suited to facilitate a secure and scalable streaming mesh architecture for internal as well as external sharing. The reasons include the service’s built-in API layer, comprehensive security through IAM, flexible networking connection options, and versatile consumption models. The streaming mesh patterns demonstrated—shared data access with replay, message filtering, and fan-out to subscribers—showcase how Kinesis Data Streams effectively supports producers, consumers, and governance teams across internal and external boundaries.
For more information on how to get started with Kinesis Data Streams, refer to Getting started with Amazon Kinesis Data Streams. For other posts on Kinesis Data Streams, browse through the AWS Big Data Blog.
Post Syndicated from daroc original https://lwn.net/Articles/1034811/
There are a large number of ways to configure the 6.16
Linux kernel. It has 32,468 different configuration options on x86_64,
and a comparable number for other platforms. Exploring the ways the kernel can
be configured is sufficiently difficult that it requires specialized tools.
These show the
number of possible configurations that options can be combined in has
6,550 digits. How has that number changed over the history of the kernel, and
what does it mean for testing?