The cost of saying yes has changed

Post Syndicated from Dalia Abuadas original https://github.blog/engineering/the-cost-of-saying-yes-has-changed/


The most expensive part of a small feature request used to be writing the code. Now it’s usually the meeting about whether or not to write the code.

That’s a real shift, and it quietly breaks a lot of engineering instincts. Engineers learn early that most “small asks” aren’t small: they need tests, a rollout plan, someone to think through the edge cases and own the behavior after it ships. A two-hour change can become a two-week distraction if it touches the wrong part of the system. So we push back. Is this really needed? Does it belong in this release? Does it change a contract we already agreed to? I’m not giving that instinct up.

But it rests on an assumption that’s quietly breaking, which is that writing the first version of the code is the expensive step. For a specific class of change, it no longer is. If you can tell those changes apart from the rest, you can replace “is this in scope?” with a question you can answer in thirty minutes instead of a two-day debate.

The debate often costs more than the patch

Here’s a pattern I keep seeing. Someone asks for a small change such as surfacing a last_active_at timestamp that already exists in the backend on a settings page. The team spends forty minutes in a thread. One person says it sounds risky. Someone remembers a related migration from two years ago. Someone mentions the deadline. Eventually we land on “probably a day or two, could be more,” with low confidence, primarily because nobody has actually tried it.

That process made sense when trying was the expensive part. You had to stop what you were doing, load the context into your head, make the change by hand, write the tests, then discover the second- and third-order consequences. When the first attempt is cheap, defending the boundary can cost more than crossing it.

An agent can produce that first patch in the time the thread takes to warm up. It’s not free and definitely not automatically correct. But it is cheap enough that the smart move is often to stop guessing and look at a real diff.

The first patch is a price check, not the product

The mistake is to treat the generated patch as the deliverable. It isn’t. It’s a probe. It turns an abstract scope argument into a concrete artifact you can interrogate:

  • Does it touch the files you expected, or does it sprawl across five packages?
  • Are the tests obvious, or does the change resist being tested?
  • Does it preserve the existing abstractions?
  • Does it quietly require a new product decision?
  • Would you be comfortable owning this behavior six months from now?

Those are better questions than “does this feel like scope creep?” because now you’re arguing from evidence instead of vibes. If the last_active_at field comes back as a four-line diff with a passing test, ship it. The debate was the expensive part. However, if that same request comes back touching the auth middleware, you’ve learned the request was never small. Not only that, you learned this in thirty minutes instead of two days.

This is not letting the AI decide. It’s using the AI to make human judgment cheaper and better-informed.

Cheap to write is not the same as cheap to own

Here’s the trap, and it’s the most important distinction of the AI era. A change is not cheap just because the code was cheap to generate. It’s cheap only if a human can confidently review and own the result.

A thousand-line diff that technically passes but nobody wants to own is not a cheap change. It’s a deferred cost. So the dividing line in that case isn’t “can an agent write this?” It’s “can a person validate it?”

  • Adding a display field that already exists in the backend is usually cheap.
  • Changing authorization behavior is not cheap, no matter how clean the diff.
  • Refactoring a well-tested helper is usually cheap.
  • Changing data-retention semantics is not cheap.

Plenty of changes still deserve a hard no even when the code is trivial. This includes anything that moves the product contract, creates a support burden, or touches privacy, billing, or compliance. AI lowers the cost of producing a candidate. It does nothing to lower the cost of owning one.

Move scope discipline closer to the evidence

Traditionally, scope discipline happened before implementation, because implementation was the expensive thing to protect. Now some of that discipline can move to review. That doesn’t mean skipping planning. It means being precise about which planning actually pays off.

Before relitigating a small change, ask for a constrained attempt. The constraints are the whole point.

Produce the smallest possible patch. Keep it behind the existing feature flag. Don’t change the public contract. Add or update tests. List every file you touched and call out anything risky.

If the agent can’t produce a clean patch under those constraints, the request was bigger than you thought, and you know it carries a real ownership cost before anyone commits to it. If it can, that tells you something too. Either way you’ve replaced “is this in scope?” with “here’s what it costs. Do we want to pay it?”

The new skill is pricing uncertainty

The best engineers in an AI-assisted world won’t be the ones who say yes to everything, and they won’t be the ones who reflexively say no. They’ll be the ones who can price uncertainty fast. They’ll know when a request is a product decision wearing an implementation costume, when review will be harder than writing, and when a change is small enough that the fastest responsible answer is to just try it.

That last one is genuinely new. “Try it and see” used to mean pulling a developer off other work. Now, for the right kind of task, it means handing an agent a bounded assignment and using the result to make a better call. Less time guessing, more time supervising. Less time treating implementation as a black box, more time evaluating concrete artifacts.

Scope creep is still real. But “no, because any new code is too expensive” is a much weaker argument than it was two years ago. The cost of producing code has dropped. The cost of understanding, reviewing, and owning it didn’t. So the question worth asking shifted from “is this more work?” to “where’s the real cost?” And sometimes, for a small, bounded change, the real cost is just finding out.

The cost of saying yes has changed. The cost of saying no should change with it.

The post The cost of saying yes has changed appeared first on The GitHub Blog.

Eclipse Dataspace Components on AWS: Cost optimization strategies

Post Syndicated from Jorge Hernández Suárez original https://aws.amazon.com/blogs/architecture/eclipse-dataspace-components-on-aws-cost-optimization-strategies/

When you deploy Eclipse Dataspace Components (EDC) connectors on AWS, one of the first challenges you face is predicting and controlling the cost of the required infrastructure. Without clear benchmarks, it is difficult to make informed decisions about workload sizing, environment configuration, and long-term investment.

Part 1 of this 3-part blog series covered the fundamentals of data space architectures and the EDC per the International Data Space Association’s (IDSA) standards. Part 2 explored production-ready architecture patterns for deploying EDC connectors on Amazon Web Services (AWS), discussing operational excellence, security, and reliability principles. This final post covers the remaining three AWS Well-Architected Framework pillars: Performance Efficiency, Cost Optimization, and Sustainability.

In this post, you will learn which AWS services drive cost in an EDC connector deployment, how to estimate monthly costs for business-critical and non-critical workloads, and how to apply optimization strategies that can reduce your spending by up to 58%.

Understanding cost drivers in data space deployments

Data spaces are secure and sovereign data environments that enable data sharing across independent organizations. With these architectures, you can collaborate with external organizations while maintaining full control over your data and compliance with data sovereignty principles. Your infrastructure costs can vary significantly. The main factors are your performance and reliability requirements, along with data volume and velocity across the network. It’s also important to distinguish between two types of infrastructure. A Dataspace Governance Authority (DSGA) centrally establishes components such as management, identity, and discovery functions. Participants host other components themselves, including the connector. This blog post focuses only on costs associated with EDC connector deployment on the participant, that is, the data provider and consumer sides.

Fictional usage assumptions

Before diving into the numbers, here are technical and operational assumptions you can use as a baseline for your own estimates.

Technical assumptions

Category Assumption Justification
Data Volume 5 GB per participant Includes 6 months of historical data, and backups
Network Traffic 20 GB/month per participant Data transfers between participants
API Calls 100,000/month per participant Catalog queries, contract negotiations, and data transfers
OAuth Token Requests 1,000/month per participant Machine-to-machine authentication for data plane operations

Table 1: Technical assumptions for EDC connector cost estimation

Operational assumptions

  • Single AWS Region: Spain (eu-south-2)
  • Operating hours: 24/7/365.
  • Growth rate: Not considered in baseline estimates.
  • Disaster recovery: Automated backups only (no cross-region replication)

Deployment architecture and scenarios

Figure 1 shows the reference architecture for deploying production-ready EDC connectors on AWS, covered in depth in Part 2 of this series.

Production-ready EDC connector deployment architecture diagram showing AWS services including Amazon ECS, Amazon Aurora, Network Load Balancer, and supporting services

Figure 1: Production-ready EDC connector deployment

This post considers two cost scenarios depending on the criticality of the workload:

  • Business-critical workloads: Designed for high availability, performance, and reliability of use cases supporting critical business functions.
  • Non-critical workloads: Designed for use cases that tolerate interruptions, testing environments, or production workloads where brief disruptions are acceptable.

Both scenarios follow the architecture patterns described in Part 2 of this post series, with the primary differences being in sizing of compute and database resources.

Cost estimation: Business-critical workloads

Note: These estimates use the assumptions above and illustrate the relative cost contribution of each service. Your actual costs may vary based on your specific usage patterns, data volumes and regional pricing. This post highlights which components represent the highest cost drivers and therefore come with the highest potential for optimization.

AWS Service Configuration Monthly Cost (USD)
Amazon Aurora PostgreSQL-Compatible Edition db.r6g.large (2 vCPU, 16 GB), 20 GB storage + 10 GB backup 276.00
Amazon Elastic Container Service (Amazon ECS) with AWS Fargate 2 vCPU, 4 GB RAM, always on 83.00
Network Load Balancer 20 GB processed data 20.00
AWS Secrets Manager 10 secrets 4.00
Amazon Cognito 1K machine-to-machine (M2M) token requests 2.25
Amazon Elastic Container Registry (Amazon ECR) 2 GB storage, 10 GB transfer 1.00
Amazon API Gateway 100K REST API calls 0.40
Amazon Simple Storage Service (Amazon S3) 5 GB Standard tier 0.10
Total 387.00

Table 2: Estimated monthly cost for business-critical EDC connector deployment

These estimates help identify where your budget goes and where optimization has the most impact. In the business-critical scenario, the main cost driver is Amazon Aurora PostgreSQL. The db.r6g.large configuration is selected for constant workloads that require reliability and speed with high memory and performance. Amazon ECS with AWS Fargate is the second largest cost contributor as it runs containers continuously to maintain environment availability. Network Load Balancer represents a third notable cost component, while the remaining services contribute only a small portion of the total cost.

Cost estimation: Non-critical workloads

If you are running development, testing, or experimentation environments, you can reduce costs by up to 58% through rightsizing and use of Amazon EC2 Spot capacity.

AWS Service Configuration Monthly Cost (USD)
Amazon Aurora PostgreSQL-Compatible db.t4g.medium (2 vCPU, 4 GB), 20 GB storage + 10 GB backup 110.00
Amazon ECS with AWS Fargate Spot 2 vCPU, 4 GB RAM, always on 26.00
Network Load Balancer 20 GB processed data 20.00
AWS Secrets Manager 10 secrets 4.00
Amazon Cognito 1K M2M token requests 2.25
Amazon ECR 2 GB storage, 10 GB transfer 1.00
Amazon API Gateway 100K REST API calls 0.40
Amazon S3 5 GB Standard tier 0.10
Total 164.00

Table 3: Estimated monthly cost for non-critical EDC connector deployment

These figures show that a non-critical configuration can cut costs significantly while maintaining the same data throughput and API capacity. Costs are reduced through the use of smaller and more flexible resources. Amazon Aurora PostgreSQL remains the main cost driver, but the smaller instance type (db.t4g.medium) reduces cost significantly. From a compute perspective, using Amazon ECS with AWS Fargate Spot capacity cuts costs by almost 70% compared to the business-critical setup. In total, this configuration reduces the monthly cost by approximately 58%, while maintaining identical assumptions for data throughput, API calls, and storage.

Key takeaways on cost optimization

This comparison shows that the primary cost contributors in both scenarios are database, compute and load balancing resources, which represent baseline infrastructure costs rather than usage-based charges. Services like Amazon S3, API Gateway, and data transfer charges contribute marginally to overall costs at these volumes. This cost structure indicates that the architecture scales efficiently with increased usage. As you onboard more use cases and increase data volume and velocity, you get more value from your existing infrastructure investment without proportional cost increases.

Well-Architected pillars: Performance efficiency, cost optimization, and sustainability

Part 2 of this series covered EDC best practices along the Operational Excellence, Security, and Reliability pillars of the AWS Well-Architected Framework. This section covers the remaining three pillars as they apply to EDC deployments.

Performance efficiency

Right-size compute resources: Match your Amazon ECS task definitions to actual workload requirements. Start with smaller configurations and scale up based on observed metrics rather than over-provisioning from the start. Amazon CloudWatch Container Insights provides the visibility needed to make informed sizing decisions.

Use the flexibility of Amazon Aurora: For workloads with variable demand patterns, consider Amazon Aurora Serverless v2 which automatically scales database capacity based on application needs. This eliminates the need to provision for peak capacity while maintaining performance during high-demand periods.

Optimize data transfer patterns: Design your data plane operations to minimize unnecessary data movement. Use Amazon S3 Transfer Acceleration for large transfers across geographic distances and consider data compression where appropriate to reduce both transfer times and costs.

Cost optimization

Reduce compute costs for fault-tolerant workloads: With AWS Fargate Spot, you can save up to 70% for workloads that can tolerate interruptions. Non-critical environments, batch processing, and development workloads are ideal candidates. Implement graceful shutdown handling to manage Spot interruptions effectively.

Lower storage costs over time: Configure Amazon S3 Lifecycle policies to automatically transition infrequently accessed data to lower-cost storage classes such as S3 Intelligent-Tiering or S3 Glacier Instant Retrieval. For EDC connector deployments, historical transfer logs and archived assets are good candidates for tiered storage.

Monitor for unexpected cost increases: Use AWS Cost Explorer and set up AWS Budgets with alerts to help detect unexpected cost increases. Tag EDC-related AWS resources consistently so you can accurately allocate costs and identify optimization opportunities.

Lock in lower rates for predictable workloads: For business-critical connectors with predictable, steady-state usage, Savings Plans for Amazon Aurora and AWS Fargate can provide significant discounts compared to On-Demand pricing.

Sustainability

Optimize resource utilization: Higher utilization of provisioned resources means less waste. Use automatic scaling policies to match capacity with demand and shut down non-production environments outside of business hours when possible.

Select efficient instance types: AWS Graviton-based instances (such as the r6g and t4g families used in our example) deliver better price-performance and energy efficiency compared to equivalent x86 instances. AWS Graviton processors offer improved performance per watt of energy use.

Minimize data movement: Each data transfer consumes energy. Design your data space integrations to avoid redundant transfers, cache frequently accessed catalog data of peers locally using the Federated Catalog, and batch operations where possible to reduce the total number of network round trips.

Summary

By rightsizing AWS infrastructure to match actual compute and database capacity needs, data space participants can achieve significant cost savings without compromising on data security and sovereignty aspects that make data spaces valuable. The comparison between business-critical and non-critical workload configurations demonstrates how AWS services like Amazon Aurora, AWS Fargate Spot, and Amazon S3 can be combined effectively to balance data sovereignty, performance, and cost efficiency.

As data spaces grow in adoption across industries and geographies, understanding these cost dynamics becomes increasingly important as you plan your network participation. The patterns and estimates in this post series offer a foundation for planning your cross-organizational data strategy and data spaces journey on AWS.

To get started, assess your workload criticality to determine whether a business-critical or non-critical configuration fits your needs. Then use the AWS Pricing Calculator to estimate costs for your specific data volumes, regions, and usage patterns. For an end-to-end reference implementation, explore the Dataspace Connector on AWS project which combines Infrastructure-as-Code with custom EDC extensions and AI tooling integration.

References

About the authors

Eclipse Dataspace Components on AWS: Architecture patterns in production

Post Syndicated from Jonas Bürkel original https://aws.amazon.com/blogs/architecture/eclipse-dataspace-components-on-aws-architecture-patterns-in-production/

Running Eclipse Dataspace Components (EDC) connectors in production on AWS requires deliberate architecture decisions around isolation, managed services, and security layering. In Part 1 of this series, we covered the fundamentals of data space architectures and EDC per the International Data Space Association’s (IDSA) standards. If you are new to EDC, we recommend starting there. We showed how connector functionality can be customized to support native integration with Amazon Web Services (AWS) Cloud services. Examples include Amazon Simple Storage Service (Amazon S3) for data storage and AWS Secrets Manager for credentials management. In this post, we dive deeper into the connector deployment architecture on AWS and present patterns and practices for production-grade deployments.

Fundamental architecture building blocks

The EDC connector consists of a control plane and a data plane that customers typically ship and deploy as containers. Depending on data integration requirements and support for specific protocols and capabilities, a custom EDC build process may need to be implemented as described in Part 1 of this series. For example, you may need OAuth 2.0 client credentials for the data plane to connect to backend systems. You store the resulting EDC container images in a container registry, such as Amazon Elastic Container Registry (Amazon ECR). Figure 1 shows an example architecture for EDC connector deployments on AWS following best practices for production use.

Architecture diagram showing production-ready EDC connector deployment on AWS with Amazon ECS, Aurora, S3, and API Gateway components

Figure 1: Production-ready EDC connector deployment on AWS

You can split the architecture into four sub-components:

  • Amazon Elastic Container Service (Amazon ECS) and AWS Fargate provide serverless container orchestration. This allows for scalable EDC deployment without managing any of the underlying infrastructure.
  • EDC requires persistence to store secrets and relational control plane data, and a means of vending OAuth 2.0 client credentials. AWS Secrets Manager, Amazon Aurora and Amazon Cognito can provide these capabilities as managed services.
  • Amazon S3 provides durable data storage for handling both inbound and outbound data that is shared and received through the data space.
  • Finally, Amazon API Gateway and Network Load Balancer provide secure, private network connectivity to EDC APIs in an isolated Amazon Virtual Private Cloud (Amazon VPC) using VPC links.

