The AWS User Group Zrenjanin recently held its second meetup, continuing its mission to build and strengthen the cloud community in Serbia. This time, the speakers were Nikola Đorđević, Solution Architect and Duško Milićev, DevOps Engineer. As a new group within AWS Community Serbia, we’re excited to grow, connect, and share knowledge with cloud enthusiasts across the country.
Building on the success of the first meetup, which focused on AWS Landing Zones, this session tackled an increasingly critical topic in cloud computing: digital sovereignty. The timing couldn’t be more relevant, as AWS prepares to launch its Sovereign Cloud in Europe within the next month, further strengthening the digital sovereignty narrative for European clients.
Why Digital Sovereignty Matters for Our Projects
Digital sovereignty isn’t a new concept, but as our speakers emphasized, it’s becoming increasingly critical to implement it in practice across our client projects. The driving forces behind this shift are creating real challenges that we help our clients navigate daily.
The current business landscape is marked by escalating geopolitical tensions that require greater data control, stricter regulatory requirements with substantial penalties for non-compliance, and growing client demand to know exactly where their data resides, who can access it, and who manages it. These aren’t abstract concerns – they directly impact how we architect and deliver solutions.
Impact Across Our Client Sectors
Many of our clients operate in highly regulated industries where digital sovereignty has become essential rather than optional. The public sector handles massive amounts of personal data and classified information, from defense ministries to government agencies. Financial services clients cannot afford any downtime and must maintain continuous operations with secure data. Healthcare organizations must protect sensitive patient data under increasingly strict regulations. And critical infrastructure providers, managing energy, water supply, and other strategically important systems, face unique sovereignty challenges that require careful architectural planning.
Understanding the Risks
Our experts highlighted three major consequences of inadequate digital sovereignty that directly impact project success and client relationships. Regulatory penalties are no longer symbolic fines but substantial amounts that can threaten business viability. Data breaches lead to loss of client trust and potential business closure, creating reputational damage that extends far beyond immediate financial costs. Business continuity failures, whether through data loss or service interruptions, can halt operations completely. Understanding these risks helps us position our expertise and guide clients toward resilient, compliant solutions.
AWS’s Sovereign-by-Design Philosophy
Understanding AWS’s approach helps us better serve our clients and make informed architectural decisions. After conducting extensive interviews with customers, AWS recognized that digital sovereignty rests on two fundamental pillars that shape how we design and implement cloud solutions.
The first pillar, data sovereignty, focuses on giving clients complete control over data location – explicitly choosing where their data resides – along with granular access management that determines who can access data and how, plus full oversight of data governance through the entire lifecycle.
The second pillar, operational sovereignty, emphasizes resilience and sustainability so that business operations can withstand outages, while also ensuring independence and transparency to avoid vendor lock-in and maintain clear operational visibility. This dual approach informs our architectural decisions and helps us guide clients through complex compliance requirements.
The AWS Digital Sovereignty Pledge
AWS has formalized its commitment through the Digital Sovereignty Pledge, which provides concrete guarantees that shape our project implementations. Customers have always controlled the location of their data with AWS, and the company pledges never to copy or move client data without explicit permission. This location control gives clients the certainty they need for compliance.
The pledge also promises verifiable control over data access through highly detailed control mechanisms that allow precise definition of who can access what, at the service, role, and user levels. This granularity is essential for our clients in regulated industries.
At the infrastructure level, the AWS Nitro System serves as the core technology behind AWS compute services. Using dedicated hardware and software, Nitro keeps data protected while it’s being processed on Amazon EC2. It creates a strong security boundary – both physical and logical – ensuring that no one, not even AWS employees, can access workloads running on EC2 without explicit authorization.
Encryption represents another critical commitment. All AWS services already support encryption, and most of them support encryption with customer-managed keys that are inaccessible to AWS. This “encrypt everything everywhere” approach covers data in transit, at rest, and in memory, giving clients multiple layers of protection.
Finally, built-in resilience means all services are designed to be resilient by default, with options to withstand failures at zone or region levels. This architectural approach supports our disaster recovery and business continuity planning for client projects.
Four Critical Client Questions We Address
Based on AWS’s research and our project experience, clients consistently ask four fundamental questions that guide our architectural discussions. They want to know where their data actually is, whether it’s truly in the specified region or somewhere else. They’re concerned about who can access their data, whether it’s just them, AWS operators, or potentially federal agencies. Compliance is always top of mind: does moving to the cloud maintain alignment with applicable regulations? And security remains paramount: will business continuity be maintained if something unexpected happens? Our role is to provide clear, evidence-based answers to these questions while implementing appropriate controls.
Essential AWS Services for Our Projects
Several AWS services form the foundation of our digital sovereignty implementations, each serving a specific purpose in our overall architecture.
AWS Identity and Access Management (IAM) provides the granular control over access that clients need, offering roles, policies, and comprehensive permission management. This service becomes the backbone of our access control strategy across all projects.
CloudTrail enables continuous monitoring of all system activities and API calls, providing the full transparency that both we and our clients need for audit and compliance purposes. Every action is logged, creating an immutable record of who did what and when.
AWS Key Management Service (KMS) addresses encryption requirements. While AWS-managed encryption is convenient for many use cases since it handles key rotation automatically, sectors like finance often require custom keys. KMS supports importing and managing customer-owned encryption keys, giving clients complete control when they need it.
The Nitro System, which has been running all AWS infrastructure since 2018, is a lightweight hypervisor designed with isolation in mind. This hardware-enforced security layer provides an additional level of assurance for clients with the highest security requirements.
Accelerating Compliance for Clients
One of our key value propositions is helping clients achieve and maintain compliance more efficiently. AWS provides several tools that support this work.
AWS Artifact serves as a comprehensive repository where clients can find all relevant compliance documentation. With support for over 140 security standards and 240+ regulatory frameworks, it becomes our central reference point for compliance requirements. Instead of piecing together compliance information from multiple sources, we can show clients exactly how AWS services map to their specific regulatory needs.
The Landing Zone Accelerator on AWS has transformed how we set up cloud foundations for clients. It implements sovereign-by-design principles from the start, following AWS best practices and major global compliance standards. This tool is particularly valuable for clients with highly regulated workloads or complex compliance needs, as it compresses what used to take months of manual configuration into a much shorter timeframe.
For more complex scenarios, the Global Security and Compliance Acceleration Program provides additional support. This free AWS service connects organizations with AWS experts and trusted partners who guide them from migration to compliance, making it easier and faster to build secure, sovereignty-aligned cloud environments. We leverage this program when clients have particularly challenging compliance requirements.
It’s important to remember that AWS operates on a Shared Responsibility Model. AWS manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. Meanwhile, we remain responsible for applications, data, and platform configurations in our client projects. This division of responsibility shapes how we approach security and compliance across all layers of the stack.
Addressing Portability Challenges
European clients increasingly demand portability – the ability to move workloads between cloud providers – and this requirement shapes our architectural decisions. While AWS and other providers are working on improving portability, the reality is that not all services are implemented identically across different cloud platforms.
Our approach involves examining available options, evaluating potential benefits, and estimating development time before making recommendations. The rule of thumb we follow is to use managed services where they make sense and provide clear value, but to remain aware of dependencies and potential lock-in. This balanced perspective helps clients make informed decisions about service adoption based on their specific portability requirements.
AWS GuardDuty: Proactive Threat Detection
One of the services our experts highlighted in detail was AWS GuardDuty, which represents a shift from reactive to proactive security. This machine learning-powered threat detection service continuously monitors DNS logs, network traffic, and API calls, analyzing patterns to detect anomalies and suspicious activities. Rather than simply recording what happened, GuardDuty provides probability scores for potential threats and can trigger automated responses through integration with other services.
The distinction between GuardDuty and CloudTrail is important to understand. CloudTrail provides an audit trail showing who did what – it’s our record of all actions taken in the AWS environment. GuardDuty, on the other hand, uses machine learning to detect threats and anomalies based on those logs, identifying patterns that might indicate security issues. Think of CloudTrail as the recording and GuardDuty as the intelligent analysis.
The recommendation from our experts is clear: combine GuardDuty with AWS Security Hub, AWS WAF, and AWS Shield for comprehensive protection. The goal is to be proactive rather than reactive, minimizing both risk and response time. This layered security approach has proven effective across our client implementations.
Practical Security Best Practices
The session concluded with several practical recommendations that apply directly to our daily project work. When it comes to S3 bucket security, the rule is simple: never leave S3 buckets public if they contain client data. We should use AWS Config to manage the desired state and enable automatic remediations in case of non-conformity, tightening security with proper policies and encryption at all stages of the data lifecycle.
Data classification deserves special attention. We should automate data classification processes and create actions and guardrails to maintain proper classification over time. Generated or synthetic data used for testing can be handled more flexibly, but production data must remain local, encrypted, and within defined geographic boundaries. This distinction helps us balance operational efficiency with security requirements.
Key Takeaways
Several clear messages emerged from the presentation that should guide your approach to future projects. First, digital sovereignty is no longer optional – it’s becoming a fundamental requirement for cloud deployments, especially in regulated industries. This shift means we need to factor sovereignty considerations into our initial architectural discussions rather than treating them as add-ons.
Second, while AWS provides comprehensive tools for implementing digital sovereignty, we must actively engage with them and implement best practices. The tools exist, but they require thoughtful configuration and ongoing management. Our expertise lies in knowing how to use these tools effectively.
Third, the shared responsibility model means we own the application layer, data, and configurations in client projects. We can’t assume that moving to AWS automatically makes everything secure and compliant—our architectural decisions and implementation practices matter enormously.
Fourth, a proactive approach pays dividends. Implementing sovereignty best practices from the start, especially for projects handling sensitive data or operating in regulated industries, prevents costly retrofitting later. It’s far easier to build in sovereignty controls from the beginning than to add them after the fact.
Finally, staying informed matters. As geopolitical tensions continue and regulations tighten, the organizations that prioritize digital sovereignty today will be best positioned for tomorrow’s challenges. Our participation in events like this AWS User Group meetup keeps us at the forefront of cloud best practices.
In this article:
