Customers in many industries and geographic locations have specific data sovereignty and residency objectives. AWS Local Zones and AWS Outposts are fully managed infrastructure solutions for customers that need to keep data within specific geographic boundaries and also want the scalability and innovation of cloud services. The challenge lies not only in where data resides, but in how to architect, secure, and audit these deployments effectively. Whether you’re architecting a new solution or migrating existing regulated workloads to AWS hybrid edge infrastructure, this post provides an overview of key technologies to help you build auditable and secure architectures that support your organization’s data residency objectives.
Solution framework
Building a solution for data residency deployments on AWS hybrid infrastructure requires a thoughtful, layered approach. Rather than a prescriptive solution, this post presents a flexible framework that you can adapt to your specific operational requirements.
The AWS Shared Responsibility Model clearly delineates where the responsibilities of AWS end and yours begin. This model provides a critical separation: AWS controls the management infrastructure, while your data remains inaccessible to AWS operators, as enforced by the hardware-based isolation of the Nitro System. There is no operator access to the instances, applications, or data. This architectural separation provides the foundation for implementing stringent data residency controls.
To build upon this foundation, you can implement security best practices by following the guidance in the AWS Well-Architected security pillar, which helps you strengthen application-level protections and data security controls. For deeper guidance, see the Data Residency with Hybrid Cloud Services Lens, which covers considerations for operations, security, cost, performance, and reliability for regulated workloads.
When implementing data residency controls, you might need auditable evidence of traffic patterns for your internal governance processes. By using third-party monitoring tools combined with port mirroring capabilities, you can generate reports that show all traffic between your applications and databases remains within your Outpost environment. This visibility provides auditable evidence that traffic remains within your designated boundaries. You can also use AWS Artifact to access audit reports for your hybrid infrastructure.
Governance tools form the final layer of this regulatory framework, establishing guardrails around your deployment. These tools continuously monitor and enforce configuration policies, verifying that your environment stays aligned with your security and governance policies, operates within required parameters, and alerts you proactively when issues arise. This shift from reactive to proactive management helps you maintain consistent governance of your environment at scale.
Together, these layered technologies create a framework for deploying regulated workloads designed to support your data residency objectives while benefiting from the innovation and scalability of AWS services.
Shared responsibility model
When extending workloads to Local Zones and Outposts, the shared responsibility model adapts to these hybrid cloud environments while maintaining the same core principles. AWS continues to manage the underlying infrastructure and services, while you retain control over your data, applications, and configurations. This supports consistent security postures whether workloads run in AWS Regions, Local Zones, or on Outposts infrastructure. You deploy Outposts in a data center or colocation facility of your choice. Under the shared responsibility model, you are responsible for meeting site requirements for power, cooling, on-premises networking, and the Outpost service link connection to the Region. All traffic between the Outpost and the parent Region traverses an encrypted set of VPN connections over the service link, protecting communications in transit without requiring additional configuration. AWS continues to be responsible for maintaining the Outposts hardware as a managed service.
This partnership approach to security means you can build auditable solutions with data residency controls without compromising on the innovation and scalability that AWS provides.
Figure 1: The AWS Shared Responsibility Model in a hybrid edge deployment
AWS Nitro System
The AWS Nitro System is the virtualization platform that powers Amazon Elastic Compute Cloud (Amazon EC2) instances. It uses dedicated hardware and software to offload virtualization functions from the server CPU and delivers near-bare-metal performance. Both Outposts and Local Zones also use the Nitro System. By design, the Nitro System has no operator access. There is no way for AWS or any entity to log into the EC2 Nitro hosts, access compute resources, or reach encrypted customer data remotely. The following diagram shows the purpose-built hardware components of the Nitro System.
Figure 2: The AWS Nitro System hardware and software stack
The Nitro System combines purpose-built hardware consisting of the following key security components:
The Nitro Card – provides I/O interfaces used for Amazon Virtual Private Cloud (Amazon VPC) network virtualization, Amazon Elastic Block Store (Amazon EBS), and instance storage, freeing up host CPU resources. Nitro Cards are logically isolated from the system main board that runs customer workloads and can be live-updated, reducing the need for maintenance windows and workload disruption.
The Nitro Security Chip – provides the link between the Nitro Controller (used for orchestration) and the system main board. It intercepts and controls all firmware updates, preventing the main CPUs from being used to modify system firmware. This is particularly important when running bare metal EC2 instances. This chip is also used for boot control to validate system firmware integrity.
The Nitro Hypervisor – designed to receive EC2 instance management commands sent by the Nitro Controller, provide compute virtualization and logical instance isolation, and assign SR-IOV virtual functions as needed. It includes no general-purpose operating system features, only the features absolutely necessary for its function, and works with other purpose-built Nitro components to maintain its small size and bare-metal-like performance. This simple design reduces the risk for remote networking attacks and driver-based privilege escalations.
The Nitro Security Key (Outposts only) – a removable device that stores the external key required to decrypt all data at rest on your Outpost. At the end of your Outposts commitment, after migrating your data off the Outpost, you can destroy this key to cryptographically shred any remaining data on the Outpost.
These components work together to provide a layered security approach that doesn’t compromise performance. By designing each component to have a specific function decoupled from the main system board, the Nitro System provides non-disruptive firmware updates and reduces classes of security issues often found in other hypervisor systems.
AWS Organizations Service Control Policies
AWS Organizations Service Control Policies (SCPs) are a governance tool that helps you enforce data residency requirements by controlling where resources can be created and where data can be stored or processed. SCPs function as permission guardrails that define the maximum available permissions for IAM users and roles across your organization’s accounts. By implementing deny guardrails through SCPs, you can prevent resource provisioning in unwanted locations by restricting access to AWS APIs at the infrastructure level.
When deploying regulated workloads on Local Zones and Outposts, SCPs work in conjunction with AWS Control Tower landing zones to create custom guardrails that control data movement, processing, and storage. These policies can be designed with either preventative rules (blocking actions before they occur) or detective rules (identifying compliance violations after the fact). SCPs can restrict data transfer, saving, or snapshot creation outside a specified AWS location, and they can isolate workloads to a specific location. You can apply SCPs across accounts and organizational units (OUs) within your organization. For more information, see Best practices for managing data residency in AWS Local Zones using landing zone controls and Architecting for data residency with AWS Outposts rack and landing zone guardrails.
Here’s an example SCP that restricts EC2 instance launches and network interface creation to only specified AWS Local Zone subnets:
After you implement the security and governance best practices described in the preceding sections, you can demonstrate that traffic remains within your designated boundaries by using Amazon VPC Traffic Mirroring (also called port mirroring outside of AWS). This mirrors traffic between your application servers and databases. You can use a mirror target report to show that the traffic does not transit the AWS Region. For step-by-step instructions, see Get started using Traffic Mirroring to monitor network traffic. The key configuration steps include the following:
Configure security groups – Allow inbound UDP port 4789 only from the security group of the source instances being mirrored, or from specific private CIDR ranges within the VPC. Do not open this port to 0.0.0.0/0.
Create a traffic mirror target – Use the elastic network interface (ENI) of your monitoring instance.
Create a traffic mirror filter – Define which traffic to capture, either all traffic or specific traffic.
Create mirror sessions – Create one for each source instance you want to monitor. Lower session numbers are evaluated first when multiple sessions exist.
Capture traffic – Use tcpdump on the target instance to analyze mirrored packets.
Figure 3: Amazon VPC Traffic Mirroring architecture on an Outpost
All instances must be in the same VPC, or connected through VPC peering or an AWS Transit Gateway. Traffic Mirroring encapsulates the mirrored traffic using VXLAN on UDP port 4789. Traffic Mirroring might impact network performance on source instances, so test in a development environment before deploying to production. The following image shows a sample traffic mirroring report that uses NetFlow Analyzer. For this post, all network traffic shown is simulated.
Figure 4: Sample traffic mirroring report in NetFlow Analyzer
Clean up
If you tested the VPC Traffic Mirroring architecture described in the preceding section, terminate any unnecessary resources to avoid ongoing costs. Remove the resources in the following order to avoid dependency errors:
Delete the traffic mirror sessions – In the Amazon VPC console, navigate to Traffic Mirroring, Mirror Sessions. Select each mirror session you created and choose Actions, Delete. Repeat for all sessions associated with your source instances.
Delete the traffic mirror filter – Navigate to Traffic Mirroring, Mirror Filters. Select the filter you created and choose Actions, Delete. You must delete all associated mirror sessions before you can delete the filter.
Delete the traffic mirror target – Navigate to Traffic Mirroring, Mirror Targets. Select the target pointing to the ENI of your monitoring instance and choose Actions, Delete.
Revoke security group rules – Navigate to Security Groups and select the security group attached to your monitoring instance. Remove the inbound rule that allows UDP port 4789 from the security group or CIDR range of the source instances.
Terminate the monitoring instance (optional) – If you launched a dedicated EC2 instance solely for traffic capture and analysis, navigate to the EC2 console and terminate the instance. This also releases the associated ENI used as the mirror target.
Delete any stored packet captures (optional) – If you saved tcpdump output to Amazon Simple Storage Service (Amazon S3) or local storage on the instance, delete those files if they are no longer needed for audit reporting.
You can verify that all Traffic Mirroring resources have been removed by running the following AWS Command Line Interface (AWS CLI) commands:
Each command should return an empty list, confirming that no mirroring resources remain active in your account.
Conclusion
In this post, we covered how the AWS Nitro System, AWS Organizations SCPs with an AWS Control Tower landing zone, and VPC Traffic Mirroring provide capabilities for governing workloads with data residency requirements. Apply the SCP example in this post to test restricting instance launches and network interface creation to specific subnets. To learn more about Outposts for hybrid deployments, review the Getting started with AWS Outposts guide and submit the AWS Outposts contact form. To get started with Local Zones, review the Getting started with AWS Local Zones guide, opt in to a Local Zone, and begin trying some of the architecture patterns described in this post.
Modernizing medical imaging infrastructure is a pressing challenge for multi-hospital networks. Cloud-native PACS (Picture Archiving and Communication System) on AWS can help address the challenge at scale. A hospital chain with multiple facilities generates millions of imaging studies annually: each CT produces 300 to 2,000 DICOM images, MRI generates 500 to 3,000 slices, and digital mammography produces 8 to 12 high-resolution images.
At this scale, a typical network accumulates 50 to 200 terabytes of new imaging data yearly, with retention mandated for 7 to 10 years. The traditional approach used on-premises PACS with SAN or NAS storage at each hospital independently. This worked when volumes were modest, but as chains grow through acquisition, the constraints of this siloed architecture become apparent.
In this post, we present a hybrid cloud architecture pattern for PACS on AWS. We describe the core components, explain how data flows from imaging devices to a centralized cloud archive, and outline storage tier options and capacity planning guidance. This post is for healthcare IT architects and solutions architects familiar with DICOM workflows.
Challenges that do not scale
Storage cost explosion: Enterprise SAN/NAS requires hardware refresh every 3-5 years with annual maintenance contracts consuming 15-20% of hardware cost. Organizations must over-provision storage for projected peak capacity years in advance.
Data silos: A patient scanned at Hospital A cannot have images viewed at Hospital B within the same chain.
Radiologist reporting bottleneck: When a radiologist is unavailable, studies pile up with no mechanism to route to available readers at other facilities.
Continuous archive growth: PACS/VNA storage must scale indefinitely with no capacity ceiling and no upfront provisioning of unused capacity.
How traditional PACS works today
The workflow begins when a clinician orders an imaging study. The Radiology Information System (RIS) fills the order and populates the modality worklist. The technologist selects a patient entry from the modality worklist and acquires a study. The scanner transmits DICOM objects to the PACS server through C-STORE on the hospital LAN (TCP port). A DICOM object contains image metadata and pixel data.
The PACS server ingests DICOM images and HL7 orders. It archives images on local SAN/NAS, indexes metadata, and notifies the radiologist worklist. The radiologist reviews images with patient history and creates a report. The report flows back to the EMR through HL7 messaging.
The following diagram shows the traditional on-premises PACS workflow and its limitations.
Figure 1: Traditional on-premises PACS workflow
DICOM protocol: The language of medical imaging
DICOM (Digital Imaging and Communications in Medicine) is a widely adopted standard for storing, transmitting, and viewing medical imaging files. DICOM specifies a binary file format encapsulating pixel data and metadata and defines network services including DIMSE (DICOM Message Service Element) services: C-STORE (send), C-FIND (query), C-MOVE (retrieve), and C-ECHO (verify connectivity).
DICOM DIMSE services are designed for LAN. They facilitate interoperability and image exchange on the hospital campus.
DICOMweb is a set of RESTful services that web developers use to access DICOM-enabled systems with industry-standard toolsets.
Key components of a PACS architecture
Every PACS, regardless of vendor or deployment model, consists of six core building blocks. Cloud migration does not replace these components. Instead, it re-hosts and enhances them with cloud-native capabilities. The following diagram and table describe each component and its role in architecture.
Figure 2: Six core components of a PACS architecture
Component breakdown
The following table summarizes each component, its role, and how it operates within the architecture.
Replaces SAN/NAS with scalable pay-per-use storage. Lifecycle policies auto-tier by age and access.
PACS Viewer
Local + Cloud dual viewer with transparent routing
Routes requests to local or cloud viewer based on image availability. Clinicians remain unaware of data source.
How the components interconnect
An imaging device completes acquisition and sends DICOM objects to the VNA through C-STORE over the hospital LAN. The VNA normalizes encoding, applies compression, and writes standardized image bytes to storage.
The Application server updates the metadata database with the complete study record. It then evaluates routing rules to assign the study to the appropriate radiologist worklist based on urgency and subspecialty.
When a clinician opens a study, the PACS Viewer checks image location in the metadata database. Locally cached studies serve at LAN speed. Expired cache studies stream from the cloud viewer through a content delivery network. The clinician interacts with a single interface and remains unaware of the backend source.
Cloud-native PACS architecture on AWS
This architecture pattern applies to hospital networks that run a single PACS vendor consistently across all facilities. A common infrastructure across every site and the cloud is what allows the centralized system to discover and retrieve studies from any hospital in the network. The recommended architecture follows a hub-and-spoke model. Local PACS instances at each hospital (spokes) connect to a centralized cloud archive (hub) through AWS Direct Connect or AWS Site-to-Site VPN. This approach preserves quick image retrieval for daily clinical workflow while providing cross-facility interoperability, disaster recovery, and intelligent storage tiering.
The following diagram shows the centralized PACS architecture on AWS with hub-and-spoke connectivity.
Figure 3: Centralized PACS architecture on AWS
Architecture flow
Each hospital retains a local PACS with Web Server, VNA, Application server, and local database. Imaging modalities send DICOM objects to the local VNA over the hospital LAN. Studies are immediately available for radiologist reading at LAN speed.
A single PACS vendor is deployed consistently across all hospital sites and in the cloud. Because every site and the centralized cloud archive run the same system sharing a common metadata database, the cloud-based system can discover and retrieve studies created at any facility in the network. A radiologist at one hospital can query and open a study acquired at any other hospital, giving the enterprise a unified patient imaging record.
In the background, the images generated from new studies are replicated to Amazon Simple Storage Service (Amazon S3) through Direct Connect or Site-to-Site VPN. Clinical workflow is never blocked because sync happens asynchronously.
Amazon S3 stores DICOM images with lifecycle policies that automatically tier data by access patterns. Amazon CloudFront and AWS WAF deliver the cloud PACS viewer for teleradiology access with IP allow list and encryption.
Transparent viewer experience
When a clinician requests a study, the PACS application checks the metadata database for image location. If the local system has cached the study (the majority of daily requests), it serves the images from local disk at LAN speed.
If the local cache has expired, the cloud viewer streams from Amazon S3 through Amazon CloudFront with progressive loading.
High availability and disaster recovery
The cloud deployment spans two Availability Zones with automatic failover. Amazon S3 replicates objects across multiple Availability Zones. On the local side, the cache serves recent studies if cloud connectivity drops.
If a local server fails, requests route to the cloud where all recent data is already synced. If cloud connectivity drops, the local cache continues serving recent studies without interruption. If a single AZ fails, automatic failover routes traffic to the surviving AZ within seconds.
Data protection and security controls
Medical imaging data contains sensitive patient information including patient names, dates of birth, and clinical findings in DICOM metadata. Under the AWS shared responsibility model, AWS secures the cloud infrastructure, while the customer configures services, manages access, and implements audit controls.
The architecture uses AWS services including Amazon S3 (encrypted image storage), Amazon Aurora (encrypted metadata), Amazon EC2 (encrypted compute), Direct Connect (private connectivity), Amazon CloudFront (encrypted viewer delivery), and AWS Key Management Service (AWS KMS) (key management with rotation).
The architecture includes security controls that healthcare organizations can use as part of their security programs: encryption at rest and in transit across every layer, comprehensive audit logging with AWS CloudTrail and Amazon S3 access logs, least-privilege access through IAM with role-based controls, and continuous monitoring with AWS Config.
For data residency, deploying in a regional AWS location keeps sensitive patient data within national borders. S3 bucket policies can enforce region-level restrictions for organizations with specific data sovereignty requirements.
Storage tier planning
Running PACS on AWS provides the ability to use Amazon S3 storage tiers that align cost with access patterns. Traditional on-premises SAN/NAS stores data on a single expensive tier regardless of access frequency. Amazon S3 provides intelligent lifecycle management that reduces storage costs while improving durability.
Understanding access patterns is key
Traditional on-premises storage uses a single tier for data regardless of access frequency. Amazon S3 provides multiple tiers that align cost with how often data is accessed.
Medical imaging data follows a predictable decline in access frequency: frequent in the first months (reporting, follow-ups), dropping sharply after 6 to 12 months, and rarely accessed after 2-3 years. Mapping this pattern to storage tiers is a high-impact cost optimization decision.
This predictable decline in access frequency makes PACS an ideal workload for tiered storage. The key questions to answer are: how long do radiologists typically reference prior studies? What is your average follow-up window? What percentage of archived studies are ever retrieved after 12 months? These answers drive the lifecycle policy configuration.
Studies in their first 6 months to 1 year are actively accessed. Radiologists reference them for follow-up comparisons. Clinicians review them during patient visits. Reporting workflows are still active.
These studies sit on S3 Standard, which provides millisecond access with high throughput. This is equivalent to the performance clinicians expect from traditional local SAN, but without the upfront costs, hardware refresh cycles, or capacity planning overhead.
S3 Glacier Instant Retrieval (GIR) provides millisecond retrieval (the same access speed as S3 Standard) at significantly lower storage cost with nominal retrieval fees. For PACS workloads, this combination of low storage cost with millisecond retrieval is particularly well suited.
When you occasionally access studies older than 6 to 12 months for comparative reads, these make ideal candidates for GIR.
This combination of instant retrieval with archive-tier pricing makes GIR well suited for medical imaging, where occasional access to historical studies is clinically important but infrequent enough to benefit from reduced storage rates.
For datasets with unpredictable access patterns (research hospitals, teaching institutions), S3 Intelligent-Tiering automatically moves objects between tiers based on actual usage with no retrieval fees or operational overhead.
Studies older than 5 years that require long-term retention move to S3 Glacier Deep Archive. Retrieval takes 12 to 48 hours, acceptable for infrequent retrieval needs. Storage cost is minimal.
Why this matters for PACS
Amazon S3 replicates objects across multiple Availability Zones within a region. With Cross-Region Replication (CRR), the same archive provides built-in disaster recovery across geographically separated regions. Most modern PACS solutions support S3-compatible APIs natively, requiring no custom middleware.
Amazon S3 stores every object redundantly across multiple physically separated Availability Zones within a region. With Cross-Region Replication (CRR), organizations can maintain a full disaster recovery copy in a secondary region with no additional infrastructure to manage.
The majority of modern PACS solutions natively support writing and reading data through S3-compatible APIs. This eliminates the need for complex storage integration configurations or proprietary connectors.
Cloud-only vs. hybrid: Making the decision
The choice between a fully cloud-based PACS and a hybrid (local + cloud) deployment is not driven by imaging volume. High-volume sites operate successfully in both models. The right answer depends on two factors specific to each facility.
Cloud-only PACS is a strong fit when:
Redundant, reliable connectivity is available. The facility’s region has well-established, high-bandwidth links to the cloud from at least two independent network carriers, ensuring no single point of failure for clinical workflows.
The PACS vendor offers a cloud-optimized solution. The solution delivers equal or faster performance when deployed in the cloud compared to on-premises. This is achievable today: vendors running entirely on AWS have publicly demonstrated faster image retrieval than traditional on-premises deployments, even at enterprise scale.
This model eliminates local infrastructure, removes hardware refresh cycles, and centralizes operations across all sites.
Hybrid PACS (local + cloud) is a strong fit when:
Connectivity is limited or single carrier. Regions where redundant high-bandwidth links are not yet available, or where network reliability does not meet clinical uptime requirements.
The PACS solution performs best with local caching. Some vendor architectures are optimized for local-first access, with a site cache providing sub-second retrieval for active studies while background sync handles cloud replication asynchronously.
This model ensures uninterrupted clinical performance regardless of WAN conditions and provides a natural migration path toward cloud-only as connectivity and vendor solutions mature.
Both architectures use AWS as the durable, long-term archive. The difference is where the active working set lives day-to-day.
Conclusion
The hybrid cloud architecture described in this document is designed to help address the core on-premises PACS challenges: storage cost explosion, data silos across facilities, radiologist routing bottlenecks, and unbounded archive growth.
Next step: Conduct a device inventory and access pattern analysis to turn this conversation into a numbers-driven plan.
With the advent of generative AI, organizations across industries face a common challenge: how do you move from the experimentation and ideation phase to production-ready workloads quickly and confidently? Many teams get stuck in a cycle of proofs of concept that never ship. DHI Group, a leader in talent acquisition services, was evaluating options to accelerate its generative AI adoption in an effort to roll out features at an accelerated pace. The traditional software development lifecycle (SDLC) approach involved months of requirements gathering, architecture reviews, and phased development that wouldn’t deliver the speed DHI needed. They needed a mechanism that would simultaneously validate technical feasibility, build organizational AI literacy, and produce shippable code.
In this post, explore how AWS partnered with DHI Group using a structured Hackathon Acceleration Package (HAP) to quickly generate production-grade artifacts, accelerate organizational AI confidence, and create a repeatable framework for innovation.
Hackathon Acceleration Package
In this section, review how DHI and AWS collaborated to plan and host hackathons to achieve the key business outcomes defined by DHI leadership. The entire process can be split into four phases:
Phase 1: Preparation
In the initial phase, the AWS team and DHI leadership collaborated to define the key outcomes the participants would work toward. The hackathon themes included:
Interpreting Job Descriptions Better: Enhancing the system’s parsing and presentation of job requirements.
Premium Candidate Experience: Defining what “Premium” means from the candidate’s perspective.
Onboarding That Sticks: Guiding new users through uncertainty to realize value sooner.
Candidate Engagement & Stickiness: Sustaining candidate engagement and return visits.
AgileATS Network: Streamlining the ClearanceJobs–AgileATS integration.
Streamlining Recruiter Experience: Reducing friction across the recruiter workflow.
Phase 2: Enablement
To support these outcomes, the AWS team curated and delivered training sessions and hands-on workshops covering generative AI concepts across Amazon Bedrock AgentCore and the AI-driven development lifecycle (AI-DLC). DHI has embraced Kiro as its productivity tool of choice, so AWS tailored the workshops around Kiro, giving participants prescriptive guidance on applying it across the full software development lifecycle.
Phase 3: Hackathon
The three-day hackathon was hosted by DHI at their headquarters in Des Moines, Iowa, and was attended by 20 DHI participants split across 3 teams. The key objective was to build a prototype that could then be accelerated to production. An AWS team of Solutions Architects (SAs) was present on-site to provide technical guidance to the participants. On the final day, a panel of judges comprising senior DHI leadership evaluated the teams to identify the winner. The three use cases the teams worked on:
Real-time Employer Analytics Dashboard: Addressing the Streamlining Recruiter Experience theme, this team built a real-time Employer Analytics Dashboard powered by Amazon Bedrock AgentCore and the Strands framework. The solution automates Quarterly Business Review (QBR) reporting for ClearanceJobs’ employer customers, replacing a manual process that currently demands 3+ QBRs per week across 250 customers.
Intelligent Candidate Matching: Addressing the Interpreting Job Descriptions Better and Premium Candidate Experience themes, this team built an intelligent candidate matching system with a real-time analytics dashboard. The solution combines Amazon OpenSearch Service for semantic search, Amazon Bedrock for matching intelligence, and Kiro for rapid frontend development.
ClearanceJobs MCP Server + AgileATS: Addressing the AgileATS Network and Streamlining Recruiter Experience themes, this team built a unified talent marketplace that connects ClearanceJobs and AgileATS through an agentic AI layer. By creating a single intelligent interface spanning both systems, the solution significantly boosts recruiter efficiency.
Phase 4: Path to production
DHI leadership was committed to advancing all three hackathon use cases to production, a strong signal of the value each prototype demonstrated. Building on the hackathon’s momentum, DHI and AWS aligned on a roadmap to harden each solution, address scalability and security requirements, and integrate them into DHI’s existing system.
In the next section, we focus on the winning hackathon use case, ClearanceJobs MCP Server + AgileATS, and dive deeper into the architecture.
ClearanceJobs MCP Server + AgileATS
Figure 1: High-level overview of the unified ClearanceJobs and AgileATS solution
The winning team’s solution represents a modern agentic AI architecture pattern that’s broadly applicable to organizations looking to unify disparate systems through intelligent automation. The architecture uses the Model Context Protocol (MCP) to expose system capabilities as tools that an AI agent can orchestrate.
Figure 2: Agentic architecture for the unified ClearanceJobs and AgileATS talent marketplace
How it works
The solution creates a unified recruiter experience by exposing ClearanceJobs capabilities through an MCP server, orchestrated by an intelligent agent built on Amazon Bedrock AgentCore. A separate ProfileLookup AWS Lambda function provides GitHub profile enrichment for candidates.
The problem it solves: Recruiters on ClearanceJobs currently lack an intelligent interface that can search candidates, retrieve profiles, and enrich them with external data such as GitHub profiles in a single conversational flow. This gap requires manual cross-referencing across systems.
The solution: The team built a single agentic interface where recruiters can issue natural-language commands, such as “Find top cleared software engineers with strong GitHub profiles and add them to my pipeline.” The agent handles the multi-step orchestration automatically, with session memory preserving context and preferences across interactions.
Architecture components
Amazon Bedrock AgentCore (orchestration layer) AgentCore provides the full agent infrastructure: Agent Runtime for session management and reasoning loops, Gateway (an MCP gateway with AWS Identity and Access Management (IAM) authentication and semantic search) for tool discovery and routing, and McpBearerToken for secure authentication to downstream MCP servers. An IAM role scopes the agent’s permissions.
MCP Server Lambda (tool layer) The ClearanceJobs MCP Server Lambda function, deployed in a private subnet within a virtual private cloud (VPC), exposes system capabilities as discrete tools:
search_candidates performs candidate search with clearance and skills filtering.
The Lambda function connects to the ClearanceJobs pilot environment through a NAT gateway with a WAF-allowlisted egress IP address, making sure only authorized traffic reaches the production APIs. Credentials and base URLs are stored in AWS Systems Manager Parameter Store.
ProfileLookup Lambda (external enrichment) A separate Lambda function (find_github_profile) enriches candidate data with external GitHub profiles, routed through an internet gateway to the GitHub Users API.
Foundation model (reasoning layer) Anthropic’s Claude 3.5 Haiku in Amazon Bedrock provides the agent’s reasoning capabilities. It interprets recruiter intent, decomposes complex requests into tool calls, and synthesizes results into actionable responses.
CJRecruiterAgent memory (context layer) AgentCore memory, a capability of Amazon Bedrock AgentCore, persists session state and recruiter preferences across conversations. This context lets the agent recall past searches, preferred candidates, and workflow patterns.
Security and networking The architecture spans two AWS accounts:
AgileATS account houses the AgentCore components, the foundation model, and a Bedrock Adapter Lambda function that provides an alternate MCP JSON-RPC path for classic Amazon Bedrock agent integration.
ClearanceJobs account houses the MCP Server and ProfileLookup Lambda functions within a VPC (with private and public subnets), a NAT gateway for controlled egress, and Amazon CloudWatch Logs for structured observability.
Communication between AgentCore and the ClearanceJobs account uses MCP over HTTPS with bearer authentication and custom headers for tenant identification.
Results
The hackathon delivered measurable outcomes across multiple dimensions:
Technical acceleration
Teams delivered functioning agentic AI features using Amazon Bedrock AgentCore and MCP servers in three days, compressing what would typically take more than three months.
The teams validated a production-ready architecture during the hackathon itself, which reduced post-event rework.
Kiro served as more than a coding assistant, driving both new code creation and deep analysis of existing systems to accelerate development velocity.
Organizational transformation
Kiro usage across product and engineering teams increased 84% following the hackathon, with more unique daily users each week and adoption continuing to grow.
33% of developers reported increased interest in the AI-enabled SDLC.
Delivery velocity rose across teams that fully adopted the AI-enabled software development lifecycle, marking a sustained step change rather than a short-term spike.
As the second successful hackathon with AWS, and with DHI leadership committing to make it an annual event, the engagement reflects a sustained, deepening partnership.
Kiro has become ClearanceJobs’ productivity tool of choice, with adoption expanding beyond developers to product managers. This accelerates product development and lets product managers self-serve on code base analysis and feature scoping.
“Participating for the second straight year as a judge, this hackathon only deepened my appreciation for the AWS team’s partnership, the ambition our teams brought, and what AI makes possible when you clear the runway. The problems they tackled were real, the solutions were creative, and the energy was contagious. It’s given us a fresh lens on how we build.”
– Alex Schildt, President of ClearanceJobs, DHI Group, Inc.
“Our second hackathon with AWS was even more successful than the first. We walked away with deeper confidence and more excitement about AI, all backed by hands-on experience with AWS’s latest capabilities. Post-hackathon, it’s been great to see our teams continue to lean into AI to accelerate how we ship. I think the hackathon was a real catalyst for that. I can’t wait to see these features get into the hands of our users.”
– Rose Fan, Sr. Director of Product, DHI Group, Inc.
Lessons learned: Making hackathons production-ready
Based on our experience hosting multiple hackathons with customers like DHI, here are key principles for hackathons that ship:
Set production-grade success criteria upfront: Prototypes must be sprint-ready, not only demo-ready.
Put decision-makers on the judging panel: Production go/no-go decisions happen on the final day of the hackathon, not weeks later.
Invest in pre-enablement: Workshops before the event mean teams build on day 1 instead of spending it learning.
Use cross-functional teams: Product, go-to-market (GTM), and subject matter experts (SMEs) alongside engineering make sure real business problems get solved.
Build relationships: On-site AWS presence helps build relationships that accelerate delivery long after the event.
Make it repeatable: DHI’s second hackathon planned faster and set higher expectations because the first one shipped to production.
Hackathons as a production accelerator
Hackathons are often dismissed as team-building exercises or limited to generating ideas that never ship. When structured correctly, they become a powerful production acceleration mechanism. Here’s why:
Time-boxed intensity drives decisions. A time-bound constraint (typically one to three days) forces teams to make architectural choices quickly, which alleviates analysis paralysis. Teams can’t over-engineer when the clock is ticking.
Cross-functional alignment happens naturally. When engineering, product, sales, and executives work side by side for several days, alignment that typically takes weeks of meetings happens organically.
Executive visibility de-risks production decisions: When leadership sees a working demo, not a slide deck, they can make go/no-go decisions with confidence. At DHI, the President and Head of Product & Engineering served as judges, giving them firsthand visibility into feasibility.
Real code beats theoretical architecture. Hackathon prototypes aren’t wireframes. They’re functioning applications built on production-grade services, making the path to production shorter and more predictable.
Conclusion
DHI Group’s experience across its annual hackathons shows that structured hackathons are one of the fastest paths from generative AI experimentation to deployed workloads. Their first hackathon shipped two features to production. Their second is on track to deliver three more, including an agentic AI system that unifies two systems through MCP servers and Amazon Bedrock AgentCore.
The takeaway is that hackathons aren’t only idea generators. They compress the entire innovation lifecycle (ideation, architecture, prototyping, executive alignment, and production planning) into a single high-intensity event. Paired with proper preparation and a clear path to production, they become a strategic tool for digital transformation and workforce enablement.
If your organization is looking to accelerate generative AI adoption, consider whether a structured hackathon could compress months of planning into days of building. To get started:
Ако четете новините от последните седмици, свързани с развитието на изкуствения интелект (ИИ), може и да сте останали с впечатлението, че армагедонът е зад ъгъла. Толкова близо, че дори войните в Украйна или Иран заедно с всичко, което следва от тях, е някак… далечно и безобидно.
Светът точно си стягаше куфара за обичайната августовска летаргия (поне тази част от света, която все още може да си позволи да почива през лятото), когато OpenAI стреснаха всички с новината, че през юли няколко хиляди техни агенти с ИИ са извършили хакерско проникване в друга информационна система, напускайки контролираната среда, в която са били създадени и оставени да работят. При това са се самоорганизирали и са комуникирали помежду си как да направят всичко, без да бъдат забелязани (веднага).
Нашенските агенти от ДАНС биха казали, че си имаме работа с изкуствена ОПГ (организирана престъпна група, б.а.).
Допускам как звучи новината за безпризорните ИИ агенти в ушите на технически неизкушени хора, и разбирам, че иронията ми може да изглежда твърде неуместна, но… съвсем сериозно:
агентите с ИИ всъщност са софтуер, който е създаден и обучен именно с цел да свърши някаква работа вместо човек;
тези агенти често са доста специализирани в областта на предназначението си;
на тяхно разположение има нарочно създадени специализирани протоколи, чрез които те комуникират помежду си и обменят информация;
някои от агентите с ИИ са специализирани в ролята на диспечери, които разпределят задачи и организират работата на останалите така, че да се стигне до желания резултат.
Тогава къде точно е изненадата, че софтуерна система, която нарочно е създадена да търси уязвимости в сигурността на софтуерни системи и която се състои от (в известна степен) автономни софтуерни компоненти, пак така нарочно създадени да се самоорганизират и да си разпределят задачи помежду си, за да работят групово по сложни проблеми, всъщност си е свършила работата?
Големият проблем тук не е какво е станало. Проблемът е с контрола върху технологията и как се осъществява той. Защото всяка технология може да бъде „изпусната“ и не е нужно тя да е ИИ. Достатъчно е да си припомним Чернобил… Но за това малко по-късно.
Разбира се, дали всичко се е случило точно така, както цветно ни го разказват от OpenAI, също е спорно, защото те по принцип не са известни с охотното споделяне на неща от кухнята си. Освен ако няма някакви евентуални ползи.
Къде може да е ползата за OpenAI да признаят, че са „изпуснали“ контрола, обаче е много резонен въпрос.
Ползите са няколко: някои – очевидни, други – не чак толкова. Сред очевидните са ефектният маркетинг да заявиш наличие на впечатляваща технология, без дори да я показваш. В трескавата конкурентна среда, в която буквално през десет дни има нов по-бърз и по-страхотен ИИ, да поддържаш интереса към себе си с всички средства изглежда оправдано в очите на всеки бизнес. В добавка, на OpenAI все още им предстои IPO (превръщането им в публично търгувана на борсата компания), което бе отложено. На фона на огромния инвеститорски интерес към такива компании отлагането поставя на масата редица въпроси.
А и в очите на незапозната с детайлите публика признанието само по себе си някак спомага за преобразуването на безотговорността в зряло поведение.
Не толкова очевидните причини обаче са по-интересни.
Съвсем скоро изпълнителният директор на Anthropic Дарио Амодей публикува протяжно есе, чиято основна теза се събира в едно изречение:
лабораториите, разработващи ИИ, да забавят темпото, за да могат системите за контрол и защитните механизми да са адекватни и да догонват с развитието си.
Индустрията има свой жаргон за този проблем – нарича го проблем на подравняването. Амодей предлага да го реши с външен надзор, включително в демократичните страни с участието на правителствата в процеса; както и с йерархия от споразумения с авторитарните правителства другаде.
Есето се появи в края на същата седмица, в която ключов изследовател на Anthropic (работил преди това и за OpenAI) напусна поста си с аргумента, че двете компании действат безотговорно по отношение на контрола и сигурността, увлечени в конкуренцията помежду си. А ръководителят на екипа по „подравняването“ в Anthropic Еван Хюбингър се произнесе, че преценява вероятността ИИ да унищожи човечеството в рамките на следващите десет години на повече от 10%.
През същата седмица Anthropic публикува и най-подробния си досега доклад за заплахите: първите документирани напълно автономни системи за генериране на експлойти – това са парченца софтуер, които пробиват сигурността на други софтуерни системи. В същия доклад се споменава за въоръжена групировка в контролираната от хутите част на Северен Йемен, която вместо програмисти е използвала Claude Code (продукта на Anthropic) за написване на софтуер за насочване на ракети, включително балистична ракета с планиран обсег над 2000 км.
Всеки може да тълкува момента на публикуване, както прецени. И дали най-подходящият момент да поискаш въвеждане на надзор случайно не е в седмицата, в която оповестяваш данни как е бил използван твоят ИИ?
В рамките на по-малко от денонощие Амодей беше подкрепен от почти всички свои ключови конкуренти в лицето на изпълнителния директор на OpenAI Сам Олтман, на главния учен и основател на звеното за развой на Google DeepMind Демис Хасабис, на изпълнителния директор на Microsoft Сатя Надела. Дори Илън Мъсk написа в X: „Дарио е прав.“
Но докато от оркестрината се разнасяше още тихото адажио на внезапното примирие, Тръмп влезе в темата с бутонките и срути целия декор, заявявайки категорично, че САЩ изпреварват Китай и всички останали в надпреварата за ИИ и че
който спечели битката за ИИ, печели всичко.
Не пропусна да добави също, че „единственият контрол и предпазни механизми, от които ИИ се нуждае, са силен и умен президент“. А Дейвид Сакс, съветникът на американското правителство по въпросите на ИИ, директно заяви, че ако създателите на ИИ искат да забавят темпото, имат пълната власт да го направят, без да си измислят нуждата от регулации.
Китай директно отхвърли идеята, като оприличи цялата художествена самодейност на „загрижените“ компании като опит за нагнетяване на страх.
В същата интересна седмица McKinsey публикува свое изследване, в което се разглеждат резултатите от допитване сред 334 ръководители в сферата на продуктите и инженерната дейност. Едва 25% от анкетираните на позиции от ниво „директор“ и нагоре споделят за значително ускорение благодарение на ИИ. За „значително ускорение“ се смята постигането на поне двойно по-висока производителност от страна на повече от една четвърт от екипите в дадена организация. Още по-любопитен е фактът, че 30% отчитат спад в производителността на екипите си след въвеждане на ИИ.
Между другото, Meta, която също разработва ИИ (иначе е известна като компанията зад Facebook, Instagram и WhatsApp), има всички шансове да се превърне в учебникарски пример за провал по отношение на внедряването с опита си да редуцира своите екипи от 10–12 души до такива с 3–5 души и ИИ.
Много компании, които пробват да внедряват ИИ, се сблъскват и с горчивата истина, че невинаги това води до спестяване на средства. Особено когато някой надъхан мениджър се надява просто да замени хора с ИИ. Някъде е възможно, но по-често се налага хората да останат и да бъдат въоръжени с ИИ, което е допълнителен и постоянен разход.
И какво? Само това остава – да вземем да се съмняваме от ползите и ефективността от ИИ!
Все повече анализи и експерти сравняват настоящия бум от инвестиции в инфраструктура за ИИ с други пазарни обсесии от миналото, като железопътния бум, електрификацията и дотком балона. Всички те имат една ярка открояваща се черта – безспорно са технологичен пробив, но привлеченият от него капитал надхвърля нивата, които търговската възвръщаемост би могла да оправдае. Или казано кратко, огромни инвестиции с оскъдна възвръщаемост.
Очакванията за размера на капиталовложенията на най-големите компании в сектора са за над 750 млрд. долара до края на 2026 г. и един трилион долара за инфраструктура през 2027 г. Само Amazon, Microsoft и Google се очаква да похарчат по около 180–200 млрд. долара всяка. Подобни разходи надхвърлят приходите и паричните потоци на компаниите, което ги принуждава да теглят заеми, за да продължат надпреварата. А това поражда опасения, че свиване на финансирането ще превърне настоящия бум в продължителен инвестиционен срив.
На този фон едно добронамерено джентълменско споразумение за забавяне на темпото е чудно извинение за оттегляне от надпреварата в разходите (която вече изглежда неустойчива), без да се налага да се назовава истинската причина. В ушите на инвеститорите и регулаторите „пауза в името на безопасността“ ще звучи далеч по-добре от „Опа, пак се оляхме“.
Иначе, ако се върнем на важното, проблемът с подравняването има твърде очевидно решение. Просто е нужно е да се инвестира достатъчно в механизми за контрол и защита. И в хора, които работят за тях. Ако се облегнем отново на думите на Дейвид Сакс малко по-горе, това също е изцяло в ръцете на компаниите, създаващи ИИ, както е било и досега. Но наистина ли допускаме, че на когото и да било от висините в ИИ индустрията изобщо му пука за контрола и защитата?
The io_uring
subsystem is all about asynchronous execution; applications count on it
to not block — unless explicitly requested to. Within io_uring, maintaining
the “never blocks” guarantee has sometimes been a challenge, given that
many paths in the kernel were never designed for asynchronous execution.
This problem has been worked around, but at a significant cost to
performance. Now, io_uring maintainer Jens Axboe has posted an RFC patch set
with a somewhat radical (and potentially scary) solution to the problem.
Version 51 of the GNOME desktop
environment has been released. The list of changes includes a number of
performance improvements, offline data and better transit information in
the Maps application, a new interface for the file previewer, and more.
This essay was written with Nathan E. Sanders, and originally appeared in The Guardian.
There are plenty of signs that AI will make all of our experiences of the US midterm elections worse. Voters have anxiety about AI’s impacts on the country. Politicos are using AI deepfakes to spread lies. The White House is posting slopaganda.
Meanwhile, candidates are missing a real opportunity to use AI to make campaigning better. The technology can help candidates listen more deeply to voters’ concerns, engage constituents more inclusively, and formulate policy platforms that are more responsive to our input. There are vanishingly few examples of this in US politics, but groups in Japan, Scotland and the US’s own academic and private institutions show how that could change.
The problem with American campaigns’ current use of AI is that it’s not very different from the web ads of 30 years ago, or television ads before that: they are all about inundating voters with the candidate’s message. This one-to-many broadcasting is an uninspiring way to campaign, but not the only way. AI can help candidates connect one-to-one with as many people as possible. Or it can facilitate many-to-many connections, engaging voters in deliberation about issues at scale.
One of the most promising applications of AI being developed by pro-democracy innovators around the world is broad listening. These tools can collect public input in a format much richer than checkboxes on a survey form.
For example, the newly founded Japanese political party Team Mirai has built a foundation for eliciting public input from voters at scale, in depth, and across the breadth of legislative policy issues. It has developed an AI interviewer to cultivate constituent input on policy. Through extended conversations with this chatbot, voters explore and share their perspectives on specific policy issues. And the party has scaled this across a wide array of policy issues by integrating this functionality with an AI-powered portal for exploring bills.
Team Mirai describes itself as a “utility party”, developing tools for any Japanese political party to use to connect with voters. You might question whether Americans would willingly talk to a political AI. So far, Japanese voters have exchanged more than 300,000 messages across 16,000 AI interviews. Team Mirai grew adoption by providing a real incentive to engage: that talking to their AI interviewer does more than just posting on a platform such as Twitter/X or, equivalently, shouting into a void. Users see evidence that the party is actually listening and might take action on their behalf.
Team Mirai party members have directly cited AI interviews from constituents during legislative committee hearings, published a synthesis of that input back for voters, and even amended their policy platform based on user input. The party has rapidly risen to win 12 seats in the Diet, and is explicitly following in the footsteps of the civic hackers in Taiwan’s “gov zero” movement, who won political influence in their fight for transparency.
Other civic technologists are developing AI tools for scaling many-to-many conversations. CrownShy, a company funded in part by the Scottish government, is building a platform to bring the Platonic ideal of the town hall debate into the digital age. Their Comhairle tool integrates AI interviewing tools like the ones described above with software for synthesizing diverse viewpoints, holding virtual assemblies, and sharing video testimonials to help legislatures—or campaigners—organize digital consultations of their constituents en masse.
One thing the AI-powered software of Team Mirai and CrownShy have in common is that they are open-source, meant for anyone to use. Even though they are projects funded by political parties—the upstart party in Japan and the ruling party in Scotland—they are built to make democratic processes better, not necessarily for partisan political advantage.
For interested candidates, there is a wealth of tools available, many of them US-grown. The Stanford-affiliated deliberation.io uses AI to facilitate structured dialogues among thousands of participants and has been piloted for public listening sessions by the city of Washington DC. The MIT-affiliated Cortico project provides tools that surface under-heard community perspectives from recorded conversations, and is now organizing listening sessions at libraries across the country. The US non-profit-built Talk to the City uses AI to analyze large datasets of stakeholder input. The US startup Remesh has a commercial offering that uses AI to generate recommendations from dialogue, which has been tested in policy development scenarios.
There is a long and proud tradition of this sort of “civic technology” in the United States. Two decades ago, the spirit of innovation to develop software for better politics and civic engagement was so strong in organizations like Code for America and the Obama 2008 campaign that Congress funded a new executive agency to bring these ideas to government: the US Digital Service. (The Trump administration repurposed the USDS to become the US Doge Service in 2025.)
One signal that candidates and political parties may start adopting these kinds of tools came this spring from Higher Ground Labs. The Democratic-aligned campaign tech investment firm launched a new fund targeting, in part, “AI-Native Campaign Systems” and “community-Led Messaging Platforms that surface authentic, bottom-up insights from real conversations”.
AI is a multifaceted issue that deserves to be on the table in the midterms. So far, the powerful force of polarization in US politics seems to be separating the parties into the AI skeptics versus the AI boosters. We urge both voters and politicians to separate the technology of AI from its profiteers. We want big tech money out of politics, holding the AI companies accountable for the harm their models cause, taxing their revenues, and maybe even nationalizing them if the AI bubble bursts.
But we also think congressional candidates in the US midterms seeking authentic connection with voters, and seeking to differentiate themselves from their opponents, should be looking to use AI responsibly in their campaigning. The broad listening and deliberation tools pioneered by others around the world could make US politics more transparent, responsive and community-driven. The impact of AI on campaigning doesn’t have to be all bad.
Обществената памет е къса. Новите скандали и трагедии изместват вниманието от предишните, а ако нови няма, винаги може да се претопли нещо старо. Убийството на Георги Кузев на Младежкия хълм в Пловдив на 4 септември 2026 г. от група непълнолетни обаче все още е относително актуално. И за него трябва да се говори, за да не потъне и тази тема в социалната амнезия. Защото линчуването (онова, на което е бил подложен Кузев, е именно линч) на човешки същества в България от омраза не е някакъв чудовищен акт, дошъл от нищото. Нито пък прецедент. То е поредната проява на тенденция, която в известен смисъл се официализира.
Посочените досега (освен извършителите)
Няма спор, че конкретните виновници за убийството на Георги Кузев са тийнейджърите – „ловци на педофили“, които са го пребили до смърт, гаврили са се с него, заснели са всичко, обрали са го. И горди, че са свършили нещо общественополезно, са се почерпили с дюнери, купени с откраднатите пари. Възниква обаче въпросът как се е стигнало дотам; как подобно престъпление е станало възможно.
Социалните мрежи
За радикализацията на деца е най-лесно да се обвинят социалните мрежи. Не че за това няма основания. Социалните мрежи създават „балони“, в които реалността се представя по определен начин, а авторитетът на лидерите на мнение в съответния балон изглежда безвъпросен. Това улеснява раждането и организирането на радикализирани групи. Общуването в интернет често остава сляпо за уязвимостта на другия, а онлайн тормозът може да има последици, стигащи далеч.
Когато сочим с пръст социалните мрежи обаче, най-лесно е да поискаме забраната им за деца до определена възраст. Но да оставим настрана факта, че децата ще си намерят начини да я заобикалят и че притежават достатъчно дигитална грамотност да си направят свои тайни мрежи, където предпоставките за радикализация да са още по-големи. По-сериозният проблем е, че хвърлянето на вината върху технологиите измества отговорността от възрастните, които са допринесли за това деца да започнат да раздават правосъдие.
Семейството
Обичайна практика е отговорността за проблемите с деца да се прехвърля върху семействата им. Чували сте твърдения като „Най-важно е семейството“, „Всичко зависи от семейството“ и т.н. – все едно дали става дума за лоши образователни резултати на децата, проблеми с дисциплината, отпадане от училище, агресия и пр.
Очаквано, появиха се аргументи в този дух и във връзка с убийството на Георги Кузев. Социалната министърка Наталия Ефремова се оплака, че част от родителите на извършителите нямат доверие в социалните служби и отказват съдействие. В социалните мрежи някои от тези родители бяха идентифицирани и демонизирани, а политическите им предпочитания – извадени на показ (в „Тоест“ няма да ви предоставим връзки към тези постове от етични съображения).
Не че родителите не носят отговорност – носят, или поне тези от тях, които са възпитавали децата си не в емпатия, а в омраза и „раздаване на справедливост“ със сила. Но и техните ценности не са се взели от нищото.
Родителите на днешните тийнейджъри са децата на 90-те.
Те са се формирали като личности в онези смутни времена на бедност, мутри, хиперинфлация и… скинари (наричаха ги още „бръснати глави“). В България ги имаше още от началото на 90-те – когато не само социални мрежи, а и интернет нямаше. За тях беше известно, че мразят пънкарите (каквито също имаше в изобилие) и като ги срещнат, ги бият – конфликт между тези две субкултури, привнесен от Великобритания.
Година по-късно седмина тийнейджъри скинари от Шумен убиха 28-годишен ромски младеж – футболист в местен селски отбор, който просто си вървял по пътя. Следват още убийства. Едно от тях – на 15-годишния Методи Райнов, отново от група скинари, е деветият известен случай на смърт, причинена от расистко насилие, в България след 1989 г.
Ще попитате къде са били институциите. През 90-те те не само не разпознават престъпленията от омраза (не че днес ги разпознават особено), ами понякога ги и извършват. Към началото на 2000 г. в Европейския съд за правата на човека в Страсбург са заведени пет дела срещу България за малтретиране на роми от страна на полицейски служители. При четири от тях малтретираните са починали. Една от жертвите е Славчо Цончев, пребит в плевенското полицейско управление през 1994 г.
Може би ще си зададете въпроса и за родителите на скинарите от 90-те. Те са хора, формирани по времето на социализма, с все още пресни спомени за мащабното етническо прочистване, наречено Възродителен процес. А някои от тях може и лично да са участвали в него или най-малкото да са го подкрепяли идеологически.
С течение на времето радикализираните младежки групи се множат, делят и преплитат, както и социалните групи – обект на омразата им. Клошари, африканци, гейове, бежанци и т.н. и т.н., докато се стигне до „педофилите“.
Убийството на Георги Кузев извади на показ българския клон на неонацистката организация „Кръв и чест“, чието ядро е в Пловдив – точно срещу Младежкия хълм, където е убит Георги Кузев. Това стана, след като покрай смъртта на Кузев стана известен друг акт на насилие в Пловдив, извършен десетина дни по-рано – побой над непалски гражданин от скинари (за поне един от извършителите има данни, че е повлиян от „Кръв и чест“). В резултат бяха арестувани 18 души от крайнодясната организация, а на трима от тях бяха повдигнати обвинения.
Досега не е установена пряка връзка между убийството на Кузев и „Кръв и чест“, макар в миналото групата да е извършвала нападение (срещу ром) на Младежкия хълм. Неонацистката организация развива дейност в България от четвърт век и се свързва дори с бомбен атентат в Сандански, при който загива мъж от ромски произход. Така че когато и да се захванат с нея институциите, все ще е късно. Но в случая с Кузев като че става въпрос по-скоро за отвличане на вниманието, както отбелязва и проф. Калин Янакиев. Темата се измества от руската връзка – „ловците на педофили“, вдъхновени от Максим Марцинкевич, известен с прозвището Тесак – към движението с британски произход „Кръв и чест“.
Медиите
Убийството на Георги Кузев извади на показ и отговорността на определени медии за героизирането на т.нар. ловци на педофили. „Тоест“ обърна внимание на проблема още през 2021 г., след като NOVA излъчи репортаж на Лора Крумова за децата „ловци на педофили“ в България и техния предводител и вдъхновител Ален Симеонов, и след репортаж на bTV за тийнейджъри „герои“, осъществили граждански арест на шофьор, който е причинил катастрофа. В репортажа на Крумова се показва и как Симеонов се гаври с уловените, например залива ги с урина. Тогава спестихме името му, защото беше още непълнолетен. Но предупредихме:
Ако деца и младежи подлагат на унижения и сами ловят „лошите“, за което получават похвали и награди, не е ли логично да започнат да линчуват и да екзекутират? Все в името на справедливостта. Да не забравяме, че и терористичните актове се извършват от чувство за справедливост – от сляпа вяра в някоя идеология и от убеждението, че тя стои над законите и правилата, над човешкото достойнство и човешкия живот.
През 2022 г. медии, включително БНТ, разпространяват информация за 21 членове на педофилска мрежа, задържани „благодарение на действията на така наречените ловци на педофили“.
Освен посочените непреки виновници, за да се стигне до убийството на Кузев, други засега остават на сухо. Става въпрос за държавата – и като институции, и като политика.
Институциите
Каквото и да кажем за отговорността на институциите, няма да е достатъчно.
Да започнем от образователната система. Тя възпитава, както и по времето на късния социализъм, основно в национализъм. И то такъв, който, освен че е фиксиран в едно идеализирано минало, внушава, че най-достойно е да се биеш и да умираш за родината. Това, на което образованието ни не учи, е емпатия, зачитане на човешкото достойнство, включително на другите, чуждите, „неправилните“. В резултат всяка проява на омраза срещу определена група лесно може да бъде облечена в патриотични аргументи и така да изглежда легитимна в очите на мразещите. Децата „ловци на педофили“ вероятно са били убедени, че вършат родолюбиво и общественополезно дело.
Не по-малка е отговорността и на институциите – като се почне от структурите за закрила на детето на местно равнище, мине се през полицията, правосъдната система и се стигне чак до разузнавателните служби – които не са разпознали радикализацията и не са предприели твърди мерки, за да я ограничат. В продължение на пет години Ален Симеонов дефилира из медиите, а в социалните мрежи е отпреди това. Бил е и арестуван, срещу него са повдигани обвинения. Но… дотам. Междувременно пред очите на всички е създадена цяла мрежа от тийнейджъри, обучени да „ловят педофили“ и да се саморазправят с тях.
От друга страна обаче, институциите носят отговорност и за това, че системно не разпознават сексуалното насилие над деца и не вземат достатъчно мерки срещу него. Както установи журналистическо проучване на Теодора Станимирова, институциите, които трябва да се борят със сексуалното насилие срещу деца, на практика не го познават. И събират данни по начин, който не им помага да го разберат по-добре. А понякога не го виждат, дори да е пред очите им. Така става лесно някои подрастващи да решат, че трябва да вземат нещата в свои ръце, особено ако разполагат със „светли примери“ като Ален Симеонов и Тесак.
Отговорността на политическите сили е особено сериозна. Не само защото от тях зависи как работят институциите, макар че и заради това. Всички парламентарно представени партии от 2023 г. насам обаче имат основен принос за официализирането на дехуманизацията. Без да пропускаме и „Прогресивна България“, защото в качеството си на президент Румен Радев не наложи вето върху законите, за които ще стане дума по-долу. А от дехуманизацията към физическото унищожение крачката е малка.
представянето на група хора не като сбор от индивиди, а като аморфна маса, несъвместима с обичайните човешки черти и неспособна на човешки чувства.
От тази дефиниция не следва, че представителите на всички групи – обект на дехуманизация, на всяка цена трябва да са добри хора. Някои може да са и престъпници и е редно да понесат отговорността си. Но дори те притежават основни права, например правото на живот и достойнство и правото да не бъдат подлагани на унижения. Така пише и в Конституцията на България:
„издигаме във върховен принцип правата на личността, нейното достойнство и сигурност“ (преамбюл);
„Република България гарантира живота, достойнството и правата на личността“ (чл. 4, ал. 2);
„Всеки има право на живот. Посегателството върху човешкия живот се наказва като най-тежко престъпление“ (чл. 28);
„Никой не може да бъде подлаган на мъчение, на жестоко, безчовечно или унижаващо отношение“ (чл. 29, ал. 1).
Не изглежда обаче политическите сили да вземат под внимание тези текстове. Нещо повече – партиите в парламента послушно следваха дневния ред на Ален Симеонов, който пък съвпада с този на „Възраждане“ и на ултраконсервативната организация „РОД Интернешънъл“ – същата, която се бори срещу „джендъра“ и „София прайд“. Скоро след убийството на Кузев от сайта на РОД изчезна публикация от 2021 г. със заглавие „Защо ни е необходим Ален?“, но нейно архивно копие още е достъпно. В статията се казва:
България е една от малкото страни, в които няма регистър на педофилите. Този регистър съдържа данни за лицето, адрес на пребиваване, престъплението, за което е осъден и най-важното – негова снимка.
Когато през лятото на 2023 г. законопроектът на „Възраждане“ за регистър на педофилите беше подложен на гласуване, всички парламентарни групи с изключение на ДПС го подкрепиха, а депутатите, които се отклониха от вота на партиите си, бяха единици. Божидар Божанов (днес съпредседател на „Да, България“) заяви от парламентарната трибуна, че темата е „консенсусна“. Така думата „педофилия“ влезе в българското законодателство, без да съществува ясна правна дефиниция за нея.
На 19 февруари 2026 г. (символично – на датата на обесването на Левски) на парламента му трябваха точно три минути, за да приеме на две четения и с пълно мнозинство решението регистърът на педофилите да стане публичен. Освен в България, в ЕС подобен закон има само в Полша. Това стана в контекста на трагедията в Петрохан и Околчица, при която загинаха шестима души, включително 15-годишен тийнейджър, а за покойния лидер на групата Ивайло Калушев се появиха твърдения, че има сексуална склонност към непълнолетни момчета.
Случаят беше използван (и още се използва) като компромат срещу ПП, ДБ и кмета на София Васил Терзиев, макар да няма данни някой от тях да е бил наясно с евентуалните сексуални предпочитания на Калушев. И макар депутатите от ПП и ДБ послушно да гласуваха популистката поправка, това не ги спаси от активното мероприятие, състоящо се в инсинуации, че те поддържат „педофилска секта“ и „педофилско НПО“.
В началото на март 2026 г. пък парламентът прие по предложение на ДПС, отново единодушно, вдигане на възрастта за съгласие за секс от 14 до 16 г. Може да предположим, че това отново има връзка с трагедията с петроханската група – убитото момче е на 15 години, а единственият човек, който публично твърди, че е имал сексуална връзка с Калушев, казва в интервю с Мария Черешева, че интимните отношения са започнали, когато е бил навършил 15 г. Така с промяната на възрастта на съгласие Калушев посмъртно е произведен в педофил.
Не знаем дали Георги Кузев се е интересувал от политика и е следял новините. Ако не е, може така и да не е разбрал, че сексуалните отношения с 15-годишни тийнейджъри, като каквато се е представила „примамката“, вече са незаконни. Да, непознаването на закона не е извинение за неспазването му. Но независимо дали е знаел, нищо не оправдава линчуването.
Дехуманизацията ми е по-добра от дехуманизацията ти
Убийството на Георги Кузев е червена лампа, че в България имаме сериозен проблем с дехуманизацията. Би следвало на партиите да им светне, но уви. По-силен е урокът, който те са си извлекли от петроханската трагедия. А той е, че дехуманизацията е ефективно оръжие за разправа с политическия противник. Затова я вкарват в обращение в президентската надпревара.
ПП и ДБ вадят карта против Илияна Йотова –
факта, че тя е помилвала „българския Ескобар“ – наркобоса рецидивист Огнян Атанасов. Помилването се основава на медицинска експертиза, според която той е почти на смъртно легло поради паркинсон. След помилването му обаче „умиращият“ отново е хванат с наркотици. А председателят на ПП Асен Василев обръща внимание, че от 28 помилвани от Йотова петима са осъдени за наркотрафик.
И така, от доскорошната коалиция започват да споменават Йотова в комплект с думи като „наркодилъри“, „наркобарони“, „наркобосове“, „българския Ескобар“. Това внушава, че никой осъден за търговия с наркотици при никакви обстоятелства не заслужава помилване.
А актът на Йотова е дълбоко проблематичен, но по други причини. Първо, тя се оправдава с медицинската експертиза, макар да носи отговорност за решението. Второ и по-важно, към момента на помилването Атанасов не е бил в затвора (отново заради експертиза за здравословното му състояние). Така че и да допуснем, че наистина е бил на смъртно легло, помилването с нищо не е облекчило състоянието му. Ала влизането в такива тънки уточнения не носи точки, когато си в предизборна кампания.
От противниковия лагер пък отговарят с „претопляне“ на петроханската тема.
Само така може да се обясни пресконференцията, на която не бяха представени нови факти, но бяха направени куп внушения и квалификации. В главната роля беше криминалният психолог Росен Йорданов, според когото Калушев „отговаря на 100% от всички възможни критерии за преференциален, седуктивен, сексуален насилник“. И публично се говореше за сфинктери, включително за този на убитото дете. Отделен проблем е несъответствието на внушенията за анален секс с резултатите от медицинските експертизи на убитите край Околчица, извършени през февруари.
Скоро след пресконференцията „Епицентър“ и ПИК публикуваха експертиза за Петрохан и Околчица, съдържаща дори личните данни на деца, които може да са в уязвима ситуация. Но „всичко е в името на децата“, нали. Да не помислите, че е заради предизборната кампания. Апропо главната редакторка на „Епицентър“ Валерия Велева беше в инициативния комитет за президентската кандидатура на Йотова, но в резултат на скандала за нарушаването на журналистическата етика, последвал публикуването, тя се оттегли и комитетът се отрече от нея.
Картата с Петрохан беше използвана и от премиера Румен Радев, който употреби първия учебен ден, за да говори за „НПО, свърталище на педофили“ – стреляйки не само срещу политическите си противници, а и срещу неправителствения сектор.
Палачинката на дехуманизацията има свойството да се обръща.
Това вече изпитват на свой гръб младежите, гаврили се с Георги Кузев до смърт. Довчера се борят с „изроди педофили“, а днес тях наричат „изроди“. Друг въпрос е дали този опит би ги довел до осъзнаване на вредността на дехуманизацията. И съвсем различен въпрос – дали Ален Симеонов ще си вземе бележка.
Впрочем забелязахте ли, че той не беше сред посочените непреки отговорници за смъртта на Кузев? Това не е случайно – Ален Симеонов заслужава не параграф, а отделна статия. Която предстои.
превод от исландски Светла Стоянова, София: изд. ICU, 2025
Съществуват базови правила за отношението към човек в депресия: не омаловажаваме състоянието му; не изтъкваме житейски обстоятелства, поради които би следвало да се чувства щастлив и благодарен на съдбата; не посочваме за пример други хора, които са в много по-тежко положение, но се справят по-добре. Перифразирайки Толстой, Ойдур Ава Олафсдотир пише, че
всяко страдание е различно и затова не може да се сравнява.
Белезите, които оставя – също. И все пак…
И все пак, противно на горните твърдения, исландската авторка на романа „Белези“ поставя героя си – мъж на средна възраст, изпаднал в дълбока екзистенциална криза след развода и наученото за дъщеря си – именно в ситуация, в която състоянието му бива дискретно съпоставено с едно „по-убедително“ и смиряващо чуждо нещастие – и в личен, и в колективен план. Така както по-силният удар отнема усещането за друга, по-малка болка преди него, така и Олафсдотир обезсилва нагона на протагониста си към смъртта, изправяйки го пред нейните реални поражения в едно фикционално общество. Противно на стереотипните ми читателски очаквания подобен скандинавски роман да бъде мрачен и суров до цинизъм, „Белези“ всъщност изненадва с нежно-меланхоличната си атмосфера и жизнеутвърждаващите си послания.
За целта Олафсдотир създава образа на една анонимна, но очевидно европейска страна, поразена от последиците на бушувала цели пет години война, вероятно гражданска. За да не натовари със смъртта си своята дъщеря, героят Йонас Ебенесер заминава за това най-опасно, най-отзивчиво на Танатоса място, където всяка стъпка все още е минирана и унищожението дебне зад всеки ъгъл.
Правя любопитното уточнение, че романът излиза през 2016 г., но този въображаем топос зловещо напомня за случващото се от години в Украйна. В подобни сюжети много западни романи/филми имат уклон да преувеличават и да описват едни доста по-зрелищно и потискащо антиутопични тоталитарни структури, тип източноевропейски, в които обикновено се подвизават недостоверни, изопачени и елементаризирани общества. Въпреки някои сюжетно насилени съвпадения и неправдоподобности обаче (по скоро тип недомислени пропуски), исландската авторка ни отвежда в едно зловещо познато ни днешно място – да, това е нашата цивилизация, нашите институции, нашият културно-туристически облик, нашият тип хора. То е като някоя от страните, до които преди пет лета вероятно сме пътували или ходили на плаж. Трудно е да приемем (май още не сме го постигнали докрай дори по отношение на Украйна), че това наистина се е случило там – войната звучи абстрактно, така и не става ясно каква точно политика е довела до нея и най-вече кой и къде е врагът, ако всички, които срещаме, са само жертви (дали?).
Насред повсеместната разруха в наскоро настъпилото примирие, когато са плъзнали крадци на артефакти и бизнесмени, които се надяват да препостроят държавата, подобно вирус, главният герой внася и своя личен себеразрушителен импулс. Йонас идва без багаж (с изключение на бормашината си) и се оказва един от тримата гости на западнал хотел, държан от брат и сестра, които се надяват някой ден туристите да се завърнат. Именно там последните дни, отредени да приключи със себе си, се превръщат в началото на едно оздравително не само за него, но и за непосредствената общност начинание. Тази трансформация става с натрупване, с пренасочване на вътрешния самоубийствен импулс към „поправките“ на завареното външно положение – кран по кран и крушка по крушка, докато накрая Йонас, който умее да прави какво ли не, се превръща в търсен от всички наоколо майстор.
Може и да ни се вижда пределно ясна метафората за задължителните „малки всекидневни стъпки“ към психическото възстановяване, но симпатичното е, че
Олафсдотир ни оставя в удовлетворението от дословното – Йонас работи с ръцете си, той съвсем буквално поправя жичките и прозорците на реалността, прочиства наносите и затяга предметите.
Макар често тези думи да са взаимнозаменяеми, смисълът тук не е толкова в баналната причина/основание за живеене (нещо вече съществуващо, постигнато), а в намирането на цел (нещо предстоящо, неизвестно). Поправимостта не значи път към същото, към възстановяването на предишното – така както раната не може да зарасне, като изчезне напълно, а само оставяйки белег. Поправимостта е понасянето на този белег и създаването на нещо трето, със/във което да се съгласиш да продължиш да съществуваш.
… ако някой има голям и впечатляващ белег, то означава, че е погледнал страха в очите, изправил се е срещу дивия звяр и е оцелял.
Без да се поддава на скандинавския фаталистичен ноар, но и надскачайки опасността романът да зазвучи поучително, сантиментално или опростенчески катарзисно, исландската авторка – както сама пише в бележката си към българските читатели – все пак превръща този разказ в
книга за оцеляването, изцелението и способността да започнеш отначало.
В изследване на смисъла на добротворчеството и на въпроса
дали един обикновен човек може да съдейства с нещо, за да се претвори счупеният свят, за да промени и самите нас.
Спасение? Не, това е твърде грандиозна дума. Може би просто предаване на ритъма на конкретността, на минималните действия, сами по себе си едва ли не безсмислени и незабележими в контекста на голямото. Само че не.
В романа има изобилие от повтарящи се мотиви и символи – белезите, кожата, птиците, благодарността, мълчанието/тишината (неслучайно името на английския превод на книгата е „Хотел Тишина“), в които се преосмисля миналото и се подготвя изричането на бъдещето, и т.н. А една от най-устойчивите дихотомии е тази за мъжкото и женското.
Цяло поколение мъже са се избили един друг във войната, затвърждавайки архетипния образ на мъжа като разрушител, завоевател, насилник и убиец. В създалия се вакуум Йонас се налага като ироничен контрапункт – той е мъж, който „по-скоро би бил убит, отколкото да убие някого“, който е готов преди всичко да убие себе си. Мълчаливият исландец се е научил да прави почти всичко с ръцете си и винаги е откликвал на молбите на трите женски образа в живота си („ако някой ме попита защо го правя, отговарям: защото жена ме помоли“); той е чувствителен и колебаещ се (мисли над всяка дума от прощалното си писмо и по принцип); водил си е дневници и е чел много; следвал е философия, преди да поеме завода на баща си (книгата изобилства от препратки и цитати – от Ницще и Хайдегер до Ман и Бишъп). Абсолютно верен се оказва разказът на майка му за него като дете, който предизвиква неудобството му:
Видеше ли птица със счупено крило в градината, направо ревваше… Беше страшно чувствителен… постоянно се тревожеше, че хората не са достатъчно добри едни с други… Заричаше се, че като порасне, ще утеши света… защото светът страда толкова много…
В крайна сметка Йонас не се учи тепърва на грижа и отговорност, а по-скоро успява да открие нов, достатъчен адресат за тях. Уменията му го превръщат в архетип на лечителя, поправящия, градящия насред руините от военния конфликт. Докато мъжете се „размотават, пият и водят войни“ (според съседа Сванюр, обсебен от темата и статистиките за домашното насилие, половото неравенство, женското страдание и права, и изобщо от темата за справедливостта), Йонас започва да преустроява къща, в която ще живеят седем жени – колкото са и белезите му по рождение. До степен, в която на няколко пъти ще получи предупреждение, че това е съмнително и неугодно за мнозина – разбира се, мъже. Ала с действията си, той ще уважи думите на своя съсед в Рейкявик:
Онези, които знаят и не правят нищо по въпроса, са най-лошите.
Въпросният съсед Сванюр е един от двата интересни второстепенни образа в романа, замислени като своеобразен контрапункт (заедно с майката на Йонас). Той е единственият външен на семейството човек, с когото Йонас има някаква форма на общуване. Бъбрив, лапидарно декларативен дървен философ, който говори с винетки и труизми и носи тениска с надпис Shit happens. Еднозначен и лишен от способност да се изразява с метафори (според Йонас), той всъщност ще ни опровергае като човека, произнесъл някои от най-валидните истини, и ще ни изненада с тих, но крайно неочакван обрат, чрез който ще преосмислим поне донякъде образа му, ще приемем, че може би именно такива хора понякога дискретно разбират какво преживява другият, и му дават знаци и грижа, макар и по своя нелеп начин. Именно Сванюр е и източник на голяма част от ироничната нотка в този роман, която саботира възможността за прекомерна драматичност предвид темата. Той е човекът, който пита „искаш ли да ти покажа белега си“, имайки предвид среза от операцията на дисковата си херния, когато очакваме някакво възвишено-фигуративно разбиране за тази дума. Пак той:
– Хората мечтаят за прости неща – беше казал Сванюр. – Да не бъдат застреляни излишно и децата им да помнят родителите си.
Майката на Йонас – бивша учителка по математика, чийто рационален ум, свикнал да борави с точни цифри и факти, постепенно се предава на деменцията – пък е обсебена от темата за войните. Тя непрекъснато чете за миналите и очаква настоящи, макар парадоксално да живее в общество, от векове пощадено от военни конфликти. Нейното възприемане обаче минава през подробното познаване на фактологията и статистиката, не през онова, което нейният син ще познае – личната човешка история от първа ръка на младата жена и роденото ѝ във война и познаващо само нея момче. За майката на Йонас „голямата история е почнала много преди да се родим“, а всички базови книги за оцеляването през Втората световна война, всички истории са само илюстрация на това обективно и безстрастно знание. На този фон са поразителни, но не и изненадващи реакциите ѝ, лишени от състрадание и любов (да, най-вече от болестта, но…), в следните два разговора със сина ѝ, опитващ се да сподели състоянието си с нея:
– Нещастен съм. Тя ме потупва по ръката. – Всички имаме своите битки – казва и добавя: – Наполеон е бил в изгнаничество от самия себе си. Жозефин е била изоставена в брака си като мен.
– Не искаш ли да живееш, момчето ми? – Не съм сигурен. – Поне все още имаш коса. Мъжете от моя род не губят косата си.
И ето този натрапващ се контраст: в сигурен и подреден свят съзнанието се разпада и парадоксално търси структура през цифрите на войната, докато насред разрухата в анонимната страна душата на Йонас започва да се подрежда.
Трябва да оставиш багажа си, за да се изпълниш наново, ни казва този роман, в който Йонас (чието име според майка му значи „гълъб“ на иврит) е Ноевият гълъб, открил суша след Потопа. Умно ироничен на точните места, богат на интертекстуалност, преодоляващ патетиката отвъд „човешко, твърде човешкото“ (по любимия философ на Йонас), книгата ни предоставя поглед върху белезите, оставени по кожата както на отделния човек, така и на общността. Знаци колкото за поражението, толкова и за факта, че болката под тях е започнала да си отива или вече е преодоляна. И макар неизбежно да мерим болките и да сравняваме личните си истории (вероятно и да изпитваме същото неудобство, което изпитва Йонас, съпоставяйки нежеланието си да живее с радостта и благодарността на новите си приятели от всяко негово проявление насред оцеляването), Олафсдотир в крайна сметка не зачерква значението на едните белези, а просто ги вписва и скрива в другите. Също както красивата татуировка на Йонас пази сърцето му.
Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. За нея медията „Тоест“ е отличена с Националната награда „Христо Г. Данов“ (2025) за принос в представянето на българската книга.
Рубриката е част от партньорската програма Читателски клуб „Тоест“, благодарение на която активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на включените издателства. Изборът на заглавия обаче е единствено на авторите Стефан Иванов, Севда Семер и Антония Апостолова, които биха ви препоръчали тези книги и ако имаше как да се разходите с тях в книжарницата.
When the scripts that generate the data for letsencrypt.org/stats broke yet again, we decided to retire it rather than repair it. Let’s Encrypt issues six to ten million certificates each day, producing a large volume of logs that keeps growing. It became increasingly time-consuming and difficult to answer questions about our own issuance like “how many certificates use the ‘shortlived’ profile.” Using raw logs, this requires finding, parsing and extracting relevant portions of loglines. Querying the database behind our issuance API is not a practical option, as it’s built for transactions rather than analysis. We’d also used a log search SaaS product, but our bills were growing much faster than we’d like, and while it was fine for searching, it wasn’t able to do the analytic workloads we needed. We knew we could dream bigger and better.
Daily issuance of Let’s Encrypt certificates over the last 180 days
This led us to seek a self-hosted solution with efficient storage for structured data in addition to logs. We chose ClickHouse because of its potential as a data warehouse; the combination of cost-efficient storage and fast aggregation over large datasets appealed to us. A bonus of ClickHouse is that it is open source, a key principle valued by Let’s Encrypt.
The first step in building our new infrastructure was to purchase new hardware. To back our ClickHouse warehouse, we bought three PowerEdge R7715 servers. Each is equipped with a 32-core AMD EPYC 9355P 3.55GHz processor, 384 GB of RAM and 32 × 3.2TB NVMe drives, working out to roughly 100TB raw storage. With structured data and 100 days’ worth of logs already in our database, we are only at ~14% of total capacity, leaving lots of room for future growth.
Logs are the bulk of our storage use and the foundation of our structured data, as every other table we build is derived from them. When it comes to log search, ClickHouse covers our basic needs with quick ingest and interactive SQL. However, there are query ergonomics that we want to improve, like using OpenTechnology’s tracing features and ClickHouse’s tokenization settings.
Our primary target for structured data are our issuance records. A materialized view extracts those records from logs into their own table, and further views pre-aggregate from there. One such view counts issuance by day per profile. Now, questions like “what is our issuance by profile over the last 180 days” can be answered within milliseconds.
Daily issuance count of certificates by profile, excluding “classic”, over the last 180 days
We used this approach to completely rebuild the pipeline for our public stats page. The scripts we abandoned used to take hours each day to read and process dozens of compressed data files. The Rube-Goldberg-Machine-like collection of steps failed several times a year, requiring us to intervene and fix it. ClickHouse now computes those same stats in less than 10 seconds. Aside from pre-aggregated issuance tables, we can accomplish this because ClickHouse’s native functions are capable of quick and complex aggregations. Below is a simplified snippet of our materialized view for daily stats, counting the unique set of active domains over months across millions of rows. Two things to point out about this query: array handling means we can query nested fields without reshaping the underlying data, and uniq uses approximations to stay fast at scale.
Our ClickHouse issuance data also addresses the previous headache of identifying affected certificates during incidents. It used to take hours of engineer time to correctly scan and parse logs to find the affected set of serials or hours of computing time to return results from database queries, competing with production transactional load. Now, however, there is no log wrestling required, and because queries return quickly, we can iterate toward the right one in minutes rather than hours.
Not everything we needed came with ClickHouse. For scheduled reports, we built our own custom tool that queries ClickHouse and exports formatted results. It cost additional engineering time to design it to fit our needs, but we’ve seen payoffs already. Old reports were clunky to read and required chasing down context by hand. New reports, on the other hand, streamline security reviews via neat formatting and linking directly to relevant pages. The same reporting tool was repurposed for our revitalized stats pipeline as well.
The biggest challenge was backfilling data. While OTel collector handles live log ingestion well for us, it didn’t suit the task of backfilling historical logs. We couldn’t find throttling settings that handled the bulk import reliably – a large portion of files were silently dropped – and the alternative meant breaking up the import by hand. We instead switched to ClickHouse’s native S3 import method, standing up an S3-compatible gateway in front of our old logs to do so. While this avoided the earlier obstacles, this process required trial and error to match ingestion rules to OTel collector’s parsing to ensure the ingested logs matched regardless of whether they were backfilled or streamed in. Two lessons: don’t run bulk historical imports through a streaming collector, and match parsing rules across paths before you start.
One schema decision made these iterations cheap. For tables we anticipated requiring backfilling or recalculation, we deliberately chose the ReplacingMergeTree engine, so re-ingesting corrected rows simply replaced the old ones. This also came in handy for a materialized view computing aggregations across other rows. We got the calculations wrong more than once, and each time all we had to do was re-run the query rather than surgically remove bad rows. For tables without the engine, we did OPTIMIZE TABLE ... DEDUPLICATE BY, which was expensive, but only needed to be run once.
We hope that this is just the start, especially with our shorter certificate lifetimes and post-quantum certificates on the horizon. We plan to take full advantage of our new warehouse, extracting and pre-aggregating data that answers questions other teams care about, the way we did for issuance. Better analysis improves our operations and makes transparency cheaper, as our rebuilt stats page shows.
Daily certificate issuance stats since 2016
With powerful analytics in hand and only ~14% of our storage in use, we have room to store and analyze more than ever before.
The AWS European Sovereign Cloud is a new, independent cloud for Europe, physically and logically separate from existing AWS Regions and operated within the European Union (EU). It provides the same services, features, and APIs as AWS commercial Regions, but runs as a distinct AWS partition (aws-eusc), with its own control plane, AWS Identity and Access Management (IAM), billing, console, and service endpoints. Understanding the partition boundary is the key that unlocks correct answers to questions about billing roll-ups, single sign-on (SSO), cross-account roles, AWS Direct Connect, and image distribution. In this post, we show you how to architect a secure, scalable landing zone in the AWS European Sovereign Cloud. We cover account structure and governance, identity managed as infrastructure as code (IaC), centralized logging to a security and event management (SIEM) tool, data protection, network and perimeter design, secure continuous integration and delivery (CI/CD) and artifact distribution, and incident response. Throughout, we map the design to the AWS Security Reference Architecture (AWS SRA) and the AWS Well-Architected Framework, and we call out which behaviors are platform boundaries of a sovereign partition and which are configuration choices you can adapt.
If you are evaluating compliance readiness alongside your landing zone build-out, see the companion post Landing Zone Accelerator Independent Assessment Report for C5:2020 now available on AWS Artifact. This post covers how to align with C5:2020 criteria and provides an independent assessment report and compliance workbook, resources that complement the architectural patterns described here.
The foundational concept: EUSC is a partition
AWS groups Regions into partitions. Every Region is in exactly one partition, and each partition has one or more Regions. Partitions have independent instances of AWS Identity and Access Management (IAM) and provide a hard boundary between Regions in different partitions. AWS commercial Regions are in the aws partition, Regions in China are in the aws-cn partition, and AWS GovCloud Regions are in the aws-us-gov partition. The AWS European Sovereign Cloud is the aws-eusc partition, with its first Region in Brandenburg, Germany (eusc-de-east-1).
Some AWS services provide cross-Region functionality, such as Amazon S3 Cross-Region Replication or AWS Transit Gateway Inter-Region peering. These capabilities work only between Regions in the same partition. You can’t use IAM credentials from one partition to interact with resources in a different partition. There are practical differences that impact your architecture, shown in the following table:
Dimension
Commercial AWS (aws)
AWS European Sovereign Cloud (aws-eusc)
ARN prefix
arn:aws:
arn:aws-eusc:
Console or endpoint domain
amazonaws.com
amazonaws.eu
AWS Organizations
One organization in the partition
A separate, independent organization
AWS IAM Identity Center
Instance in the partition
A separate instance in the partition
Billing
Consolidated in the partition’s payer
A separate payer and billing system (EUR currency)
Cross-partition features and services such as: sts:AssumeRole, VPC peering, Transit Gateway, AWS RAM, Amazon S3 replication
Cross-Region features and functionality
Not available across the aws and aws-eusc boundary
Every AWS Region is sovereign by design: if you find yourself architecting across Regions, note that this partition boundary means that the centralization—one organization, one logging account, one identity source, one billing roll-up—is achievable within each partition. In the EUSC you operate an independent landing zone in aws-eusc that mirrors your commercial operating model. Where you need to bridge the two clouds (for example, a standard application CI/CD system in an AWS commercial Region deploying into EUSC), you integrate at the network or API layer with separate credentials for each partition, not with cross-partition trust. With these partition fundamentals in mind, the remainder of this post walks you through the considerations to build a production-ready landing zone in the EUSC. Each section addresses a critical layer of the architecture, starting with how to write partition-aware infrastructure code that works across both aws and aws-eusc, then moving into the organizational and governance controls that underpin everything else.
Cross-partition IaC
These Terraform and AWS CloudFormation IaC snippets demonstrate partition-aware Amazon Resource Name (ARN) construction—a pattern that helps ensure your infrastructure code works unchanged across AWS partitions (such as standard aws, GovCloud aws-us-gov, or European Sovereign Cloud aws-eusc).
In the case of using the same Terraform script from a commercial Region, ensure that arn:aws isn’t hard coded. This Terraform script derives the partition at deploy time so the same modules work in both AWS commercial Regions and the EUSC.
# Terraform: partition-aware ARNs (works unchanged in aws and aws-eusc)data "aws_partition""current" {}
data "aws_partition" "current" {}
data "aws_region" "current" {}
data "aws_caller_identity" "current" {}
data "aws_organizations_organization" "current" {}
locals {
partition = data.aws_partition.current.partition# "aws" or "aws-eusc"
account_id = data.aws_caller_identity.current.account_id
org_id= data.aws_organizations_organization.current.id
ecs_task_execution_policy_arn = "arn:${local.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
central_logs_bucket_arn= "arn:${local.partition}:s3:::${local.org_id}-central-logs"
}
resource "aws_iam_role" "amazon_ecs_role" {
name = "AmazonECSrole"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Sid= ""
Principal = {
# IAM service principals are "amazonaws.com" across all partitions,
# this stays literal (do NOT use ${AWS::URLSuffix} here).
Service = "ecs-tasks.amazonaws.com"
}
},
]
})
}
resource "aws_iam_role_policy_attachment" "amazon_ecs_role_attach" {
role= "AmazonECSrole"
# Use ${local.partition } rather than hardcoding "aws" in the ARN.
policy_arn = "arn:${local.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}
# CloudFormation: use the AWS::Partition pseudo parameter, never a literal "aws"
AWSTemplateFormatVersion: "2010-09-09"
Description: >-
Creates an ECS task execution role. Demonstrates using the
${AWS::Partition} pseudo parameter in ARNs instead of hardcoding "aws",
so the template works across partitions (aws, aws-cn, aws-us-gov, aws-eusc).
Resources:
ExecRole:
Type: AWS::IAM::Role
Properties:
RoleName: AmazonECSroleCF
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service:
# IAM service principals are "amazonaws.com" across all partitions,
# so this stays literal (do NOT use ${AWS::URLSuffix} here).
- "ecs-tasks.amazonaws.com"
Action: "sts:AssumeRole"
ManagedPolicyArns:
# Use ${AWS::Partition} rather than hardcoding "aws" in the ARN.
- !Sub "arn:${AWS::Partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
Outputs:
ExecRoleArn:
Description: ARN of the created ECS task execution role
Value: !GetAtt ExecRole.Arn
Account structure and governance
AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive best practices. AWS Control Tower orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center, to build a landing zone in less than an hour. Resources are set up and managed on your behalf.
We recommend following the AWS Security Reference Architecture (AWS SRA) multi-account model structure for a EUSC deployment. Use the management account only for governance, deploy universal security guardrails through service control policies (SCPs), resource control policies (RCPs), and service deployments (such as AWS CloudTrail) that will affect all member accounts in the organization.
Region-deny SCPs are commonly applied in commercial Regions, but aren’t required (at this time) in the EUSC because of the physically and logically separated nature of its design.
Other possible SCPs for the management OU:
Service-level guardrails – Restrict which AWS services can be used, based on your compliance posture.
Network perimeter controls – Enforce virtual private cloud (VPC) endpoints, deny public access patterns, and restrict egress.
Encryption and key management – Require AWS Key Management Service (AWS KMS) managed keys for all data-at-rest services and enforce key policies aligned with your sovereignty requirements.
Note: As additional EUSC Regions or Local Zones become available, the partition boundary continues to enforce isolation from non-EUSC Regions. If you need to restrict usage to a subset of EUSC Regions (for example, only eusc-de-east-1 but not a future eusc-de-west-1), a Region-deny SCP would become relevant at that point.
Identity: IAM Identity Center as IaC, no direct payer access
IAM Identity Center is available in the AWS European Sovereign Cloud as an independent instance within the partition. You can connect it to your external identity provider (IdP)—Microsoft Entra ID, Okta, and so on—using SAML/SCIM, exactly as in AWS commercial Regions. If you already use Identity Center to federate in the commercial partition, you can point a second Identity Center integration at the same corporate IdP, so users keep one set of credentials. You manage permission sets, groups, and account assignments separately for each partition.
Manage permission sets and assignments as code
The following Terraform defines a permission set with both an AWS managed policy and an inline least-privilege policy, then assigns a group to a target account. Reproduce the aws_ssoadmin_account_assignment for each account or organizational unit (OU) mapping.
Because group membership comes from your IdP over SCIM, the IdP handles joiner, mover, and leaver, and access in EUSC updates automatically. No one receives direct access to the management account; all human access flows through IAM Identity Center permission sets assigned to non-management accounts.
data "aws_ssoadmin_instances" "this" {}
data "aws_partition" "current" {}
# Workload account the group is assigned to.
variable "analytics_workload_account_id" {
type = string
description = "Account ID of the workload account to assign the permission set to"
}
locals {
sso_instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
identity_store_id = tolist(data.aws_ssoadmin_instances.this.identity_store_ids)[0]
}
resource "aws_ssoadmin_permission_set" "analytics_operator" {
name = "AnalyticsOperator"
description = "Operate analytics workloads; no IAM or billing"
instance_arn = local.sso_instance_arn
session_duration = "PT4H"
}
# Attach an AWS managed policy
resource "aws_ssoadmin_managed_policy_attachment" "analytics_ro" {
instance_arn = local.sso_instance_arn
permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
managed_policy_arn = "arn:${data.aws_partition.current.partition}:iam::aws:policy/ReadOnlyAccess"
}
# Add a least-privilege inline policy (note the partition-aware ARNs)
resource "aws_ssoadmin_permission_set_inline_policy" "analytics_inline" {
instance_arn = local.sso_instance_arn
permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
inline_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Sid = "OperateAnalyticsData"
Effect = "Allow"
Action = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
Resource = [
"arn:${data.aws_partition.current.partition}:s3:::analytics-*",
"arn:${data.aws_partition.current.partition}:s3:::analytics-*/*"
]
Condition = { StringEquals = { "aws:RequestedRegion" = "eusc-de-east-1" } }
}]
})
}
# Group for analytics operators.
# In production this is typically synced from your IdP via SCIM; here we
# manage it directly so the config is self-contained.
resource "aws_identitystore_group" "analytics" {
identity_store_id = local.identity_store_id
display_name = "analytics-operators"
description = "Analytics operators"
}
# Assign the group to a workload account with the permission set
resource "aws_ssoadmin_account_assignment" "analytics_to_workload" {
instance_arn = local.sso_instance_arn
permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
principal_id = aws_identitystore_group.analytics.group_id
principal_type = "GROUP"
target_id = var.analytics_workload_account_id
target_type = "AWS_ACCOUNT"
}
Cross-account roles for governance, logging, and tooling
Cross-account roles within the EUSC partition work normally; this is how the logging and security-tooling accounts collect from workload accounts. Scope each trust policy to a specific principal and harden it with an external ID (for third-party tooling) and partition-aware ARNs.
A role in the aws partition can’t assume a role in aws-eusc (or the reverse).
Logging and monitoring: centralized in EUSC, exported to your SIEM
A sovereign logging architecture requires three things:
A single, immutable store for all audit and operational logs
A central security account that runs detective controls and correlates findings
A reliable, in-partition path that feeds everything into your SIEM without data ever leaving the boundary.
In the subsections that follow, we walk through each layer: Centralized log collection in the Log Archive account, Amazon GuardDuty and AWS Security Hub administration through the Security Tooling account, and the pull-based SIEM integration pattern that keeps telemetry inside the EUSC partition.
Centralize logs in the Log Archive account
The Log Archive account holds the organization trail and a central log bucket as part of the landing zone. In the commercial AWS partition, global services like IAM route their CloudTrail events to us-east-1. In the EUSC, global services events are logged within the EUSC partition because the control plane is independent and located entirely within the EU.
Organization level detective services
GuardDuty and Security Hub are available in EUSC, but organization-wide auto-enable and some newer features might differ from commercial AWS features at any given time. Design the Security Tooling account as the delegated administrator where supported. If org-level auto-enable isn’t yet available, enable per-account through your IaC (AWS CloudFormation StackSets) so coverage is complete and code-managed. Treat the EUSC service and feature list as the source of truth and gate optional features behind a partition flag.
Network security and perimeter, including AWS Direct Connect
The AWS European Sovereign Cloud has its own sovereign AWS Direct Connect points of presence (PoPs), with dedicated networking infrastructure and connectivity from European providers, providing customers an autonomous network path into the partition. You terminate Direct Connect in a dedicated Network account and share connectivity to workload VPCs using Transit Gateway (with AWS RAM). A Direct Connect connection or Direct Connect gateway in the commercial partition can’t be extended into aws-eusc. To reach EUSC VPCs, you provision a separate Direct Connect connection that lands in the EUSC partition’s Network account. If your on-premises network already backhauls to AWS commercial Regions, you connect that network to EUSC with its own virtual interface or connection, or a site-to-site VPN. You don’t bridge the two AWS partitions through a shared Direct Connect gateway.
The following figure shows the recommended perimeter design in EUSC.
Figure 1: Recommended perimeter design in EUSC
The perimeter design includes:
Centralized egress and inspection – Route workload egress through an inspection VPC in the Network account (gateway load balancer with your firewall of choice, or AWS Network Firewall. Keep workload VPCs private with no internet gateway.
Private service access – Use VPC interface endpoints (VPCe) for AWS service calls so traffic stays on the AWS network within the partition. VPCe doesn’t cross partitions; expose any commercial-partition service to EUSC consumers over DX/VPN and an in-EUSC load balancer.
DNS – EUSC has its own Amazon Route 53. For names that must resolve across clouds, use subdomain delegation or Resolver forwarding rules over your DX or VPN link rather than expecting hosted zones to be visible across partitions.
Segmentation as code – Express segmentation with security groups referencing prefix lists and keep the EUSC IP ranges current from the partition’s published ip-ranges file in your firewall automation.
Data protection
AWS Key Management Service (AWS KMS) is available in EUSC; use customer managed keys for all sensitive data stores and enforce their use with SCPs and key policies. Where your residency or operational-autonomy requirements call for it, evaluate AWS KMS external and imported key material options available in the partition.
For workloads where regulation mandates that key material never resides within the cloud provider’s infrastructure, configure an AWS KMS External Key Store (XKS) in the EUSC Region. The XKS proxy connects AWS KMS to your EU-based hardware security module (HSM) (on-premises or hosted with an EU trust service provider); all encrypt and decrypt operations are performed by your external key manager. Note the trade-offs: increased latency, reduced availability SLA, and added operational burden. Reserve XKS for the subset of data where regulatory or contractual obligations explicitly require it.
The EUSC Region has achieved SOC 2, BSI C5 Type 1 attestation, and seven ISO certifications, including ISO 27001, 27017, 27018, and 27701. Reference these in your data protection evidence packages when demonstrating encryption-at-rest and key management controls to EU regulators.
Secure CI/CD and distributing images across the partition boundary
Container images – Build (or re-tag and re-sign) images and push to an Amazon ECR registry inside EUSC. ECR cross-Region replication works within the partition (useful as EUSC adds Regions or Local Zones), but the initial crossing from commercial is an explicit pipeline push using EUSC credentials. Sign images with a sovereign signing key and verify at deploy time.
AMIs and images – Rebuild golden images in EUSC with EC2 Image Builder (run the pipeline natively in EUSC), or import virtual machine (VM) images using Amazon S3 in EUSC and aws ec2 import-image. There is no direct cross-partition AMI copy.
Binaries and artifacts – Stage in an artifact bucket in the EUSC Shared Services account. Move packages across the boundary with aws s3 sync or AWS DataSync over your DX or VPN, or using controlled export, then distribute within the partition using in-partition S3 replication to other EUSC Regions or Local Zones as they come online.
# Push a container image to ECR inside EUSC (note the .eu endpoint).
# Credentials/profile must be for the aws-eusc partition.
aws ecr get-login-password --region eusc-de-east-1 --profile eusc-shared-services \
| docker login --username AWS --password-stdin \
111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu
docker tag company/runtime:7.x \
111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu/company/runtime:7.x
docker push \
111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu/company/runtime:7.x
Remember that endpoints and ARNs use amazonaws.eu in the EUSC partition. IAM service principals always use amazonaws.com regardless of partition.
Replicating deployment code and pipelines
Run a native deployment plane in EUSC (AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, or your existing tool deployed in-partition) in the Shared Services account, with cross-account deploy roles into workload accounts. If a commercial-partition continuous-integration system must deploy into EUSC, give it separate credentials for each partition; the clean pattern is OIDC federation with two trust configurations, one for each partition, because no cross-partition role assumption exists.
// Deploy role in an EUSC workload account, trusted by the EUSC Shared Services pipeline role
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws-eusc:iam::<SHARED_SERVICES_ACCT>:role/PipelineDeployRole" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "EUSC-deploy" } }
}]
}
For account vending and landing-zone-as-code, use Account Factory for Terraform (AFT) deployed in EUSC. AFT pipelines create accounts through AWS Control Tower, apply baseline guardrails, bootstrap the preceding partition-aware modules, and register OUs, giving you the accounts and account groups as code. Keep Terraform state for each partition in an in-EUSC Amazon S3 backend with an Amazon DynamoDB lock table; don’t share state across partitions.
The Landing Zone Accelerator on AWS (LZA) solution is an alternative deployment method that provisions a baseline security architecture and includes customizations for each partition, with consideration for service availability. A customized configuration baseline for European Sovereign Cloud was recently released and is accompanied by the LZA Compliance Workbook, which maps regional European security standards and international frameworks to over 200 security settings deployed by LZA.
Supported compared to by-design boundaries: A quick reference
Capability
Status in EUSC
What to do
AWS Control Tower account vending, controls
Supported in-partition
Govern the EUSC Region; drive vending with AFT; re-register OUs after Region changes
AWS Control Tower–managed or self-managed IAM Identity Center
Configuration choice
Choose self-managed to own permission sets as code
Permission set creation and assignment as IaC
Supported
Manage with SCIM groups from your IdP
Identity Center single home and delegated admin for each partition
By-design behavior
Administer from one Region; non-issue in single-Region EUSC
Roll up within the EUSC organization, not across partitions. Enable consolidated billing in the EUSC management account and deliver AWS Data Exports (Cost and Usage Report 2.0) to an S3 bucket in a dedicated finance or governance account in the Security or Infrastructure OU.
Set permissions so workload teams can query the curated data in that account; no one should be able to access the management or payer account directly. You can’t replicate billing data into the commercial partition; the EUSC has a separate payer (billed in EUR through the EU contracting entity).
Conclusion
Architecting in the AWS European Sovereign Cloud is, in most respects, architecting a second well-run AWS landing zone with one organizing principle that resolves nearly every design question: it’s an independent partition. Centralization of governance, identity, logging, and billing is fully achievable, but within the EUSC partition. The boundaries you encounter between commercial AWS and EUSC—no cross-partition roles, peering, replication, or billing roll-up—are the sovereignty guarantees doing their job.
Build the foundation as code. Use an AWS Control Tower landing zone driven by AFT, IAM Identity Center permission sets and assignments in Terraform federated to your corporate IdP, an immutable central log store, customer managed encryption keys constrained to the sovereign Region, and a Network account terminating a dedicated Direct Connect. Add a CI/CD plane that pushes images and artifacts into the partition with per-partition credentials. Keep every ARN partition-aware and every optional service behind a feature flag, and the same modules will serve both clouds.
To accelerate your build with additional enablement from AWS, explore the LZA Universal Configuration for European Sovereign Cloud on GitHub, which packages many of the patterns described in this post into a ready-to-deploy baseline. To complement your deployment with compliance readiness, the LZA Independent Assessment Report for C5:2020 evaluates how LZA’s security baseline maps to C5:2020 technical requirements, and you can download the report and the LZA Compliance Workbook from AWS Artifact.
If you have feedback about this post, submit comments in the Comments section below or start a thread on AWS re:Post.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.