With this approach, all cloud resources belonging to a single EDC connector instance form an isolated architecture cell. You access this cell through the S3 bucket to move in data that is to be shared as part of an EDC asset, or to retrieve data received from a third party as part of an EDC data transfer. Secondly, the API Gateway can be configured to expose selected EDC API resources from its management API, data plane API and Dataspace Protocol (DSP) API. You can protect both means of interacting with the EDC architecture cell using AWS Identity and Access Management (AWS IAM) and the AWS Signature Version 4 (SigV4) protocol.

Larger enterprises participating in data spaces may decide to operate multiple EDCs depending on their requirements on failure isolation, data governance, and separation of shared and received data. A common pattern is to deploy separate connector instances per use case. Infrastructure-as-code such as AWS Cloud Development Kit (CDK) allows for automated, templatized deployment and management of EDC connectors over time while keeping operational effort at bay. Using the Dataspace Connector on AWS reference implementation, a full connector cell deploys from a single CDK command, ready to negotiate contracts and transfer data. Amazon API Gateway also comes with Model Context Protocol (MCP) proxy support. This allows EDC APIs to be consumed by authorized AI agents and MCP clients for autonomous data collection and sharing. Besides integration with agentic systems, customers often follow a workflow-based approach for connecting EDCs with their cloud-based data environments. They interact with both APIs and the peripheral S3 bucket to securely expose and retrieve external information.

Real-world validation of these architecture patterns can be seen in production deployments like the Prometheus-X Data Space Connector, for education sector use cases. This implementation uses the same core architecture we recommend: Amazon ECS with AWS Fargate for container orchestration, S3 for data storage, and event-driven processing with AWS Lambda and Amazon EventBridge. This demonstrates how these patterns work effectively in production environments across different industry sectors.

Key principles for production-readiness

We discuss some of the architecture principles that inform the best practices diagram highlighted in Figure 1 along three of the AWS Well-Architected Framework’s pillars.

Operational Excellence

Infrastructure as Code for Consistency: Define all infrastructure declaratively to support repeatable, version-controlled, and testable deployments. Automated validation, for example using CDK Nag, helps catch misconfigurations and security issues before deployment, shifting security left in the development lifecycle. The code itself serves as living documentation of the architecture.

Observability as a First-Class Concern: Treat monitoring and logging as core infrastructure components. Amazon CloudWatch Container Insights, Amazon CloudWatch Logs, and EDC’s structured health check endpoints provide visibility into system behavior, supporting proactive issue detection and faster troubleshooting. EDC APIs for health checks can be similarly exposed with restricted access through API Gateway and IAM.

Managed Services Over Self-Managed Infrastructure: Use AWS managed services (Aurora, Secrets Manager, Fargate, Cognito) instead of deploying and maintaining compatible self-managed solutions. This shifts undifferentiated heavy lifting to AWS and reduces operational burden. You gain high availability, built-in security best practices, compliance certifications, and automatic updates.

Security

Defense in Depth: Implement security through multiple independent layers rather than relying on a single control. Network isolation (VPC private subnets), security group segmentation (restricting traffic between components), IAM least privilege (scoped permissions per service), and encryption (at rest and in transit) each provide independent controls. These layers work together so that if one layer is bypassed, others continue to provide protection.

Principle of Least Privilege: Every component receives only the minimum permissions required for its specific function. Scope IAM roles to individual services (control plane, data plane) and restrict security groups to necessary ports and sources. The internal-only Network Load Balancer fronted by API Gateway prevents unintended public exposure of EDC APIs and data. This may also support security review and approval of EDC as open-source software, since APIs can be allowlisted and validated individually.

Encryption Everywhere: Encrypt data by default at every stage: at rest (Aurora, S3, Secrets Manager), in transit (TLS enforcement, HTTPS-only egress), and during processing (encrypted environment variables). This provides comprehensive data protection regardless of where information resides in the system.

Reliability

Fail Fast, Recover Automatically: Systems detect failures quickly and recover without manual intervention. ECS circuit breakers can automatically roll back failed deployments, automated health checks remove unhealthy targets, and point-in-time recovery supports rapid database restoration. This minimizes mean time to recovery (MTTR) and reduces the scope of failures, even within a single EDC architecture cell.

Design for Regional Resilience: Cross-zone load balancing distributes traffic across multiple Availability Zones (AZs), Aurora automatically replicates data across AZs, and Fargate tasks can be scheduled in any AZ. The highlighted architecture can tolerate Availability Zone failures in an AWS Region without service disruption. For more information about Availability Zones and Regions, see AWS Global Infrastructure.

Decoupled Components with Clear Boundaries: Deploy the control plane and data plane as independent services with distinct responsibilities, security contexts, and scaling characteristics. This separation enables independent updates, targeted scaling, and failure isolation between coordination logic and data transfer operations.

The remaining three Well-Architected Framework pillars of Performance Efficiency, Cost Optimization, and Sustainability are covered in the third post of this series where we discuss cost optimization strategies for running EDC connectors on AWS.

Conclusion

With the growing popularity of data spaces and EDC as a data space connector, it is important to distinguish between a setup suitable for testing and experimentation and one that is ready for production. Production environments require that business-critical processes depend on timely, successful transmission of confidential information between participants. The architecture defined in this post combines EDC deployment best practices from the community with AWS recommendations to achieve fault tolerance, scalability, and security while keeping operational complexity at a minimum.

In part 3, you will learn about cost optimization strategies to run your production-ready connector efficiently and maximize the value it returns by supporting business use cases for data sharing along your supply network. In the meantime, explore the Dataspace Connector on AWS project and see how the patterns and best practices covered in this post come together in an end-to-end reference implementation.

References

About the authors

Eclipse Dataspace Components on AWS: Data sharing fundamentals

Post Syndicated from Alejandro Esquivias Cañadas original https://aws.amazon.com/blogs/architecture/eclipse-dataspace-components-on-aws-data-sharing-fundamentals/

This three-part blog series guides you through implementing Eclipse Dataspace Components (EDC) on AWS, from foundational concept to production deployment. Part 1 establishes the theoretical foundation with IDSA standards, the Dataspace Protocol (DSP), and core EDC architecture. Part 2 provides production-ready AWS deployment patterns using services like Amazon Elastic Container Service (Amazon ECS), Amazon Aurora, and Amazon API Gateway. Part 3 completes the journey with cost optimization strategies and practical guidance for running efficient, scalable data space infrastructure on AWS.

The International Data Spaces Association (IDSA) is a non-profit organization focused on establishing and promoting standards for data spaces. A data space is defined as a “set of technical services that facilitate interoperable dataset sharing between distinct entities”. At a technical level, a data space has participants: data consumers and data providers. Centrally, there is a Dataspace Governance Authority (DSGA). The DSGA manages the data space, enforces rules and policies and issues membership credentials to participants.

IDSA rules and specifications are implemented in the Dataspace Protocol (DSP). The DSP has become an Eclipse Specification project and can be found in the Dataspace Protocol GitHub repository. Standardization is under development and is currently in the approval phase as ISO/IEC DIS 20151. The Eclipse Dataspace Components (EDC) provide the technical components to implement data spaces according to IDSA requirements.

These components include the federated catalog (FC), the connector, and the identity hub. The FC contains an aggregated repository of catalogs gathered from multiple participants in the data space. These are obtained by periodically crawling participants’ data assets and storing them in a local cache, to eliminate the need to query each participant individually on demand. The connector is the software that enables data to be shared between participants, and identity hub manages a participant’s credentials in the data space. Amazon Web Services (AWS) provides a comprehensive cloud infrastructure that supports the deployment and operation of data space components like the EDC connector. AWS offers scalable compute, storage, and networking services that help you build secure, compliant, and interoperable data spaces aligned with IDSA standards and the ISO/IEC DIS 20151 specifications.

To verify identities in a data space in a decentralized manner, the Decentralized Claims Protocol (DCP) is used. DCP represents an overlay on top of DSP to establish trust between network participants. When an issuer needs to prove their identity to a verifier, they first generate a Decentralized Identifier (DID), which contains information about their identity. The issuer stores their Verifiable Credential (VC) in their identity hub. A verifiable credential is similar to a certificate: while a certificate authority validates a public key, the credential issuer validates the DID with specific attributes. The verifier looks up the DID of the issuer and with the information obtained from the DID document verifies the VC.

High-level diagram showing how DCP establishes trust between an issuer and verifier using DIDs and Verifiable Credentials

Figure 1: High-level diagram of the Decentralized Claims Protocol (DCP)

Simplified overview showing how a verifier resolves a DID document to verify credentials

Figure 2: Simplified overview of DID document processing

The final element of the EDC are the different types of policies, including membership, access, contract and usage policies.

The role of the connector

The EDC connector is divided into two parts: the control plane and the data plane. The control plane handles contract negotiation and sends messages to the data plane to initiate a data transfer. The data plane is responsible for transferring data from a provider’s to a consumer’s EDC connector across distinct legal entities.

Diagram showing the EDC connector architecture with separate control plane and data plane

Figure 3: Overview of the connector control and data plane

Structure of the EDC connector open-source project

The Connector repository as part of the EDC project defines how the connector control and data planes are implemented. We provide an overview of how the repository is structured:

  • /spi – The Service Provider Interface (SPI) is the architectural foundation that defines how modules communicate within the EDC connector. It contains foundational interfaces and contracts that every component must implement, establishing standardized integration patterns. This layer also acts as a blueprint for developers to extend EDC connector functionality while maintaining clean separation of concerns and ensuring compatibility between core and custom components.
  • /core – The Core module represents the core SPI implementation. It houses the actual working code for the connector’s essential operations, including default implementations of key services and business logic for data sharing.
  • /extensions – The Extensions layer showcases the connector’s modular plugin architecture through real-world integrations, including connections to major cloud providers like AWS. These extensions serve both as reference implementations and ready-to-use components for common enterprise integration scenarios.

SPI defines the contracts, Core implements the basics, and Extensions add specialized functionality. These three layers work together to create a flexible, extensible data space connector system. The “vanilla” Eclipse EDC connector does not bundle the AWS extensions by default. To add AWS service-specific functionality, such as integration with Amazon Simple Storage Service (Amazon S3), AWS Secrets Manager, or Amazon DynamoDB, you need to include the respective AWS extensions into a custom EDC control and data plane build.

High-level EDC customization guide

Customizing the EDC connector for native AWS service integration creates a purpose-built solution that can use AWS managed services for storage, security, and scalability. The following steps help your connector natively integrate with services like Amazon S3 for data storage (used for example as Asset Administration Shell “Submodel Server”) and AWS Secrets Manager for credentials management, rather than relying on operations of self-managed components.

EDC uses a modular, plugin-based architecture built on Gradle. The vanilla connector ships only core functionality. To integrate with specific cloud services or persistence backends, you assemble a custom build that combines EDC’s core modules with the extensions you need. The customization revolves around three concepts: a version catalog, launcher modules, and a project settings file.

Step 1: Version catalog

The version catalog (gradle/libs.versions.toml) is the centralized registry of all dependencies and their versions. Here you declare which EDC modules, cloud provider extensions, and third-party libraries your connector needs to use. EDC publishes its AWS extensions under the org.eclipse.edc.aws Maven group. You reference these alongside the core EDC artifacts (org.eclipse.edc) at compatible version numbers. This single file ensures all modules in your project share consistent dependency versions.

Step 2: Launcher modules

The launcher modules are the actual deployable units: one for the control plane and one for the data plane. Each launcher is a small Gradle subproject whose build.gradle.kts lists the extensions to bundle at runtime. A typical control plane launcher might include the core control plane module, a metadata persistence extension (such as PostgreSQL or DynamoDB), a vault extension (such as HashiCorp Vault or AWS Secrets Manager), and any provisioning extensions for your target storage system. The data plane launcher follows the same pattern with data plane-specific modules. Both launchers typically use Gradle plugins to produce a single executable JAR. You only include what you actually use, keeping the connector lightweight and tailored to your unique requirements.

Step 3: Project settings

The project settings file (settings.gradle.kts) registers all modules with Gradle: your launcher subprojects and any custom extensions you may develop locally. If you write your own extension, for example, a DynamoDB-backed asset store, you place it in an extensions/ directory and register it here so your launchers can reference it as a project dependency.

The resulting project structure typically looks like this:

my-connector/
├── control-plane/
│   └── build.gradle.kts       # Control plane launcher
├── data-plane/
│   └── build.gradle.kts       # Data plane launcher
├── extensions/                # Optional: Custom extension code
├── gradle/libs.versions.toml  # All dependency versions
├── build.gradle.kts           # Root build config
└── settings.gradle.kts        # Subproject registrations

An open-source reference implementation for EDC customization on AWS is provided as part of the Dataspace Connector on AWS project. In this post, you learned about the fundamentals behind secure, cross-organizational data sharing using emerging data space architectures. We covered the two protocols included in ISO/IEC DIS 20151 data space standardization, DSP and DCP, and discussed the EDC connector, the main software required for data space participants, and how it can be customized.

In part 2, we explore production-ready deployment patterns for EDC connectors on AWS, examining architecture best practices that support your data space infrastructure’s security, reliability, and operational efficiency. To get started, explore the Dataspace Connector on AWS project and see how its Gradle build settings are configured to support Amazon DynamoDB for serverless, inexpensive metadata persistence.

References

About the authors

[$] Securing BPF LSMs against tampering

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

Since 2020, BPF programs have been able to

act as Linux security modules
(LSMs). Several projects, including systemd, have been working to use
that capability to provide more security to users. Christian Brauner
spoke at the 2026

Linux Storage, Filesystem, Memory-Management, and BPF Summit
about some of the limitations of using BPF in this way, and the changes he
would like to see for systemd’s use. In particular, he would like a way to make
sure that BPF programs cannot be removed or have their private data tampered with.

Искате ли децата ви да учат заедно с ромски деца?

Post Syndicated from Емилия Милчева original https://www.toest.bg/iskate-li-detsata-vi-da-uchat-zaedno-s-romski-detsa/

Искате ли децата ви да учат заедно с ромски деца?

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

Общината е Самоков и според решението на Комисията за защита от дискриминация (КЗД) кметът д-р Ангел Джоргов е нарушил чл. 5 от Закона за защита от дискриминация по признака „етническа принадлежност“, като не е предприел действия във връзка със сегрегация на ученици от първи клас в две основни училища – „Митрополит Авксентий Велешки“ и „Христо Максимов“. 

Под това решение от 5 май, с което „Тоест“ разполага, са се подписали и тримата членове на КЗД: Наско Атанасов, Елка Божова и Иво Христов (понастоящем вицепремиер, отговарящ за човешкото развитие). 

На сайта на КЗД решението не е публикувано.

По данни за 2020 г. на Центъра за междуетнически диалог и толерантност „Амалипе“ в България има 335 сегрегирани училища, 185 от които са общообразователни, а останалите – професионални гимназии. Това е близо 14,2% от всички училища в България.

Кратък наръчник по ромска интеграция

С наближаването на изборите за пореден път се повдига въпросът за интеграцията на ромите. Все се появяват конфликти, които се използват за катализиране на етническо напрежение.

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

Като член на независим регулатор, избран от квотата на президента, Иво Христов е подкрепил извода на КЗД по казуса. Като вицепремиер той носи политическата отговорност дали този принцип ще намери място в политиката на правителството. Това е национална тема – ромите са третата етническа група в България с 4,4% дял от населението, по данни от преброяването през 2021 г., и Христов разполага с власт и възможности да постави проблема в дневния ред на „Прогресивна България“. 

Как започва всичко?

В сигнал на Фондация „Саворе“, подаден от председателя ѝ Христо Николов, се описва как в Самоков години наред действа система, която възпроизвежда етническото разделение още при записването на децата в първи клас. Според сигнала не става дума за случайно струпване на ромски ученици в едно училище, а за последици от начина, по който Общината е организирала училищния прием.

По думите на жалбоподателя, Общината използва училищните райони така, че ромските деца от определени квартали да се насочват основно към „Митрополит Авксентий Велешки“ и „Христо Максимов“. В същото време в останалите училища в града учат почти изцяло деца от български произход. Родителите от ромски произход, които искат да запишат децата си в друго училище, често срещат отказ с аргумента, че не попадат в съответния район.

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

Първата институционална реакция е, че проблем няма. След проверка Регионалното управление на образованието – София-област стига до заключението, че приемът е организиран законосъобразно, и не установява сегрегирани училища в Самоков. До противоположен извод стига по-късно КЗД.

Колко входа има българското образование?

Майка ми е родена през 1946 г. и ми е разказвала, че в училището, в което е учила през 50-те години, е имало българи, роми и турци. Но училището е имало два входа. През единия са влизали българските деца, а през другия – ромските и турските. Децата са играли заедно, но са учили в различни класни стаи, вероятно и по различни програми.

Тази история разказва Огнян Исаев от Тръста за социална алтернатива, който проучва темата за сегрегацията в образованието. Процесът започва много по-рано от комунистическия режим и продължава през различни исторически периоди, а някои факти са в пълно противоречие с днешното клише, че ромите не ценят образованието. 

Ако не можеш да нахраниш детето си

Как и защо в масовия случай децата, попаднали в институции, са от ромски произход? По приблизителни оценки те са между 60 и 70%, въпреки че ромите съставляват малко над 10% от населението. Надежда Цекулова разказва за проблема.

„Още в края на XIX и началото на XX век в България съществуват етнически училища – гръцки, турски, арменски и еврейски. Те се самоиздържат чрез съответните религиозни и общностни организации. След 20-те години на XX век държавата постепенно централизира образователната система и започва да въвежда единни стандарти, като обучението преминава на български език, а майчиният език остава като учебен предмет.“

До началото на ХХ век голяма част от ромите в България са мюсюлмани и затова посещават турските училища. След Балканските войни и последвалите спогодби между България и Турция голяма част от турското население напуска страната и много турски училища започват да се закриват. Затова още през 20-те години ромската общност в София предприема организирани действия, за да отвори собствено училище. За целта обаче трябва да създаде своя мюсюлманска вероизповедна община, защото тогава училищата се управляват именно чрез такива общности. 

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

Следващите десетилетия обаче показват различна история – не за липсата на желание за образование, а за различните форми, в които държавата организира достъпа до него. 

Формирането на големи трайно обособени ромски квартали в България улеснява образователната сегрегация. Гетата са едни от най-устойчивите форми на пространствено разделение в страната. 

След 1944 г. държавата създава училища в ромските квартали с цел да ограмоти ромското население, тъй като тогава делът на неграмотните роми на възраст между 15 и 59 години надхвърля 81%; 1,5% са с основно образование и едва 0,03% – със средно или висше . 

През 80-те години делът на неграмотните роми вече е спаднал на 11%, с основно образование са 40%, а със средно и висше – близо 5%. (Но при преброяването през 2011 г. се установява, че неграмотното население се е увеличило на 21,8%, макар че и другите показатели са нараснали.)

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

Правозащитникът прави важно разграничение между грамотност и образование:

Често се казва, че по време на социализма не е имало неграмотни хора. Това донякъде е вярно. Четивната и писмената грамотност са били сравнително високи. Но функционалната неграмотност е огромна. Хората могат да четат и да възпроизвеждат текст, но много често не разбират смисъла му.

Сегрегацията обаче не се изчерпва само с отделните училища, а и с поставяне на диагнози.

„По данни от изследване на проф. Илона Томова от 1995 г. всяко трето ромско дете учи в специално училище, а в помощните училища делът на ромските деца надхвърля 50%. Нерядко това са били напълно здрави деца, чиято единствена причина да попаднат там е етническият им произход“, казва Огнян Исаев. 

От дискриминация към дехуманизация – в малки стъпки

Чухте ли за директорката на норвежко училище, която заявила, че българските деца трябва да бъдат отнемани от семействата им? А че норвежкият министър на образованието е защитил нейната „свобода на…

В своята статия „Социални фактори, подкрепящи процеса на приобщаващо образование на ромските деца“¹ проф. д.н. Христо Кючуков разказва как са били поставяни диагнози на ромски деца поради невладеене на български език. Неговият спомен датира от 80-те години на миналия век, когато е бил учител в родния си град Провадия, а всичките му ученици са били от ромския и турския етнос.

Много ромски деца идваха в първи клас без никакви знания по български език. Медицинска комисия в училището проверяваше знанията им по български, преди да постъпят в първи клас, и обикновено им се поставяше диагноза „лека умствена изостаналост“ поради невладеене на българския език. На родителите се даваха препоръки да изпратят децата си в „училища за бавноразвиващи се ученици…“

Тази практика продължава и след демократичните промени и е описана и от други автори². През 1997 г. в България има 299 „специални училища“ от различен вид с 27 148 деца, повечето роми. В изследването „Отпадащите роми“ се посочва, че в Словакия повечето ученици в училищата за деца с умствени и физически увреждания също са роми, както и в Чехия. В Румъния има 246 такива „специални училища“, а броят на децата е 48 237, повечето роми. В Унгария в редица региони до 90% от учениците в такива училища също са роми.

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

Последиците от изпращането на напълно здрави деца в „специални училища“ се усещат и днес, посочва Огнян Исаев.

Тези хора вече са на 50 и повече години. Искат да завършат средно образование, за да станат по-конкурентоспособни или просто да получат шофьорска книжка. Но дипломите им са с качествени, а не с числови оценки и няма нормативна пътека, по която да се върнат в общообразователната система. Имали сме конкретен случай в Ботевград. Проверявахме как тези хора да бъдат оценени наново, за да се установи, че никога не са били деца със специални образователни потребности. Оказа се, че такава процедура в МОН практически няма.

По думите му, сегрегацията не е останала в миналото, а просто е променила формите си.

„В началото на Прехода говорим за около 60 сегрегирани училища в ромските квартали и между 60 и 100 сегрегирани образователни институции общо. Днес вече говорим за около 200–220 сегрегирани училища.“ Сред тях вече не са само училищата в ромските квартали. „Най-новата тенденция са т.нар. обединени училища. Законът ги създаде, за да могат децата в малките населени места да стигнат поне до първи гимназиален етап. Само че в някои градове, където има достатъчно средни училища, те започват да се превръщат почти изцяло в ромски училища.“

Като пример Исаев посочва Стамболийски, а Самоков определя като друг показателен случай. Според него подобни процеси вече се наблюдават и в София, където обединени училища също се превръщат в училища почти изцяло с ромски ученици.

Последните налични национални данни също показват мащаба на проблема. Към 2020 г. в България има 930 училища с концентрация на ученици от уязвими групи. От тях 185 се намират в населени места, където има и други училища на същото образователно ниво, тоест съществува реална алтернатива, но концентрацията продължава да се възпроизвежда.

След повече от век няма различни входове към училището за децата от различни етноси и социални групи. Но практиката с отделните входове се е трансформирала в райони за обхват, правила за прием и административни решения. Дали етническите българи биха искали децата им да учат заедно с ромски деца? Решението на КЗД поставя друг въпрос: дава ли държавата изобщо равен шанс това да стане?

1 Кючуков, Х. Социални фактори, подкрепящи процеса на приобщаващо образование на ромските деца. В: Ромската общност и приобщаващото образование: предизвикателства и възможности. София: Регионален център за подкрепа на процеса на приобщаващото образование София-град, с. 24–36.

2 Тилкиджиев, Н., Миленкова, В., Петкова, К., Милева, Н. Отпадащите роми. София: Институт „Отворено общество“, 2009, с. 44.

Security updates for Friday

Post Syndicated from jzb original https://lwn.net/Articles/1083388/

Security updates have been issued by AlmaLinux (cifs-utils, container-tools:rhel8, libreoffice, nodejs:24, perl-XML-LibXML, and python3.12), Fedora (ansible-collection-ansible-posix, firefox, freerdp, ImageMagick, mingw-glib2, perl-DBI, perl-HTTP-Date, rust-cargo-rpmstatus, and rust-opendal), Oracle (cifs-utils, gegl, gimp, git-lfs, go-toolset:ol8, hplip, kernel, libreoffice, maven:3.9, perl-XML-LibXML, python3, python3.12, python3.9, and uek-kernel), Red Hat (kernel, kernel-rt, and podman), Slackware (netatalk), SUSE (agama, aws-nitro-enclaves-binaryblobs-upstream, gimp, gpsd, grafana, hostapd, ImageMagick, jackson-databind, kernel, libssh2_org, nm-configurator, opennlp, perl-Mojolicious, python-Pillow, python-python-engineio, python-python-socketio, and tomcat11), and Ubuntu (ntfs-3g, python-authlib, ruby2.3, tar, and ubuntu-advantage-tools).

Details of Alan Turing’s Voice Encryption System

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/07/details-of-alan-turings-voice-encryption-system.html

Really interesting piece of cryptographic history:

In November 2023, a large cache of his wartime papers—nicknamed the “Bayley papers”—was auctioned in London for almost half a million U.S. dollars. The previously unknown cache contains many sheets in Turing’s own handwriting, telling of his top-secret “Delilah” engineering project from 1943 to 1945. Delilah was Turing’s portable voice-encryption system, named after the biblical deceiver of men. There is also material written by Bayley, often in the form of notes he took while Turing was speaking. It is thanks to Bayley that the papers survived: He kept them until he died in 2020, 66 years after Turing passed away.

Introducing self-managed Amazon S3 buckets for AWS Lambda function code

Post Syndicated from Doug Perkes original https://aws.amazon.com/blogs/compute/introducing-self-managed-amazon-s3-buckets-for-aws-lambda-function-code/

If you manage Lambda functions at scale, you’ve likely hit the 75 GB code storage limit or explained to your security team why deployment artifacts live in an S3 bucket you don’t control. Today, we’re announcing self-managed Amazon S3 buckets for AWS Lambda deployment packages. Lambda reads your code directly from your bucket, eliminating quota pressure and giving you full security control.

Previously, the default AWS-managed code storage created three challenges at scale. First, all copies count toward your 75 GB code storage quota. Second, you cannot apply your own encryption, access controls, or compliance tags to the internal bucket. Third, the copy cannot be incorporated into your disaster recovery strategies.

With self-managed S3 buckets, Lambda reads your function code directly from your bucket. No copy, no duplication. Your S3 object becomes the single source of truth for your functions. Deployment packages no longer count against your account’s code storage limit. You manage the bucket’s security and compliance posture: choosing the encryption, defining the access policies, managing lifecycle transitions, and maintaining the audit trail. And because you own the bucket, you can use S3 Cross-Region Replication to maintain fallback copies of your code in a secondary Region, so that your functions remain deployable even if your primary Region experiences an issue. Using self-managed S3 buckets also results in a faster time to first invoke for new functions and after function updates, because Lambda no longer needs to copy your zip package to a Lambda-managed S3 bucket.

You can use this feature today in all AWS standard regions where Lambda is available, at no additional charge beyond your standard Amazon S3 storage and request costs. Let’s look at some use cases, how it works, and how to use it at scale.

Use cases

Here are a few patterns where owning your deployment bucket makes a real difference.

CI/CD pipelines and artifact management

With self-managed storage, your CI/CD pipeline uploads once, and Lambda references the same object. One set of lifecycle rules and access controls covers all artifacts, and rollbacks mean pointing the function to a previous S3 object version.

Multi-account and multi-team architectures

Organizations using AWS Organizations often separate workloads into multiple accounts: a development account, a staging account, and a production account. They centralize shared resources in a tooling or shared-services account.

Self-managed buckets integrate naturally with this pattern:

  • Store all deployment artifacts in a central “artifact account” bucket.
  • Grant cross-account s3:GetObject access to Lambda execution roles in each workload account through bucket policies.
  • Maintain a single inventory of what code is deployed where, managed by your platform or DevOps team.
  • Enforce consistent encryption, versioning, and retention policies from one place.

Disaster recovery and business continuity

Because your deployment artifacts live in a bucket you own, you can use the built-in replication features of S3, Cross-Region Replication (CRR) or Same-Region Replication (SRR), to maintain copies of your code artifacts in backup locations. Combined with S3 Versioning and Object Lock, this gives you a durable, tamper-proof code archive that supports rapid recovery if a deployment is accidentally corrupted or deleted.

How it worked before

When you deploy a Lambda function using a .zip deployment package stored in Amazon S3, the process has traditionally worked like this:

  1. You upload your .zip deployment package to your S3 bucket.
  2. You call CreateFunction or UpdateFunctionCode, specifying the S3 bucket and S3 key.
  3. Lambda copies the .zip artifact from your bucket into an internal, service-managed bucket.
  4. Lambda uses this copy to create the optimized version of your function that runs at invocation time.
  5. The copied artifact counts toward your account’s 75 GB code storage quota.

Diagram showing standard Lambda deployment flow where Lambda copies the zip package to an internal bucket

Figure 1 — Standard Lambda deployment

This model is straightforward and works well for most workloads. However, it creates three friction points at scale:

  • Storage quota pressure: Every deployment package copy counts toward your account’s 75 GB total code storage limit. Organizations with hundreds of functions and multiple published versions can exhaust this quota.
  • No control over stored artifacts: You cannot configure encryption (beyond the service default), access logging, lifecycle policies, Object Lock, or compliance tags on the internal bucket.
  • Redundant storage: Your original artifact remains in your bucket while a copy lives in the Lambda bucket used for provisioning new instances of your Lambda function.

What’s new: REFERENCE mode

This launch introduced a new function configuration setting, S3ObjectStorageMode. The default value is COPY, which provides the existing behavior described in the preceding section. To enable self-managed S3 buckets, set S3ObjectStorageMode to REFERENCE when creating or updating a function. In this mode, Lambda no longer copies your deployment package. Instead, it stores a reference to your S3 object and reads the code directly from your bucket when needed. If you do not specify S3ObjectStorageMode, Lambda still takes a copy by default.

Diagram showing Lambda deployment with self-managed S3 storage where Lambda references the object directly

Figure 2 — Lambda deployment with self-managed storage

This gives you:

  • No quota consumption. Deployment packages in your bucket don’t count against the 75 GB Function and layer storage account limit.
  • Improved performance. Lambda no longer copies the code to an internal bucket, so function creation and updates are faster.
  • Full security and compliance control. Apply your own bucket policies, encryption, Object Lock, versioning, access logging, and compliance tags.
  • Single source of truth. Your S3 object is the canonical artifact with no additional copies and no drift.
  • Disaster recovery options. Use S3 Cross-Region Replication to maintain fallback copies in a secondary Region.

How it works

To use this feature, specify the S3ObjectStorageMode parameter when creating or updating your function.

Creating a new function (AWS CLI):

aws lambda create-function \
  --function-name my-function \
  --runtime python3.13 \
  --role arn:aws:iam::123456789012:role/my-lambda-role \
  --handler app.handler \
  --code S3Bucket=amzn-s3-demo-bucket,S3Key=deployments/my-function.zip,S3ObjectVersion=abc123,S3ObjectStorageMode=REFERENCE

Updating an existing function:

aws lambda update-function-code \
  --function-name my-function \
  --s3-bucket amzn-s3-demo-bucket \
  --s3-key deployments/my-function.zip \
  --s3-object-version def456 \
  --s3-object-storage-mode REFERENCE

AWS Identity and Access Management permissions required for self-managed code storage

AWS Identity and Access Management (IAM) permissions

Lambda needs permission to read the deployment package from your bucket. You can grant access through an S3 bucket policy.

S3 bucket policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LambdaSelfManagedCodeAccess",
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/deployments/my-function.zip",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function"
        }
      }
    }
  ]
}

We recommend including the aws:SourceArn condition key scoped to your specific function ARN to allow for least-privileged access. Note the Resource is scoped to the exact S3 key rather than a wildcard prefix. This follows least-privilege and matches how the aws:SourceArn condition locks down which function can access which object.

Bucket requirements

Your S3 bucket must meet the following requirements:

  • Versioning (required). You must enable S3 versioning to make sure that Lambda references a specific, immutable artifact and to protect against accidental overwrites.
  • Encryption. The following encryption types are supported: SSE-S3, SSE-KMS (including customer-managed KMS keys), and DSSE-KMS. If you use SSE-KMS, the Lambda principal must have kms:Decrypt permission on the key.
  • Object Lock. Supported. You can apply Object Lock in Compliance or Governance mode to prevent accidental deletion of deployment artifacts.
  • Access logging. You can enable S3 server access logging or AWS CloudTrail data events to audit every time Lambda reads your code.

What happens when the object is unavailable

Lambda periodically accesses the source object from your S3 bucket to reoptimize your function code. You must maintain access to the source object for your function to remain active.

If Lambda loses access to the source object for a function, the function transitions to the Inactive state. To restore the function, restore access to the source object and then update the function.

Performance considerations

Lambda functions with self-managed code storage behave the same as standard Lambda functions with one difference during function creation and update. Lambda does not copy your deployment package to a Lambda-managed S3 bucket. In our testing with a 200MB Python 3.13 function, functions using self-managed storage showed function creation times approximately 5s less than the default COPY mode. Reading directly from your S3 bucket without an intermediate copy step can provide a modest advantage, particularly for larger deployment packages.

Getting started with infrastructure as code

Self-managed code storage can be implemented using infrastructure-as-code tooling with either the AWS CLI or AWS CloudFormation today.

AWS CLI

aws lambda create-function \
  --function-name my-function \
  --runtime python3.13 \
  --role arn:aws:iam::123456789012:role/my-lambda-role \
  --handler app.handler \
  --code S3Bucket=amzn-s3-demo-bucket,S3Key=deployments/my-function.zip,S3ObjectVersion=abc123,S3ObjectStorageMode=REFERENCE \
  --region us-east-1

AWS CloudFormation

MyFunction:
  Type: AWS::Lambda::Function
  Properties:
    FunctionName: my-function
    Runtime: python3.13
    Handler: app.handler
    Role: !GetAtt MyLambdaRole.Arn
    Code:
      S3Bucket: amzn-s3-demo-bucket
      S3Key: deployments/my-function.zip
      S3ObjectVersion: abc123
      S3ObjectStorageMode: REFERENCE

Using it at scale

Once you adopt self-managed S3 buckets for your Lambda deployment packages, your artifact bucket grows over time as you deploy new versions of your functions. This section covers strategies for managing that growth efficiently, keeping your versions organized, and planning for cross-Region deployments.

Managing artifact lifecycle with S3 lifecycle policies

Every time you update a function’s code, S3 creates a new object version in your bucket. The previous objects don’t disappear. They accumulate. Without a cleanup strategy, your storage grows indefinitely and old artifacts clutter your bucket.

S3 Lifecycle policies let you automate this entirely. You define rules that transition or delete objects based on age, and S3 executes them on your behalf: no scripts, no cron jobs, no manual intervention.

Strategy 1: Archive old versions to Glacier

If compliance or audit requirements mandate that you retain all historical deployment packages, but you rarely need to access them, transition old object versions to a lower-cost storage class:

{
  "Rules": [
    {
      "ID": "ArchiveOldDeploymentPackages",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "deployments/"
      },
      "NoncurrentVersionTransitions": [
        {
          "NoncurrentDays": 30,
          "StorageClass": "GLACIER_FLEXIBLE_RETRIEVAL"
        }
      ]
    }
  ]
}

This rule transitions any non-current object version to S3 Glacier Flexible Retrieval after 30 days. Your active deployment packages remain in S3 Standard for fast access, while historical versions move to archival storage at a fraction of the cost.

For artifacts you need to retain for years but will rarely access again, consider a tiered approach: moving to Glacier Flexible Retrieval first, then to Deep Archive:

"NoncurrentVersionTransitions": [
  {
    "NoncurrentDays": 30,
    "StorageClass": "GLACIER_FLEXIBLE_RETRIEVAL"
  },
  {
    "NoncurrentDays": 365,
    "StorageClass": "DEEP_ARCHIVE"
  }
]

Strategy 2: Delete old versions you no longer need

If you don’t have a compliance requirement to retain every historical artifact, you can expire old versions outright:

{
  "Rules": [
    {
      "ID": "DeleteOldDeploymentPackages",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "deployments/"
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 14,
        "NewerNoncurrentVersions": 2
      }
    }
  ]
}

This rule keeps the 2 most recent non-current versions of each object (giving you a rollback path) and deletes anything older than 14 days beyond that. This aligns well with a deployment strategy where you want the ability to quickly roll back to your previous one or two releases, but don’t need to retain anything older.

Diagram showing the relationship between S3 object versions and Lambda function versions

Tracking object and function versions

With REFERENCE mode, there is a direct relationship between your S3 object version and your Lambda function version. We recommend the following practices:

  • Tag your objects with metadata from your CI/CD pipeline (commit SHA, build ID, pipeline run ID) so you can trace any deployed function back to the exact source that produced it.
  • Document the mapping between Lambda function versions (or aliases) and S3 object version IDs. This makes rollbacks straightforward: update the function to reference the previous object version.

Cross-account considerations

How you organize your artifact buckets across AWS accounts depends on your operational model:

  • Centralized artifact account: A single bucket in a shared-services or tooling account, with bucket policies granting cross-account s3:GetObject access to Lambda execution roles in workload accounts. This gives your platform team a single inventory of all deployment artifacts with consistent lifecycle, encryption, and access policies.
  • Per-account buckets: Each workload account owns its own artifact bucket. Requires less effort to set up, but harder to enforce consistent governance across many accounts.

Either pattern works with self-managed storage. Choose based on how your organization balances centralized control against team autonomy.

Cross-Region considerations

With REFERENCE mode, your S3 object is the authoritative copy for your function. Self-managed code storage supports cross-Region function creation within a partition for all default Regions (non-opt-in Regions). You can store your code packages in one Region and deploy your functions in another. This makes cross-Region planning critical. There are four factors to balance:

Disaster recovery

This is the most critical consideration. Because your S3 object is the single source of truth in REFERENCE mode, you do not want all your deployment artifacts in a single Region with no fallback. A recommended pattern:

  1. Primary Region: Your main artifact bucket where CI/CD pipelines deposit new deployment packages.
  2. Fallback Region: A secondary bucket populated via S3 Cross-Region Replication (CRR). If your primary Region becomes unavailable, you can update your Lambda functions to reference the replicated objects in the fallback Region.

Enable S3 Replication Time Control (RTC) if you need a guaranteed SLA (15 minutes) for replication completion.

Cost

Weigh replication + storage costs against per-deploy cross-Region data transfer. If you deploy frequently, storing replicated copies in each target Region is usually cheaper. For infrequent deployments, a one-time transfer may suffice.

Governance and data residency

Some organizations, particularly in regulated industries, have strict requirements about where code artifacts can reside. Before configuring cross-Region replication, confirm that your data is permitted to leave its current Region. Certain regulatory frameworks (for example, data sovereignty laws, FedRAMP boundaries) may restrict replication to specific Region pairs.

Performance

If your workload requires fast function creation and activation times, for example, in a CI/CD pipeline where deployment speed is critical, keep your S3 objects in the same Region where you are creating your Lambda functions. Cross-Region reads add latency to the initial code download, which directly impacts how quickly a new function version becomes active after deployment.

For workloads where creation speed is less critical (for example, batch processing functions that are updated infrequently), the latency of a cross-Region read might be acceptable and can simplify your architecture.

Things to know

Before adopting self-managed S3 buckets for your Lambda functions, keep the following in mind:

  • Availability: You can use this feature today in all AWS standard regions where Lambda is supported.
  • Pricing: There is no additional Lambda charge. You pay standard S3 costs for storage, and any cross-Region data transfer.
  • Maximum deployment package size: The existing limits apply: 250 MB unzipped.
  • Supported runtimes: All Lambda runtimes that support .zip deployment packages are compatible. Container image deployments are not affected by this feature.
  • Migration: You can switch an existing function from service-managed to self-managed storage by calling UpdateFunctionCode with the --s3-object-storage-mode REFERENCE parameter. Lambda recreates the function by referencing the object in your S3 bucket and deletes the saved copy.
  • Reverting: You can switch back to service-managed storage at any time by updating the function with --s3-object-storage-mode COPY. Lambda resumes copying the artifact to its internal bucket.
  • Object availability is your responsibility: In REFERENCE mode, Lambda depends on your S3 object being accessible. If the object is deleted, the bucket policy changes, or the KMS key is disabled, new invocations requiring a cold start will fail.

Conclusion

In this post, we showed how self-managed S3 buckets for Lambda give you more capacity, more control, and simpler compliance, all without changing how you write or invoke your functions. Your deployment packages no longer count against account quotas, your security team can apply the same policies to code artifacts that they apply everywhere else, and your disaster recovery story is as strong as the replication capabilities of S3.

To get started:

Когато умира дете. Палиативни грижи в края на живота

Post Syndicated from Надежда Цекулова original https://www.toest.bg/kogato-umira-dete-paliativni-grizhi-v-kraya-na-zhivota/

Когато умира дете. Палиативни грижи в края на живота

От началото на тази поредица (а и доста преди нея) непрекъснато обясняваме, че съвременните палиативни грижи са много повече от „грижи в края на живота“. И все пак те са и това. Понякога сред пациентите, които се нуждаят от палиативни грижи в края на живота, има и деца. 

Децата страдат и умират. Но в болестта и в смъртта си те остават деца със своите детски нужди и особености – разбиране, което, както видяхме в предходните текстове от поредицата „Да говорим с грижа“, не е утвърдено в българския публичен дебат и публични политики. Нашите държавни системи не са пригодени да подкрепят детството нито в живота, нито в смъртта.

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

В България няма ясна система за детски палиативни грижи. Няма медицински стандарт, специалност, научно дружество или какъвто и да е друг формален документ или орган, които да регламентират какви са добрите практики в грижите за деца със заболяване, преминаващо в терминален стадий. Съществува клинична пътека, която обаче е по-скоро механизъм за заплащане на медицински дейности и гарантира до 30 дни болничен престой на онкологичен пациент в рамките на последните 6 месеца от живота му. 

А това е далеч от достатъчно – и като обхват на допустимите диагнози, и като обхват на допустимите дейности, и като продължителност на грижите, а в повечето случаи и като себестойност, заплащана от НЗОК за ден болничен престой по тази клинична пътека. 

Просто добави радост. Какво са съвременните палиативни грижи за деца

Разполагаме със здравна система, която все още не успява да се пречупи така, че да осигури детство там, където заболяването е отнело почти всичко друго. Как изглеждат детските палиативни грижи в България? Първи текст от новата поредица на Надежда Цекулова за детските палиативни грижи.

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

Когато умира дете. Палиативни грижи в края на живота
Когато умира дете. Палиативни грижи в края на живота
Когато умира дете. Палиативни грижи в края на живота
Когато умира дете. Палиативни грижи в края на живота
Когато умира дете. Палиативни грижи в края на живота

Сензорна стая в Клиниката по детска клинична хематология и онкология в УМБАЛ „Царица Йоанна“ – ИСУЛ

„Всъщност най-важното е да си човек“

Едно от местата, в които детската смърт не може да бъде забранена тема, е Клиниката по детска клинична хематология и онкология в УМБАЛ „Царица Йоанна“ – ИСУЛ в София. Там годишно се лекуват средно стотина деца, 50–60 от които са новодиагностицирани. 

Между 10 и 15 са случаите, в които оказваме палиативна грижа, като не във всички това е грижа в края на живота“, 

разказва клиничната психоложка Камелия Стоянова. И там, както и в Центъра за настаняване от семеен тип на деца с потребност от постоянни медицински грижи, за които разказахме в предишния текст, палиативните грижи невинаги се наричат така, пояснява Камелия. Самата тя е немска възпитаничка и продължава да прилага протоколи, познати от практиката ѝ в клиника в Германия. „Бихме могли да започваме по-рано с палиативните интервенции“, казва психоложката и допълва, че нагласата и на лекари, и на родители в България е да се гони упорито излекуването, понякога дори след като е пределно ясно, че няма как да бъде постигнато, докато „в Германия е по-различно“. 

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

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

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

Най-вече ги окуражаваме да не се страхуват да си обичат детето – дори и в последните моменти, когато това изглежда много страшно. Всъщност най-важното в тези моменти е наистина да си човек. Никоя техника, никоя добра практика не може да замени този човешки фактор.

Как да говорим за деца с тежки заболявания. Право, етика и човечност

Публичният разговор за тежко болните деца често се движи между две крайности – патетична жалост и почти пълно мълчание. Там някъде са и самите деца и семействата им. Как да се говори за страдание, без то да се превръща в сюжет? От Надежда Цекулова.

„Подкрепата от родителя е незаменима“

На човешкия фактор разчитат и в Клиниката по детска анестезиология и интензивно лечение на УМБАЛСМ „Пирогов“ в София – друго лечебно заведение, в което оказват грижи за деца в края на живота им. През детската реанимация на „Пирогов“ преминават около 400 деца годишно, като повечето от тях получават краткосрочни грижи след хирургични процедури. Между 10 и 15 деца постъпват в клиниката с нужда от грижи в края на живота. Към 8 юли тази година починалите са осем, пет от които са били деца с онкологични заболявания и са прекарали там последните часове или дни от живота си. 

В тези случаи работата на екипа вече е насочена не към излекуване, а към спиране на дискомфорта – болка, задух, страх. 

Това, което със сигурност можем да обещаем и да гарантираме, е, че няма да има страдание, 

казва доц. Богдан Младенов, началник на клиниката.

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

Ако детето е достатъчно стабилно и родителите имат желание и възможност да се грижат за него, то може да се прибере у дома. „Нашето старание, когато имаме такова детенце, е винаги когато може, то да си е с близките – дали вкъщи, дали в болнично отделение. Да прекара максимално време, по възможност качествено време, обезболено, с близките си. Да не го отнемаме от тях“, обяснява доц. Младенов. 

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

Самата клиника по реанимация и интензивно лечение е построена във време, когато присъствието на родителите не е било част от представата за медицински грижи, и пространството не позволява те да остават непрекъснато до леглото. Официалното свиждане е кратко – 30 минути в денонощие. Доц. Младенов разказва, че когато е ясно, че животът на детето е към края си, екипът се опитва да не се придържа механично към ограничението. „Пускаме хората колкото пъти и за колкото време можем, когато няма работа – обяснява лекарят. – Насърчаваме ги да участват и в немедицинските грижи.“ 

Младенов е убеден, че присъствието на родителите в този момент е незаменимо – те могат да дадат на детето спокойствие, кураж и познатото усещане, че не е само̀: „Аз не мога да го направя вместо майката. Вместо бащата. Без семейството няма как. Особено при малки деца е абсурдно.“

Трудностите – административни и емоционални

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

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

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

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

Детските палиативни грижи в България остават почти невидими – и в законите, и в обществения разговор. Политиките свеждат темата до болници и терминални състояния, а медиите рядко говорят за качество на живот, достойнство, радост и игра. Цената я плащат децата и семействата им. От Надежда Цекулова.

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

Психологическите предизвикателства обаче често се оказват по-сериозни от административните. 

И в двете клиники има опити екипите да бъдат подготвяни за разговорите, за които по време на медицинското си образование невинаги са получавали достатъчно насоки. В ИСУЛ Камелия Стоянова организира семинари за комуникация в трудни ситуации. Това не е професионална супервизия (тя изрично подчертава, че не е супервайзър), а защитено пространство, в което членовете на екипа могат да разглеждат случаи, останали дълго в съзнанието им, и да се упражняват в разговори, преди да се наложи да ги водят с истинско дете или семейство. Групите са смесени, а участниците разменят ролите си, за да видят ситуацията и през погледа на другия. 

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

В „Пирогов“ част от лекарите са преминавали обучения, свързани с грижите за тежко болни деца, а през годините са организирани и обучения за съобщаване на лоши новини. Но доц. Младенов не смята, че това е умение, което се усвоява отведнъж. Пред екипа всеки път отново стоят въпросите колко надежда може да бъде оставена, как да се каже истината, кой трябва да присъства на разговора, дори как да седнат хората в стаята; къде е балансът между това родителите да разберат какво се случва, без да бъдат напълно сринати в момент, когато детето все още има нужда от тях. „Това ни е много трудно и колкото и пъти да ни обучават, всеки път ще ни е полезно“, признава специалистът. 

Подкрепящите грижи за семейството

В терминалния етап родителите са едновременно най-важната опора за детето и хората, които имат най-голяма нужда от подкрепа. Камелия Стоянова разказва, че почти неизбежно се появява и чувството за вина: „Има ли нещо, което направих, за да се случи това?“, питат родителите, а понякога дори не поставят под съмнение убеждението, че тежката прогноза е по тяхна вина. В същото време доц. Богдан Младенов подчертава колко важна остава подкрепата на майката и бащата за самото дете: 

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

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

Между лекарствата и играчките – да избягаме от медицинския модел

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

Професионалният траур

Камелия Стоянова споделя, че в тяхната клиника лечението обичайно е продължително, екипите изграждат отношения с пациентите и семействата им и загубата преминава през всички. „Болезнено е за екипа, когато загубим пациент. Това наистина се приема като лична загуба, защото всеки се бори да даде още малко – още малко качество на живот, още малко да се закрепи детето, още малко да поживее – казва тя. – Имам чувството, че понякога дори болката обединява много. Това сплотява по някакъв начин екипа.“ 

Психоложката работи с колегите си върху разбирането, че 

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

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

Детската реанимация на „Пирогов“ разполага три дни седмично с психолог, който разговаря с децата, когато това е възможно, с родителите им, а при нужда и с персонала. „Никой не обича да гледа как умират деца“, казва доц. Младенов и споделя, че понякога има особено тежки моменти. Неотдавна за период от около две седмици в клиниката умират три деца, като една от медицинските сестри се случва на дежурство и при трите. „Това е огромен емоционален товар, впоследствие няколко сестри искаха да напуснат“, признава Младенов.

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

От пожелателно стечение на обстоятелствата към дължими грижи

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

Как едно семейство ще преживее последния етап от живота и раздялата с тежко болно дете, зависи до голяма степен от специалистите, при които детето ще попадне – дали те ще разпознаят нуждите отвъд „медицинския модел“, дали ще имат уменията, условията и ресурса да отговорят на тези нужди. Но нито семействата трябва да разчитат на случайността да срещнат такива специалисти, нито специалистите трябва да остават сами с решенията, отговорността и траура си. Гарантирането и регламентирането на детските палиативни грижи в края на живота няма да заменят човечността, но може да я превърнат от пожелателно стечение на обстоятелствата в дължими грижи.

Когато умира дете. Палиативни грижи в края на живота

Настоящата публикация е създадена по проект „Да говорим с грижа: Палиативните грижи за деца през погледа на медиите“. Проектът се осъществява благодарение на най-голямата социално отговорна инициатива на Лидл България „Ти и Lidl“, в партньорство с Фондация „Работилница за граждански инициативи“, Български дарителски форум и Асоциация на европейските журналисти. Отговорността за съдържанието е на журналистката Надежда Цекулова и по никакъв начин не отразява официалните позиции на финансиращите организации.

Когато умира дете. Палиативни грижи в края на живота

NVIDIA Announces Expanded Jetson Thor Lineup with Mid-Range T3000 and T2000 Modules

Post Syndicated from Ryan Smith original https://www.servethehome.com/nvidia-announces-expanded-jetson-thor-lineup-with-mid-range-t3000-and-t2000-modules/

NVIDIA has announced the addition of two new mid-range boards to their Jetson Thor lineup, the T3000 and T2000, which will arrive in Q1’27. The new boards aim to be a cheaper offering for customers feeling pressured by the high cost of memory

The post NVIDIA Announces Expanded Jetson Thor Lineup with Mid-Range T3000 and T2000 Modules appeared first on ServeTheHome.

The collective thoughts of the interwebz