Yearly Archives: 2024

[$] Another try for getrandom() in the vDSO

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

Random numbers, it seems, can never be random enough, and they cannot be
generated quickly enough. The kernel’s getrandom()
system call might, after years of discussion, be seen as sufficiently
secure by most users, but it is still a system call. Linux system calls
are relatively fast, but they are necessarily slower than calling a
function directly. In an attempt to speed the provision of secure random
data to user space, Jason Donenfeld has put together an
implementation of getrandom() that lives in the virtual dynamic
shared object (vDSO) area.

Security updates for Thursday

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

Security updates have been issued by AlmaLinux (389-ds, c-ares, container-tools, cups, fontforge, go-toolset, iperf3, less, libreoffice, libuv, nghttp2, openldap, python-idna, python-jinja2, python-pillow, python3, python3.11-PyMySQL, qemu-kvm, and xmlrpc-c), Debian (znc), Fedora (firmitas and libnbd), Mageia (dcmtk, krb5, libcdio, and openssh), Oracle (golang, openssh, pki-core, and qemu-kvm), Red Hat (openssh), SUSE (apache2-mod_auth_openidc, emacs, go1.21, go1.22, krb5, openCryptoki, and openssh), and Ubuntu (linux, linux-aws, linux-aws-hwe, linux-gcp, linux-gcp-4.15, linux-hwe,
linux-kvm, linux-oracle, linux, linux-aws, linux-azure, linux-azure-5.4, linux-bluefield,
linux-gcp, linux-gkeop, linux-hwe-5.4, linux-ibm, linux-ibm-5.4,
linux-iot, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi,
linux-raspi-5.4, linux-xilinx-zynqmp, linux, linux-aws, linux-kvm, linux-lts-xenial, linux, linux-gcp, linux-gcp-6.5, linux-laptop, linux-nvidia-6.5,
linux-raspi, linux, linux-gcp, linux-lowlatency, linux-lowlatency-hwe-5.15,
linux-nvidia, linux-xilinx-zynqmp, linux, linux-ibm, linux-lowlatency, linux-nvidia, linux-raspi, linux-aws, linux-aws-6.5, linux-oem-6.5, linux-oracle, linux-oracle-6.5,
linux-starfive, linux-aws, linux-azure, linux-azure-5.15, linux-azure-fde,
linux-azure-fde-5.15, linux-gke, linux-gkeop, linux-gkeop-5.15, linux-ibm,
linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-oracle,
linux-oracle-5.15, linux-azure, linux-azure, linux-azure-6.5, linux-bluefield, linux-iot, linux-gcp, linux-intel, linux-hwe-5.15, and php7.0 and php7.2).

Cloudflare 1.1.1.1 incident on June 27, 2024

Post Syndicated from Bryton Herdes original https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024


Introduction

On June 27, 2024, 1.1.1.1 became unreachable or heavily degraded from over 300 networks in 70 countries. The root cause was a mix of BGP (Border Gateway Protocol) hijacking and a route leak.

Cloudflare was an early adopter of Resource Public Key Infrastructure (RPKI) for route origin validation (ROV). With RPKI, IP prefix owners can store and share ownership information securely, and other operators can validate BGP announcements by comparing received BGP routes with what is stored in the form of Route Origin Authorizations (ROAs). When Route Origin Validation is enforced by networks properly and prefixes are signed via ROA, the impact of a BGP hijack is greatly limited. Despite increased adoption of RPKI over the past several years and 1.1.1.0/24 being a signed resource, during the incident 1.1.1.1/32 was originated by ELETRONET S.A. (AS267613) and accepted by multiple networks, including at least one Tier 1 provider who accepted 1.1.1.1/32 as a blackhole route. This ultimately caused immediate unreachability for the DNS resolver address from much of the world.

Route leaks are something Cloudflare has written and talked about before, and unfortunately there are only best-effort safeguards in wide deployment today, such as IRR (Internet Routing Registry) prefix-list filtering by providers. During the same period of time as the 1.1.1.1/32 hijack, 1.1.1.0/24 was erroneously leaked upstream by Nova Rede de Telecomunicações Ltda (AS262504). The leak was further and widely propagated by Peer-1 Global Internet Exchange (AS1031), which also contributed to the impact felt by customers during the incident.

We apologize for the impact felt by users of 1.1.1.1, and take the operation of the service very seriously. Although the root cause of the impact was external to Cloudflare, we will continue to improve the detection methods in place to yield quicker response times, and will use our stance within the Internet community to further encourage adoption of RPKI-based hijack and leak prevention mechanisms such as Route Origin Validation (ROV) and Autonomous Systems Provider Authorization (ASPA) objects for BGP.

Background

Cloudflare introduced the 1.1.1.1 public DNS resolver service in 2018. Since the announcement, 1.1.1.1 has become one of the most popular resolver IP addresses that is free-to-use by anyone. Along with the popularity and easily recognized IP address comes some operational difficulties. The difficulties stem from historical use of 1.1.1.1 by networks in labs or as a testing IP address, resulting in some residual unexpected traffic or blackholed routing behavior. Because of this, Cloudflare is no stranger to dealing with the effects of BGP misrouting traffic, two of which are covered below.

BGP hijacks

Some of the difficulty comes from potential routing hijacks of 1.1.1.1. For example, if some fictitious FooBar Networks (AS65001) assigns 1.1.1.1/32 to one of their routers and shares this prefix within their internal network, their customers will have difficulty routing to the 1.1.1.1 DNS service. If they advertise the 1.1.1.1/32 prefix outside their immediate network, the impact can be even greater. The reason 1.1.1.1/32 would be selected instead of the 1.1.1.0/24 BGP-announced by Cloudflare is due to Longest Prefix Matching (LPM). While many prefixes in a route table could match the 1.1.1.1 address, such as 1.1.1.0/24, 1.1.1.0/29, and 1.1.1.1/32, 1.1.1.1.1/32 is considered the “longest match” by the LPM algorithm because it has the highest number of identical bits and longest subnet mask while matching the 1.1.1.1 address. In simple terms, we would call 1.1.1.1/32 the “most specific” route available to 1.1.1.1.

Instead of traffic toward 1.1.1.1 routing to Cloudflare via anycast and landing on one of our servers globally, it will instead land somewhere on a device within FooBar Networks where 1.1.1.1 is terminated, and a legitimate response will fail to be served back to clients. This would be considered a hijack of requests to 1.1.1.1, either done purposefully or accidentally by network operators within FooBar Networks.

BGP route leaks

Another source of impact we sometimes face for 1.1.1.1 is BGP route leaks. A route leak occurs when a network becomes an upstream, in terms of BGP announcement, for a network it shouldn’t be an upstream provider for.

Here is an example of a route leak where a customer forward routes learned from one provider to another, causing a type 1 leak (defined in RFC7908).

If enough networks within the Default-Free Zone (DFZ) accept a route leak, it may be used widely for forwarding traffic along the bad path. Often this will cause the network leaking the prefixes to overload, as they aren’t prepared for the amount of global traffic they are now attracting. We wrote about a wide-scale route leak that knocked off a large portion of the Internet, when a provider in Pennsylvania attracted traffic toward global destinations it would have typically never transited traffic for. Even though Cloudflare interconnects with over 13,000 networks globally, the BGP local-preference assigned to a leaked route could be higher than the route received by a network directly from Cloudflare. This sounds counterproductive, but unfortunately it can happen.

To explain why this happens, it helps to think of BGP as a business policy engine along with the routing protocol for the Internet. A transit provider has customers who pay them to transport their data, so logically they assign a higher BGP local-preference than connections with either private or Internet Exchange (IX) peers, so the connection being paid for is most utilized. Think of local-preference as a way of influencing priority of which outgoing connection to send traffic to. Different networks also may choose to prefer Private Network Interconnects (PNIs) over Internet Exchange (IX) received routes. Part of the reason for this is reliability, as a private connection can be viewed as a point-to-point connection between two networks with no third-party managed fabric in between to worry about. Another reason could be cost efficiency, as if you’ve gone to the trouble to allocate a router port and purchase a cross connect between yourself and another peer, you’d like to make use of it to get the best return on your investment.

It is worth noting that both BGP hijacks and route leaks can happen to any IP and prefix on the Internet, not just 1.1.1.1. But as mentioned earlier, 1.1.1.1 is such a recognizable and historically misappropriated address that it tends to be more prone to accidental hijacks or leaks than other IP resources.

During the Cloudflare 1.1.1.1 incident that happened on June 27, 2024, we ended up fighting the impact caused by a combination of both BGP hijacking and a route leak. One alone is enough to cripple a service, but the two paired together can be significantly more impactful.

Incident timeline and impact

All timestamps are in UTC.

2024-06-27 18:51:00 AS267613 (Eletronet) begins announcing 1.1.1.1/32 to peers, providers, and customers. 1.1.1.1/32 is announced with the AS267613 origin AS

2024-06-27 18:52:00 AS262504 (Nova) leaks 1.1.1.0/24, also received from AS267613, upstream to AS1031 (PEER 1 Global Internet Exchange) with AS path “1031 262504 267613 13335”

2024-06-27 18:52:00 AS1031 (upstream of Nova) propagates 1.1.1.0/24 to various Internet Exchange peers and route-servers, widening impact of the leak

2024-06-27 18:52:00 One tier 1 provider receives the 1.1.1.1/32 announcement from AS267613 as a RTBH (Remote Triggered Blackhole) route, causing blackholed traffic for all the tier 1’s customers

2024-06-27 20:03:00 Cloudflare raises internal incident for 1.1.1.1 reachability issues from various countries

2024-06-27 20:08:00 Cloudflare disables a partner peering location with AS267613 that is receiving traffic toward 1.1.1.0/24

2024-06-27 20:08:00 Cloudflare team engages peering partner AS267613 about the incident

2024-06-27 20:10:00 AS262504 leaks 1.1.1.0/24 with a new AS path, “262504 53072 7738 13335” which is also redistributed by AS1031. Traffic is being delivered successfully to Cloudflare when along this path, but with high latency for affected clients

2024-06-27 20:17:00 Cloudflare engages AS262504 regarding the route leak of 1.1.1.0/24 to their upstream providers

2024-06-27 21:56:00 Cloudflare engineers disable a second peering point with AS267613 that is receiving traffic meant for 1.1.1.0/24 from multiple sources not in Brazil

2024-06-27 22:16:00 AS262504 leaks 1.1.1.0/24 again, attracting some traffic to a Cloudflare peering with AS267613 in São Paulo. Some 1.1.1.1 requests as a result are returned with higher latency, but the hijack of 1.1.1.1/32 and traffic blackholing appears resolved

2024-06-28 02:28:00 AS262504 fully resolves the route leak of 1.1.1.0/24

The impact to customers surfaced in one of two ways: unable to reach 1.1.1.1 at all; Able to reach 1.1.1.1, but with high latency per request.

Since AS267613 was hijacking the 1.1.1.1/32 address somewhere within their network, many requests failed at some device in their autonomous system. There were intermittent periods, or flaps, during the incident where they successfully routed requests toward 1.1.1.1 to Cloudflare data centers, albeit with high latency.

Looking at two source countries during the incident, Germany and the United States, impacted traffic to 1.1.1.1 looked like this:

Source Country of Users:

Cloudflare Data Center city:

Looking at the graphs, requests to 1.1.1.1 were landing in Brazilian data centers. The gaps between the spikes are when 1.1.1.1 requests were blackholed prior to or within AS267613, and the spikes themselves are when traffic was delivered to Cloudflare with high latency invoked on the request and response. The brief spikes of traffic successfully carried to the Cloudflare peering location with AS267613 could be explained by the 1.1.1.1/32 route flapping within their network, occasionally letting traffic through to Cloudflare instead of it dropping somewhere in the intermediate path.

Technical description of the error and how it happened

Normally, a request to 1.1.1.1 from users routes to the nearest data center via BGP anycast. During the incident, AS267613 (Eletronet) advertised 1.1.1.1/32 to their peers and upstream providers, and AS262504 leaked 1.1.1.0/24 upstream, changing the normal path of BGP anycast for multiple eyeball networks drastically.

With public route collectors and the monocle tool, we can search for the rogue BGP updates.

monocle search --start-ts 2024-06-27T18:51:00Z --end-ts 2024-06-27T18:55:00Z --prefix '1.1.1.1/32'

A|1719514377.130203|206.126.236.209|398465|1.1.1.1/32|398465 267613|IGP|206.126.236.209|0|0||false|||route-views.eqix
–
A|1719514377.681932|206.82.104.185|398465|1.1.1.1/32|398465 267613|IGP|206.82.104.185|0|0|13538:1|false|||route-views.ny
–
A|1719514388.996829|198.32.132.129|13760|1.1.1.1/32|13760 267613|IGP|198.32.132.129|0|0||false|||route-views.telxatl

We see above that AS398465 and AS13760 reported to the route-views collectors that they received 1.1.1.1/32 from AS267613 around the time impact begins. Normally, the longest IPv4 prefix accepted in the Default-Free-Zone (DFZ) is a /24, but in this case we observed multiple networks using the 1.1.1.1/32 route from AS267613 for forwarding, made apparent by the blackholing of traffic that never arrived at a Cloudflare POP (Point of Presence). The origination of 1.1.1.1/32 by AS267613 is a BGP route hijack. They were announcing the prefix with origin AS267613 even though the Route Origin Authorization (ROA) is only signed for origin AS13335 (Cloudflare) with a maximum prefix length of /24.

We even saw BGP updates for 1.1.1.1/32 when looking at our own BMP (BGP Monitoring Protocol) data at Cloudflare. From at least a couple different route servers, we received our own 1.1.1.1/32 announcement via BGP. Thankfully, Cloudflare rejects these routes on import as both RPKI Invalid and DFZ Invalid due to invalid AS origin and prefix length. The BMP data display is pre-policy, meaning even though we rejected the route we can see where we receive the BGP update over a peering session.

So not only are multiple networks accepting prefixes that should not exist in the global routing table, but they are also accepting an RPKI (Resource Public Key Infrastructure) Invalid route. To make matters worse, one Tier-1 transit provider accepted the 1.1.1.1/32 announcement as a RTBH (Remote-Triggered Blackhole) route from AS267613, discarding all traffic at their edge that would normally route to Cloudflare. This alone caused wide impact, as any networks leveraging this particular Tier-1 provider in routing to 1.1.1.1 would have been unable to reach the IP address during the incident.

For those unfamiliar with Remote-Triggered Blackholing, it is a method of signaling to a provider a set of destinations you would like traffic to be dropped for within their network. It exists as a blunt method of fighting off DDoS attacks. When you are being attacked on a specific IP or prefix, you can tell your upstream provider to absorb all traffic toward that destination IP address or prefix by discarding it before it comes to your network port. The problem during this incident was AS267613 was unauthorized to blackhole 1.1.1.1/32. Cloudflare only should have the sole right to leverage RTBH for discarding of traffic destined for AS13335, which is something we would in reality never do.

Looking now at BGP updates for 1.1.1.0/24 multiple networks received the prefix from AS262504 and accepted it.

~> monocle search --start-ts 2024-06-27T20:10:00Z --end-ts 2024-06-27T20:13:00Z --prefix '1.1.1.0/24' --as-path ".* 267613 13335" --include-sub

.. some advertisements removed for brevity ..

A|1719519011.378028|187.16.217.158|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|187.16.217.158|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views2.saopaulo
–
A|1719519011.629398|45.184.147.17|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|45.184.147.17|0|0|1031:1031 1031:4209 1031:4259 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519036.943174|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|route-views.amsix
–
A|1719519037|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|rrc03
–
A|1719519087.4546|45.184.146.59|199524|1.1.1.0/24|199524 1031 262504 267613 13335|IGP|45.184.147.17|0|0||false|13335|162.158.177.1|route-views.fortaleza
A|1719519087.464375|45.184.147.74|264409|1.1.1.0/24|264409 1031 262504 267613 13335|IGP|45.184.147.74|0|0|65100:7010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519096.059558|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3
–
A|1719519128.843415|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3

Here we pay attention to the AS path again. This time, AS13335 is the origin AS at the very end of the announcements. This BGP announcement is RPKI Valid, because the origin is correctly AS13335, but this is a route leak of 1.1.1.0/24 because the path itself is invalid.

How do we know it’s a route leak?

Looking at an example path, “199524 1031 262504 267613 13335”, AS267613 is functionally a peer of AS13335 and should not share the 1.1.1.0/24 announcement with their peers or upstreams, only their customers (AS Cone). AS262504 is a customer of AS267613 and the next adjacent ASN in the path, so that particular announcement is fine up until this point. Where the 1.1.1.0/24 goes wrong is AS262504, when they announce the prefix to their upstream AS1031. Furthermore, AS1031 redistributed the advertisement to their peers.

This means AS262504 is the leaking network. AS1031 accepted the leak from their customer, AS262504, and caused wide impact by distributing the route in multiple peering locations globally. AS1031 (Peer-1 Global Internet Exchange) advertises themselves as a global peering exchange. Cloudflare is not a customer of AS1031, so 1.1.1.0/24 should have never been redistributed to peers, route-servers, or upstreams of AS1031. It appears that AS1031 does not perform any extensive filtering for customer BGP sessions, and instead just matches on adjacency (in this case, AS262504) and redistributes everything that meets this criteria. Unfortunately, this is irresponsible of AS1031 and causes direct impact to 1.1.1.1 and potentially other services that fall victim to the unguarded route propagation. While the original leaking network was AS262504, impact was greatly amplified by AS1031 and others when they accepted the hijack or leak and further distributed the announcements.

During the majority of the incident, the leak by AS262504 eventually landed requests within AS267613, which was discarding 1.1.1.1/32 traffic somewhere in their network. To that end, AS262504 really just amplified the impact in terms of 1.1.1.1 unreachability by leaking routes upstream.

To limit impact of the route leak, Cloudflare disabled peering in multiple locations with AS267613. The problem did not completely go away, as AS262504 was still leaking a stale path pointing to São Paulo. Requests landing in São Paulo were able to be served, albeit with a high round-trip time back to users. Cloudflare has been engaging with all networks mentioned throughout this post in regard to the leak and future prevention mechanisms, as well as at least one Tier 1 transit provider who accepted 1.1.1.1/32 from AS267613 as a blackhole route that was unauthorized by Cloudflare and caused widespread impact.

Remediation and follow-up steps

BGP hijacks

RPKI origin validation
RPKI has recently reached a major milestone at 50% deployment in terms of prefixes signed by Route Origin Authorization (ROA). While RPKI certainly helps limit the spread of a hijacked BGP prefix throughout the Internet, we need all networks to do their part, especially major networks with a large sum of downstream Autonomous Systems (AS’s). During the hijack of 1.1.1.1/32, multiple networks accepted and used the route announced by AS267613 for traffic forwarding.

RPKI and Remote-Triggered Blackholing (RTBH)
A significant amount of the impact caused during this incident was due to a Tier 1 provider accepting 1.1.1.1/32 as a blackhole route from a third party that is not Cloudflare. This in itself is a hijack of 1.1.1.1, and a very dangerous one. RTBH is a useful tool used by many networks when desperate for a mitigation against large DDoS attacks. The problem is the BGP filtering used for RTBH is loose in nature, relying often only on AS-SET objects found in Internet Routing Registries. Relying on Route Origin Authorization (ROA) would be infeasible for RTBH filtering, as that would require thousands of potential ROAs be created for the network the size of Cloudflare. Not only this, but creating specific /32 entries opens up the potential for an individual address such as 1.1.1.1/32 being announced by someone pretending to be AS13335, becoming the best route to 1.1.1.1 on the Internet and causing severe impact.

AS-SET filtering is not representative of authority to blackhole a route, such as 1.1.1.1/32. Only Cloudflare should be able to blackhole a destination it has the rights to operate. A potential way to fix the lenient filtering of providers on RTBH sessions would again be leveraging an RPKI. Using an example from the IETF, the expired draft-spaghetti-sidrops-rpki-doa-00 proposal specified a Discard Origin Authorization (DOA) object that would be used to authorize only specific origins to authorize a blackhole action for a prefix. If such an object was signed, and RTBH requests validated against the object, the unauthorized blackhole attempt of 1.1.1.1/32 by AS267613 would have been invalid instead of accepted by the Tier 1 provider.

BGP best practices
Simply following BGP best practices laid out by MANRS, and rejecting IPv4 prefixes that are longer than a /24 in the Default-Free Zone (DFZ) would have reduced impact to 1.1.1.1. Rejecting invalid prefix lengths within the wider Internet should be part of a standard BGP policy for all networks.

BGP route leaks

Route leak detection

While route leaks are not unavoidable for Cloudflare today, because the Internet inherently relies on trust for interconnection, there are some steps we will take to limit impact.

We have expanded data sources to use for our route leak detection system to cover more networks and are in the process of incorporating real-time data into the detection system to allow more timely response toward similar events in the future.

ASPA for BGP

We will continue advocating for the adoption of RPKI into AS Path based leak route leak prevention. Autonomous System Provider Authorization (ASPA) objects are similar to ROAs, except instead of signing prefixes with an authorized origin AS, the AS itself is signed with a list of provider networks that are allowed to propagate their routes. So, in the case of Cloudflare, only valid upstream transit providers would be signed as authorized to advertise AS13335 prefixes such as 1.1.1.0/24 upstream.

In the route leak example where AS262504 (customer of AS267613) shared 1.1.1.0/24 upstream, BGP ASPA would see this as an invalid valley leak if AS267613 had signed their authorized providers and AS1031 had validated paths against that list. Similar to RPKI origin validation, however, this will be a long-term effort and dependent on networks, especially large providers, rejecting invalid AS paths as based on ASPA objects.

Other potential approaches

There are alternative approaches to ASPA that do exist, in various stages of adoption that may be worth noting. There is no guarantee that the following make it to a stage of wide Internet deployment, however.

RFC9234, for example, uses a concept of peer roles within BGP capabilities and attributes, and depending on the configuration of routers along a path for updates, an “Only-To-Customer” (OTC) attribute can be added to prefixes that will prevent the upstream spread of a prefix such as 1.1.1.0/24 along a leaked path. The downside is BGP configuration needs to be completed to assign the various roles to each peering session, and vendor adoption still has to be fully ironed out to make this feasible for actual use in production with positive results.

Like all approaches to solving route leaks, cooperation amongst network operators on the Internet is required for success.

Conclusion

Cloudflare’s 1.1.1.1 DNS resolver service fell victim to a simultaneous BGP hijack and BGP route leak event. While the actions of external networks are outside of Cloudflare’s direct control, we intend to take every step within both the Internet community and internally at Cloudflare to detect impact more quickly and lessen impact to our users.

Long term, Cloudflare continues to support adoption of RPKI-based origin validation, as well as AS path validation. The former exists with deployment across a wide array of the world’s largest networks, and the latter is still in draft phase at the IETF (Internet Engineering Task Force). In the meantime, to check if your ISP is enforcing RPKI origin validation, you can always visit isbgpsafeyet.com and Test Your ISP.

Не разпадане, а прегрупиране на сивата държава

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2024/siva-darjava/

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

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

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

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

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

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

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

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

Та не гледам на шумните събития в ДПС – както и по-малко публичните в ГЕРБ и БСП и другите комични в партията-пирамида – като на разпадане, а като прегрупиране и престрелка в мафиотската структура, която наричаме политико-икономически зависимости. Стрелят все още само служби, полиция и прокуратура по нареждане от който трябва. Те така са свикнали, така са правили десетилетия и надали някой сред тях ще очаква вие или аз да го защитим, ако нададе глава, нали? Дали?

The post Не разпадане, а прегрупиране на сивата държава first appeared on Блогът на Юруков.

Демокрация в упадък. Правителство – наесен

Post Syndicated from Емилия Милчева original https://www.toest.bg/demokratsiya-v-upaduk-pravitelstvo-naesen/

Демокрация в упадък. Правителство – наесен

Тъжно за политиците, жалко за държавата – България с бясна скорост се носи към седми поред предсрочни парламентарни избори, най-вероятно през октомври. Упадъкът на демокрацията продължава, партиите крепят фасадата ѝ. Провалът на първия мандат за съставяне на правителство на ГЕРБ–СДС потопи и следващите два, тъй като е невъзможно да съберат необходимото за подкрепа мнозинство. 

Кабинетът с министър-председател Росен Желязков, предложен с първия мандат на ГЕРБ–СДС, получи подкрепа единствено от 68-те депутати на ГЕРБ–СДС и 30 от ДПС, определени като евроатлантици от съпредседателя Делян Пеевски. 

Други 14 народни представители от ДПС обаче бяха против, както призова почетният председател на ДПС Ахмед Доган, а Джейхан Ибрямов, един от зам.-председателите на ДПС, се въздържа, но изпрати позиция до медиите, че всъщност е гласувал против и вотът му не е отчетен правилно. Между другото, наскоро беше съобщено, че неговата съпруга Биршен Ибрямова, която е била дългогодишна лична секретарка на Доган, е освободена от централата на партията. Сред гласувалите против в ДПС е и съпредседателят на Движението Джевдет Чакъров. 

Въздържал се имаше в групата на ПП–ДБ, останалите 38 бяха против. Срещу редовен кабинет гласуваха всички 38 депутати от „Възраждане“, 16-те от „Има такъв народ“, както и всички 13 избраници на „Величие“. 17-те присъстващи депутати от „БСП за България“ бяха против, също и изключеният от БСП Калоян Методиев.

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

Каквито и да са резултатите на следващи избори, те ще потвърдят силната фрагментация, характерна от няколко години за българските парламенти и предопределяща коалиционно управление, тъй като всички са твърде малки, за да управляват сами. На фона на ниската избирателна активност победители и категорични мнозинства отдавна няма. Има само политически сили, спечелили малко повече от другите. За сравнение, на парламентарните избори на 4 април 2021 г. са гласували 50,61% от избирателите, три години по-късно активността се е сринала до 34,41%. 

Спектакълът на ГЕРБ

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

Отново пуснаха в ход преговорен екип, който не постигна особени резултати, но излъчи имиджови сигнали за „добра воля“. При връчването на мандата ГЕРБ се яви със състав на бъдещо правителство, без да даде възможност за разговори по номинациите с останалите политически сили. В състава на проектоправителството бяха ярки политически лица, някои вече управлявали в кабинети на ГЕРБ, въпреки че в по-ранни изявления БСП, ИТН, „Възраждане“ и „Величие“ обявиха, че биха подкрепили правителство от експерти. Освен от ГЕРБ, в проектокабинета присъстваха и министри от последните две правителства – служебно и редовно. 

С този ход Бойко Борисов успя да се измъкне от пакетирането с ДПС и със санкционирания за корупция от САЩ и Великобритания Делян Пеевски, което щеше да е в ущърб на ГЕРБ – и имиджово, и при споделянето на властта. 

Самият Борисов на няколко пъти обясни публично, че само с ДПС няма да прави кабинет. Така парира и атаки за зависимости от страна на доскорошните партньори в „сглобката“ ПП–ДБ, които превърнаха съдружието Пеевски–Борисов в централна тема на опозиционния си наратив. Имаха своето основание – ГЕРБ развали т.нар. сглобка след меморандума на ПП–ДБ, в който имаше предложение за подялба на регулаторите 50:50, изключващо ДПС.  

Фразата на Борисов, че кабинетът може и да мине с някой „трик“, насочи подозренията към най-малката парламентарна група – на „Величие“, и към възможното ѝ разцепване предвид скандалите между двете лица на партията Николай Марков и Ивелин Михайлов. Но в деня на гласуването групата се показа единна, най-вероятно проумели, че никой не търси подкрепата им. А ГЕРБ едва ли са петимни за съдействие от партия с бутафорен изглед и неясна идеология, чиято единствената сигурна характеристика е, че е националистическа и популистка. Лидерът на ГЕРБ е бил в такива съюзи в години, когато партньори „патриоти“ с прокремълски уклон все още можеха да бъдат преглътнати. Вече не.  

За Борисов изходът беше предопределен още преди гласуването, отхвърлило предложеното от ГЕРБ правителство.

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

ДПС се пропуква

Трусовете в ДПС обаче не са факторът, който попречи на кабинета на Росен Желязков да бъде приет. Дори и групата на ДПС да беше единна, заедно с ГЕРБ не стигаха мнозинство от 121 гласа. Пропукването в една от най-монолитните партии на статуквото обаче е симптом за тектонични сблъсъци под повърхността. Безпрецедентно по рода си, тъй като за първи път е сериозно застрашено единството на ДПС. 

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

Никой досега не го е правил така агресивно, въпреки че през годините мнозина са се опълчвали на човека, наричан от своите Сокола, или просто са губили доверието му – Яшар Шабан, Гюнер Тахир, Осман Октай, Касим Дал, Лютви Местан, Корман Исмаилов, Мустафа Карадайъ… Всички те, по един или друг начин, са били изхвърляни от ДПС, но това не застраши целокупността на партията и нейното единоначалие. Само създадената от Местан партия ДОСТ успя да спечели 100 479 гласа на изборите през март 2017 г., но не мина прага от 4%, за да влезе в парламента. 

В предаването „Денят с Веселин Дремджиев“ наскоро Гюнер Тахир съобщи, че именно Пеевски, по онова време депутат в 43-тото НС, е разпоредил да бъде свалена охраната на Местан след показното му отстраняване като лидер на ДПС заради пронатовски позиции. (А днес Пеевски е вече евроатлантик, който се гневи, че подаряваме България на Путин, след като не е избрано евроатлантическото правителство.)

Тахир заяви още, че по неофициална информация сега е била свалена и охраната на Доган. Новината мина и замина, но в контекста на развилите се събития може да бъде разгледана и като опит за сплашване на почетния председател, изолирал се от активната политика, а от известно време и със сериозни финансови затруднения заради признатия от съда дълг от над 37 млн. лв. на ТЕЦ „Варна“ към „Булгаргаз“. 

Пеевски стартира акция за подмяна на ръководни кадри на ДПС по места и в парламентарната група. Действията му са опаковани като „ново начало“ и са под егидата на евроатлантизма – без да се церемони, така както е действал в медиите си и при различни поръчки. Консолидира около себе си кметовете на ДПС от помашките райони и някои местни структури. Междувременно овладеният от него пресцентър започна да го представя като председател на ДПС и лидер, въпреки че и той, и Джевдет Чакъров са съпредседатели на партията. Първите, на които посегна в ДПС, бяха знакови лица – Филиз Хюсменова, Рамадан Аталай, споменатата Биршен Ибрямова, Айсел Руфад, вече бивша зам.-председателка на парламентарната група на ДПС.  

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

Аз ще изпълня волята на хората. Хората в цялата страна съм ги видял – искат правителство. България трябва да има правителство. Ние трябва да се грижим за хората. Аз като лидер на ДПС съм отговорен само пред хората на ДПС. Това е спазване на устава на ДПС. ДПС се управлява от своя председател.

През това време във Facebook групата „Аз подкрепям Ахмед Доган“ се появиха писма от двете най-големи структури на ДПС – организациите в Кърджали и Разград, заедно с други, които призовават Доган да излезе с изявление за случващото се. Но той мълчи, а ръководните органи на партията са като парализирани – и Централното оперативно бюро, част от което са някои от изключените, и Централният съвет.

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

Съпредседателят Чакъров, мълчал досега, вече публично призна, че има напрежение – блокирани са колективните органи на партията – но се надява разумът да надделее. И двата враждуващи лагера си дават сметка, че едно отслабено ДПС не е от полза за никого. Въпросът е как ще се справят с разкола – чрез мирно споразумение за ненападение, което не изглежда възможно, или чрез валяка на грубата сила и подчинение, каквито са методите на Пеевски. Резултатът ще се чете по резултатите на ДПС през октомври.

ПП–ДБ нямат време

Предстоящото разпускане на парламента и нови избори наесен не са от полза на ПП–ДБ, които са опозиция в 50-тото НС. Това им поведение се нуждае от време, за да бъде утвърдено пред избирателите, в т.ч. и пред изгубените 300 хиляди, огорчени и фрустрирани от съюза с ГЕРБ и ДПС. Оставката на лидера на „Да, България“ и съпредседател на ДБ Христо Иванов, поел отговорност за изборните резултати, е предизвикателство за реорганизация на коалицията и обновление на лидерството, но е и загуба за обединението, което още търси общ бранд и платформа за съвместно бъдеще. Иванов заяви:

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

В ситуация на предстоящи избори и неяснота как ще бъде надградена коалицията ПП–ДБ, съчетаваща либерали и десни, бързият избор на нов лидер на „Да, България“ е належащ. Насрочено заседание за целта все още няма. Мястото на Христо Иванов в парламента, редом до другите лидери от ПП–ДБ – Атанас Атанасов, Кирил Петков и Николай Денков, зае депутатът Божидар Божанов, бивш министър на електронното управление, събрал най-много преференции на вота на 9 юни (7496). От „Продължаваме промяната“ не обявиха оставки.

По време на дебатите в пленарната зала по повод проектокабинета на ГЕРБ най-острите пререкания бяха  между ПП и депутати от партията на Борисов, без да бъде намесвано ДПС. Съпредседателят на ПП Кирил Петков се обърна към избирателите с извинение, че още в първия месец (от управлението на кабинета „Денков“) не са поставили  като приоритет реформите в службите и в правосъдната система.

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

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

Предстоящите избори няма да повлияят съществено на останалите партии. В зависимост от това кога ще бъдат насрочени, БСП може да е с нов лидер, а може все още да е с временно изпълняващия функциите Атанас Зафиров, избран след оставката на Корнелия Нинова. Според хронограмата, предложена от Изпълнителното бюро, до 10 ноември трябва да се проведе пряк избор на председател. Но това едва ли ще е спирачка за нов спад – социалистите спечелиха едва 151 560 гласа на последните избори. 

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

Достатъчно гъвкав и реактивен, лидерът на „Възраждане“ бързо смени тона и вместо напористия и нападателен Костадинов, вече отправя едни значително по-балансирани послания. На фона на междуличностните нападки и напрежение между останалите политически сили те изглеждат някак по-разумно и подсказват, че „Възраждане“ се подготвя да бъде ухажвана за партньор във властта. Въпреки че опцията за пореден сурогат от типа на „Величие“ не е изключена, партията на Костадинов може да върне част от избирателите си, които подкрепиха „Величие“, и да се амбицира да стане втора политическа сила. 

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

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

Възходът на крайнодесните и популистите не подминава България. Големият въпрос е как и колко ще ѝ навреди и къде са здравите сили, които могат да противостоят.

Пет отровни дела. Знаете ли какво е да стреляш по човек?

Post Syndicated from original https://www.toest.bg/pet-otrovni-dela-znaete-li-kakvo-e-da-streliash-po-chovek/

Не искам да убивам хора,

Пет отровни дела. Знаете ли какво е да стреляш по човек?

ми каза Александър Стоцки, когато се видяхме за първи път през 2022 г. в София. От началото на войната на Русия срещу Украйна хиляди украински бежанци напуснаха страната си. Но Стоцки не е украинец. Руснак е.

 Това е земя на простичко щастие. 

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

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

България не е религиозна страна, тъй като е комунистическа държава.

По това време, през 1965 г., Стоцки не е бил роден, вероятно и бъдещите му родители – също. Днес те живеят в Москва, столицата на Русия, а той – в София, столицата на България.

От създаването на рекламата за „простичкото щастие“ минават петдесет години и през 1989-та страната ни се откъсва от сателитната си орбита около СССР. Годината е 2015-та, когато България създава нов слоган в опит да рекламира себе си:

Скрито пред очите ти.

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

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

На какво обаче се дължи спадът на руски и украински туристи, и дума не става в речта на министърката от ГЕРБ. 

Година преди Ангелкова да оповести отлива на руски и украински туристи от страната ни, на 18 март 2014 г. Русия анексира украинския полустров Крим. Европейският съюз не признава незаконното анексиране на Крим и Севастопол от Руската федерация и инициира редица санкции за Русия. В България – членка на Съюза, лидерът на управляващата партия ГЕРБ Бойко Борисов казва, че партията му подкрепя ЕС и НАТО за ситуацията в Украйна, но според него санкциите срещу Русия са в ущърб на интересите на България и не трябва да ги има. По думите му, е по-добре страната да бъде посредник за приключването на кризата.

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

През същата 2015-та Александър Стоцки е на 19 и е част от протестиращите в Москва срещу анексията на Крим. Освен това за него е време да отслужи задължителната редовна военна служба там. Излиза от казармата с чин ефрейтор в сапьорски войски.

Пет отровни дела. Знаете ли какво е да стреляш по човек?
Пет отровни дела. Знаете ли какво е да стреляш по човек?

© Личен архив

На 24 февруари 2022 г. Русия нахлува в Украйна. Към България бягат хиляди украински жени с децата си, ужасени от ракетните обстрели над градовете им и смъртта, която сеят руските бомби и войници там. Заедно с тях към България побягват – но от другата страна на фронта – и руснаци. Един от тях е Александър Стоцки:

В края на 2021-ва и началото на 2022-ра, когато започна струпването на руски войски по границата с Украйна, в рамките на два месеца получих три призовки от армията да се явя в едно поделение. И на трите призовки пишеше, че е повиквателна за запас. Не се явих. На 23 срещу 24 февруари през нощта вече беше ясно, че започва война. Цяла нощ не спах, защото разбирах, че не ме викат запас – това беше предлог да ме изпратят на фронта. Знаех, че ако се явя запас, те ще ме принудят да подпиша всякакви документи, за да ме изпратят на фронта уж като доброволец. Отбивайки военната си служба, бях сапьор – едно от най-търсените умения при война. За щастие, имах туристическа виза за България. Хванах първия самолет на сутринта, защото вече знаех какво се случва – пълномащабна война.

На 25 февруари 2022 г. Александър Стоцки каца в България. В същото време президентът на „земята на простичкото щастие“ и държавата, в която всичко е „скрито пред очите ти“ Румен Радев казва: „Русия ще спечели тази война, но тя много трудно ще спечели мира.“ Премиерът Кирил Петков пък заявява, че войната ще свърши за три дни, защото украинската армия е почти унищожена.

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

Процесите

Софийски административен съд, административно дело № 7376
Публичното заседание е на 14.11.2022 г.

Пред Държавната агенция за бежанците (ДАБ) и Софийския административен съд аргументите на Александър да поиска убежище в България са доста. В Русия, а и след идването му в България е участвал в много митинги срещу режима на Владимир Путин. Бил е част от щаба на руските опозиционни политици като наблюдател на изборите за руската „Дума“, бил е и част от платформата „Умно гласуване“ на Алексей Навални (поддръжниците на „Умно гласуване“ са считани от руските власти за екстремисти и всеки от тях е под опасност от затвор – б.а.). След пристигането си в България е назовавал многократно и публично войната в Украйна „война“, а не „специална операция“, а също ака се е обявявал против нахлуването на руските войски в Украйна, за което в Русия санкцията е затвор.

Други притеснения на Александър са, че след като е получил три призовки за явяване в армията като ефрейтор от сапьорски войски и не се е явил, ако се завърне в Русия, със сигурност ще бъде обявен за дезертьор и ще бъде изпратен в затвор. Александър прилага копие от последната си призовка. Към този момент призовките за запас все още са хартиени. По-късно, след официалната мобилизация в Русия, се създава електронен регистър и призовките се получават по електронен път.

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

Освен това, по останалите аргументи на Стоцки, Съдът се произнася така: „Настоящият състав на Административен съд, София – град, като споделя крайните изводи за липса на основания да бъде предоставена международна закрила приема, че оспорваното Решение No 10938/19.07.2022 г. на заместник – председателя на ДАБ е правилно. Статут на бежанец в Република България се предоставя на чужденец, който основателно се страхува от преследване, поради своята раса, религия, националност, принадлежност към определена социална група или поради политическо мнение и/или убеждение, намира се извън държавата си по произход и поради тези причини не може или не желае да се ползва от закрилата на тази държава или да се завърне в нея – чл. 8, ал. 1 ЗУБ. Правилен е изводът на административния орган, че изложените от лицето причини не представляват материалноправно основание, по смисъла на чл. 8, ал. 1 ЗУБ за предоставяне на статут на бежанец. Като недоказани Съдът преценява твърденията за: участие в няколко протеста против властта; опасения, че може да бъде въдворен в затвора за политическата си дейност и моралните си принципи.

(Цитатът е със съкращения и запазен правопис.)

Според Държавната Агенция за бежанците: „От описаните по-горе твърдения на чужденеца, Агенцията приема, че молбата за закрила е неоснователна, тъй като молителят не обосновава необходимостта от предоставяне на такава и не посочва причини за основателни опасения от преследване в държавата си на произход. Вероятността да е бил призован за мобилизация за предстоящата „военна операция" в Украйна е несъществена. Няма твърдения, от които да се направи обоснован извод, че чуждият гражданин може да бъде изложен на реална опасност от тежки посегателства като смъртно наказание, изтезание, нечовешко или унизително отнасяне или наказание от официалните власти или някоя конкретна групировка, която държавата не е в състояние да контролира.

(Цитатът е със съкращения и запазен правопис)

Пет отровни дела. Знаете ли какво е да стреляш по човек?
Пет отровни дела. Знаете ли какво е да стреляш по човек?

© Личен архив

Докато Александър се чуди как би могъл да докаже на българските съдилища участието си в антивоенни протести и в протести против управлението на Владимир Путин, у нас тъкмо са приключили поредните предсрочни парламентарни избори. Преди тях в страната на „простичкото щастие“ управлява служебен кабинет на президента Румен Радев, който за пореден път на среща на върха отказва България да предостави военна помощ за Украйна.

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

(от 23.09.2022 г.)

На 14 ноември 2022 г. Административен съд София-град отхвърля жалбата на Александър: „На чужденеца е отказано предоставяне на международна закрила – статут на бежанец и хуманитарен статут.“

Александър е изумен как българските власти тълкуват аргументите му:

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

На 16.12.2022 г. новосформирания български парламент все пак гласува България да даде военна помощ на Украйна. На 23.12.2022 г. Румен Радев изрича паметната фраза „Войнолюбците в Народното събрание взеха решение за военна помощ за Украйна“*.

Четиринайсет дни след решението на Софийския административен съд Александър Стоцки и адвокатът му обжалват пред Върховния административен съд. Към аргументите за искане на закрила и убежище от първото дело досега има една съществена новост. Майката на Александър Стоцки е получила на домашния им адрес в Москва нова призовка, този път за мобилизация на нейния син. Освен на хартиен носител в Русия вече има създаден електронен регистър, като условието властите да са изпратили призовката, без значение дали получателят я е видял, е достатъчно той да се води призован и да подлежи на строги наказания, включително затвор, ако не се отзове веднага в посочения му пункт за мобилизация.

Върховен административен съд, административно дело №1356

Публичното заседание е на 11 април 2023 г.

Влизаме в съдебната зала. Адвокатът представя доказателствата пред съда. Александър казва:

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

В съдебната зала сме десетина човека – адвокатът, прокурорът, представителката на ДАБ, преводачката и няколко познати на Александър. Започва речта на представителката на Агенцията за бежанците, която настоява Върховният съд да отхвърли жалбата на Александър като неоснователна със следния мотив:

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

(Цитатът е от стенограма на Върховния административен съд, оригиналният правопис е запазен)

След като излязохме от съда Александър неразбиращо ме попита:

Как тази жена (представителката на ДАБ) си представя, че първо, в Русия някой може да откаже да отслужи редовната си военна служба. Това е невъзможно, освен ако не представиш религиозни съображения, но такива случаи са много редки. Е, става и с торба пари, но аз ги нямам. Освен това преди войната на Путин в Украйна, аз бях гражданин на Руската федерация, и като всеки гражданин съм изпълнил дълга си по закон – да отслужа военната си служба. Всеки обаче трябва да си дава сметка, че редовна служба в мирно време и това да убиваш хора на фронта са несравними. Нещо, което никога няма да направя, каквото и да ми коства. Тя представя ли си какво е да стреляш срещу човек?

По време на делото представителката на ДАБ продължи да настоява, че Александър трябва да бъде върнат в Русия, защото според нея участието му в политически митинги

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

(Цитатът е от стенограма на ВАС, оригиналният правопис е запазен)

След края на делото Александър ми каза:

В Москва на всеки ъгъл има камери с лицево разпознаване и всеки, който е говорил против войната или Путин, може много лесно да бъде заловен и откаран в затвора.

Усетих в гласа на Александър тъга и ирония, и страх. Той направи пауза и продължи:

За голямо съжаление, това е свързано с моя живот. Откакто съм в България съм протестирал пред Руското посолство и Руския културен център и срещу войната в Украйна, и в подкрепа на Навални. Такива руснаци в моята родина са обявени за врагове и ги пращат директно в затвора, но тази жена не вярва, че това е възможно, или не иска да повярва. Да не говорим, че имам официална призовка да се явя в армията, сега вероятно вече и електронна. Аз съм ужасен от перспективата да ме депортират в Русия. Това означава затвор или да ме пратят на фронта, където също ще умра, защото не мога и не искам да убивам. Вярвам, че България е наистина европейска държава с истински независим съд.

В земята на „простичко щастие“ България президентът Радев промени наратива за войната  на Русия срещу Украйна:

Украйна настоява да продължи да води тази война, но сметката се плаща от цяла Европа.

Премиерът Николай Денков отговори:

Руската федерация е най-съществената и директна заплаха за сигурността на държавите членки на Северноатлантическия пакт, а също така и на мира и стабилността в евроатлантическата област. Моят въпрос е кога нашият президент е имал свое мнение – когато е подписал тези цитати или когато днес повтаря едни руски опорки, които нямат нищо общо с това, което представят членовете на ЕС и НАТО като позиция[7]

Пет отровни дела. Знаете ли какво е да стреляш по човек?
© Личен архив

През септември 2023 г. Александър Стоцки получи статут на бежанец в България. Към днешна дата работи и е доброволец в център за подпомагане на украински бежанци.

„Тоест“ изпрати въпроси, свързани с работата на ДАБ по делата с руски бежанци в България след началото на войната на Русия срещу Украйна. До приключване на редакционната работа на този текст нямаме отговор от тях.

* Румен Радев използва „войнолюбци“ в официално изказване два пъти – в обръщението си към новоизбраните народни представители от 48-мото Народно събрание на 19.10.2022 г. и в изявление на 23.12.2022 г. Изказванията на Румен Радев са взети от официалната страница на президента.

Zabbix Audit Log: Underlying Design and Considerations

Post Syndicated from Artjoms Rimdjonoks original https://blog.zabbix.com/zabbix-audit-log-underlying-design-and-considerations/28328/

An audit improves the security of a product, specifically the “non-repudiation” aspect in threat-models (risks are reduced when threat-agents cannot deny they did malicious activity). Zabbix 5.0 already had audit functionality, which received a major rewrite in 6.0 and several updates since then. In this blog post, we will go through them and get an overall picture of what has changed (and why).

The server side work on 6.0 was mostly done and further improved in 7.0. Front-end work is still ongoing (due to a larger scope). The main goal of a Zabbix audit is to track all configuration and settings changes – who, when, and what. This is an enterprise-level requirement, but non-enterprise users can also benefit.

The situation before Zabbix 6.0

When a host or template is added, only its name is recorded, without info about items, triggers, tags, etc. The linking of the template on the host is not audited. Everything on the screen is an audit done by the front-end, except the script execution. Zabbix Server itself actually does a lot of configuration changes, including adding and updating hosts and updating items (during LLD or when linking templates during auto-registration or network discovery), but there is no audit for that at all. There are also non-configuration changes (events) we want to audit, including:

  • Script execution (already audited in 5.0):

  • Reloading passive proxy config data (ZBXNEXT-1580), added in 6.2:

  • HA node status change (ZBXNEXT-6923), added in 6.0, history push API requests, and sending data to Zabbix server via API (ZBXNEXT-8541), added in 7.0:

Audit overview

Most Zabbix server audit logic is in:

a) Linking of templates (as a result of auto-registration or network discovery) with updates to:

  • Hosts
  • Items
  • Triggers
  • Graphs
  • Discovery Rules (and prototypes of everything above)
  • Web Scenarios

b) LLD, with the following entities created from prototypes:

  • Hosts
  • Items
  • Triggers
  • Graphs

New audit goals

In addition to the main functional requirement to “track all configuration and settings changes,” there are additional requirements aimed at making all audits faster and easier to manage:

  • All audits are now stored in a single table (Simpler and faster SQL queries)
  • Bulk SQL inserts and efficient ids generation
  • The audit of a particular entity stays longer than this entity. If an entity – (host or user) is deleted – the audit for it stays
  • The audit has an independent housekeeping schedule
  • It is still possible to disable the audit

CUID

Zabbix uses an ids table to generate ids:

When something (items, triggers etc.) needs to be generated, the related row in the ids table gets locked. This represents a problem for generating audit rows, because an audit can be generated independently by the server and front-end:

So, we could end up in a situation where a user cannot create an item because the server is holding a lock on the ids table while generating thousands of new LLD items. That is why a new method for generating ID was used for audits:

Thanks to it, the front-end and server can independently generate ids for audit entries without locks. The chance of collision is astronomically low.

System user

When it is not clear under which user an audit entry needs to be generated, it is recorded under “System user.” Most of the audits done by Server are done under “System user.” One exception is “script execution,”” since it is clear which user clicked on the script execution button. However, under which user should the server record audit entries when new items are generated during LLD? We could track down which user created the LLD rule, but what if the LLD rule was then modified by another user? For such cases, “System user” is used.

RecordSetID

From the spec: “To have the ability to recognize that some set of audit log records was created during the processing of a separate operation, a new column “Recordset ID” for audit log records will be provided. Each audit log record of the separate operation will have the same recordset ID. The recordset ID will be generated using the CUID algorithm.”

We can see that 2 graphs were created in a single operation (e.g. during the linking of one template with 2 graphs).

Audit details

A new audit contains much more information on what was changed with new details:

Upgrade patch

The warning, old auditlog, and auditlog_details tables are removed during the upgrade patch to 6.0. A new auditlog table is created, and the schema is updated.

  • auditid is now CUID
  • userid can be NULL (no more foreign reference on users table)
  • username is added
  • resource_cuid is added(alternative to resource, only for HA)
  • recordsetid is added
  • note and other auditlog_details table data now is in details (JSON)

BulkSQL

It is much more efficient to execute SQL queries in bulk. Zabbix already relies on bulk SQL queries:

Inserting and/or updating thousands of new items in one query is much faster than running thousands of individual queries. There are many reasons why this is the case, but the most basic answer is that DBs are designed this way. Another reason is that a large single query in PostgreSQL needs to start the planner/optimizer once, and then it would be able to properly analyze this large query and create an efficient execution plan.

When running thousands of separate queries, the planner/optimizer needs to be started for each query, and every time it would analyze the small query and decide there is not much it can do. When a server is doing some configuration changes, like LLD or templates linking during auto-registration or network discovery, it will insert/update/delete items/triggers and also auditlog entries in one large query.

Performance impact

Quick performance tests showed that the audit slows the server at most by 4-5%. The larger the setup, the smaller the impact will be.

Storage impact and administration

Zabbix audits can generate a lot of data. If your setup generates a lot of configuration, audits can eventually overrun the storage space. In this case, there are several audit configurations that could be helpful.

First of all, an audit can be disabled for all Zabbix, including the front-end:

Disabling audit is not advised, however – this option exists mostly as a possible workaround. Audit is enabled by default and Zabbix is developed and tested with audit enabled.

Log system actions button:

A disabled audit done by Zabbix server during auto-registration, network discover, and LLD. On some systems, these can generate a lot of configurations and audits, for example when LLD discovers hundreds of new devices every minute.

This could help reduce the storage impact while preserving all other audit functionality.

Housekeeping schedule:

If a host, trigger, or graph is deleted (by housekeeper or manually), the audit generated for it stays (as it exists in a separate table).

A Zabbix audit has its own independent housekeeping schedule, and it can be adjusted to suit your environment.

The post Zabbix Audit Log: Underlying Design and Considerations appeared first on Zabbix Blog.

Refactoring to Serverless: From Application to Automation

Post Syndicated from Sindhu Pillai original https://aws.amazon.com/blogs/devops/refactoring-to-serverless-from-application-to-automation/

Serverless technologies not only minimize the time that builders spend managing infrastructure, they also help builders reduce the amount of application code they need to write. Replacing application code with fully managed cloud services improves both the operational characteristics and the maintainability of your applications thanks to a cleaner separation between business logic and application topology. This blog post shows you how.

Serverless isn’t a runtime; it’s an architecture

Since the launch of AWS Lambda in 2014, serverless has evolved to be more than just a cloud runtime. The ability to easily deploy and scale individual functions, coupled with per-millisecond billing, has led to the evolution of modern application architectures from monoliths towards loosely-coupled applications. Functions typically communicate through events, an interaction model that’s supported by a combination of serverless integration services, such as Amazon EventBridge and Amazon SNS, and Lambda’s asynchronous invocation model.

Modern distributed architectures with independent runtime elements (like Lambda functions or containers) have a distinct topology graph that represents which elements talk to others. In the diagram below, Amazon API Gateway, Lambda, EventBridge, and Amazon SQS interact to process an order in a typical Order Processing System. The topology has a major influence on the application’s runtime characteristics like latency, throughput, or resilience.

Serverless topology for an Order processing using AWS services

The role of cloud automation evolves

Cloud automation languages, commonly referred to as IaC (Infrastructure as Code), date back to 2011 with the launch of CloudFormation, which allowed users to declare a set of cloud resources in configuration files instead of issuing a series of API calls or CLI commands. Initial document-oriented automation languages like AWS CloudFormation and Terraform were soon complemented by frameworks like AWS Cloud Development Kit (CDK), CDK for Terraform, and Pulumi that introduced the ability to write cloud automation code in popular general-purpose languages like TypeScript, Python, or Java.

The role of cloud automation evolved alongside serverless application architectures. Because serverless technologies free builders from having to manage infrastructure, there really isn’t any “I” in serverless IaC anymore. Instead, serverless cloud automation primarily defines the application’s topology by connecting Lambda functions with event sources or targets, which can be other Lambda functions. This approach more closely resembles “AaC” – Architecture as Code – as the automation now defines the application’s architecture instead of provisioning infrastructure elements.

Improving serverless applications with automation code

By utilizing AWS serverless runtime features, automation code can frequently achieve the same functionality as your application code.

For example, the Lambda function below, written in TypeScript, sends a message to EventBridge:

export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => { 
    const result = // some logic
    const eventParam = new PutEventsCommand({
        Entries: [
            {
              Detail: JSON.stringify(result),
              DetailType: 'OrderCreated',
              EventBusName: process.env.EVENTBUS_NAME,
            }
          ]
    });
    await eventBridgeClient.send(eventParam);     return {
       statusCode: 200,
       body: JSON.stringify({ message: 'Order created', result }),
    };
};

You can achieve the same behavior using AWS Lambda Destinations, which instructs the Lambda runtime to publish an event after the completion of the function. You can configure Lambda destinations via below AWS CDK code, also written in TypeScript:

import {EventBridgeDestination} from "aws-cdk-lib/aws-lambda-destinations"

const createOrderLambda = new Function(this,'createOrderLambda', {
    functionName: `OrderService`,
    runtime: Runtime.NODEJS_20_X,
    code: Code.fromAsset('lambda-fns/send-message-using-destination'),
    handler: 'OrderService.handler',
 onSuccess: new EventBridgeDestination(eventBus)
});

With the AWS CDK, you can use the same programming languages for both application and automation code, allowing you to switch easily between the two.

The Lambda function can now focus on the business logic and doesn’t contain any reference to message sending or EventBridge. This separation of concerns is a best practice because changes to the business logic do not run the risk of breaking the architecture and vice versa.

export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
    const result = //some logic
    return {
        statusCode: 200,
        body: JSON.stringify({ message: 'Order created', result }),
     };
};

Instructing the serverless Lambda runtime to send the event has several advantages over hand-coding it inside the application code

  • It decouples application logic from topology. The message destination, consisting of the type of the service (e.g., EventBridge vs. another Lambda Function) and the destination’s ARN, define the application’s architecture (or topology). Embedding message sending in the application code mixes architecture with business logic. Handling the sending of the message in the runtime separates concerns and avoids having to touch the application code for a topology change.
  • It makes the composition explicit. If application code sends a message, it will likely read the destination from an environment variable, which is passed to the Lambda function. The name of the variable that is used for this purpose is buried in the application code, forcing you to rely on naming conventions. Defining all dependencies between service instances in automation code keeps them in a central location, and allows you to use code analysis and refactoring tools to reason about your architecture or make changes to it.
  • It avoids simple mistakes. Redundant code can lead to mistakes. For example, debugging a Lambda function that accidentally swapped day and month in the message’s date field took hours. Letting the runtime send messages avoids such errors.
  • Higher-level constructs simplify permission grants. Cloud automation libraries like CDK allow the creation of higher-level constructs, which can combine multiple resources and include necessary IAM permissions. You’ll write less code and avoid debugging cycles.
  • The runtime is more robust. Delegating message sending to the serverless runtime takes care of any required retries, ensuring the message to be sent and freeing builders from having to write extra code for such undifferentiated heavy lifting.

In summary, letting the managed service handle message passing makes your serverless application cleaner and more robust. We also like to say that it becomes “serverless-native” because it fully utilizes the native services available to the application.

Refactoring to serverless-native

Shifting code from application to automation is what we call “Refactoring to Serverless”. Refactoring is a term popularized by Martin Fowler in the late 90s to describe the restructuring of source code to alter its structure without changing its external behavior. Code refactoring can be as simple as extracting code into a separate method or more sophisticated like replacing conditional expressions with polymorphism.

Developers refactor their code to improve its readability and maintainability. A common approach in Test-Driven Development (TDD) is the so-called red-green-refactor cycle: write a test, which will be red because the functionality isn’t implemented, then write the code to make the test green, and finally refactor to counteract the growing entropy in the codebase.

Serverless refactoring takes inspiration from this concept but augments it to the context of serverless automation:

Serverless refactoring: A controlled technique for improving the design of serverless applications by replacing application code with equivalent automation code.

Let’s explore how serverless refactoring can enhance the design and runtime characteristics of a serverless application. The diagram below shows an AWS Step Functions workflow that performs a quality check through image recognition. An early implementation, shown on the left, would use an intermediate AWS Lambda function to call the Amazon Rekognition service. Thanks to the launch of Step Functions’ AWS SDK service integrations in 2021, you can refactor the workflow to directly call the Rekognition API. This refactored design, seen on the right, eliminates the Lambda function (assuming it didn’t perform any additional tasks), thereby reducing costs and runtime complexity.

Replacing Lambda with Service Integration in Step Function workflow

See the AWS CDK implementation for this refactoring, in TypeScript, on GitHub.

Refactoring Limitations

The initial example of replacing application code to send a message to SQS via Lambda Destinations reveals that refactoring from application to automation code isn’t 100% behavior-preserving.

First, Lambda Destinations are only triggered when the function is invoked asynchronously. For synchronous invocations, the function passes the results back to the caller, and does not invoke the destination. Second, the serverless runtime wraps the data returned from the function inside a message envelope, affecting how the message recipient parses the JSON object. The message data is placed inside the responsePayload field if sending to another Lambda function or the detail field if sending to an EventBridge destination. Last, Lambda Destinations sends a message after the function completes, whereas application code could send the message at any point during the execution.

Lambda Destination Execution

The last change in behavior will be transparent to well-architected asynchronous applications because they won’t depend on the timing of message delivery. If a Lambda function continues processing after sending a message (for example, to EventBridge), that code can’t assume that the message has been processed because delivery is asynchronous. A rare exception could be a loop waiting for the results from the downstream message processing, but such loops violate the principles of asynchronous integration and also waste compute resources (Amazon Step Functions is a great choice for asynchronous callbacks). If such behavior is required, it can be achieved by splitting the Lambda function into two parts.

Can Serverless Refactoring be Automated?

Traditional code refactoring like “Extract Method” is automated thanks to built-in support by many code editors. Serverless refactoring isn’t (yet) a fully automatic, 100%-equivalent code transformation because it translates application code into automation code (or vice versa). While AI-powered tools like Amazon Q Developer are getting us closer to that vision, we consider serverless refactoring primarily as a design technique for developers to better utilize the AWS runtime. Improved code design and runtime characteristics outweigh behavior differences, especially if your application includes automated tests.

Incorporating refactoring into your team structures

If a single team owns both the application and the automation code, refactoring takes place inside the team. However, serverless refactoring can cross team boundaries when separate teams develop business logic versus managing the underlying infrastructure, configuration, and deployment.

In such a model, AWS recommends that the development team be responsible for both the application code and the application-specific automation, such as the CDK code to configure Lambda Destinations, Step Functions workflows, or EventBridge routing. Splitting application and application-specific automation across teams would make the development team dependent on the platform team for each refactoring and introduce unnecessary friction.

If both teams use the same Infrastructure-as-Code (IaC) tool, say AWS CDK, the platform team can build reusable templates and constructs that encapsulate organizational requirements and guardrails, such as CDK constructs for S3 buckets with encryption enabled. Development teams can easily consume those resources across CDK stacks.

However, teams could use different IaC tools, for example, the infrastructure team prefers CloudFormation but the development team prefers AWS CDK. In this setup, development teams can build their automation on top of the CFN Modules provided by the infrastructure team. However, they won’t benefit from the same high-level programming abstractions as they do with CDK.

Collaboration in a split-team model

Continuous Refactoring

Just like traditional code refactoring, refactoring to serverless isn’t a one-time activity but an essential aspect of your software delivery. Because adding functionality increases your application’s complexity, regular refactoring can help keep complexity at bay and maintain your development velocity. Like with Continuous Delivery, you can improve your software delivery with Continuous Refactoring.

Teams who encounter difficulties with serverless refactoring might be lacking automated test coverage or cloud automation. So, refactoring can become a useful forcing function for teams to exercise software delivery hygiene, for example by implementing automated tests.

Getting Started

The refactoring samples discussed here are a subset of an extensive catalog of open source code examples, which you can find along with AWS CDK implementation examples at refactoringserverless.com. You can also dive deeper into how serverless refactoring can make your application architecture more loosely coupled in a separate blog post.

Use the examples to accelerate your own refactoring effort. Now Go Refactor!

Announcing initial services available in the AWS European Sovereign Cloud, backed by the full power of AWS

Post Syndicated from Max Peterson original https://aws.amazon.com/blogs/security/announcing-initial-services-available-in-the-aws-european-sovereign-cloud-backed-by-the-full-power-of-aws/

English | French | German | Italian | Spanish

Last month, we shared that we are investing €7.8 billion in the AWS European Sovereign Cloud, a new independent cloud for Europe, which is set to launch by the end of 2025. We are building the AWS European Sovereign Cloud designed to offer public sector organizations and customers in highly regulated industries further choice to help them meet their unique digital sovereignty requirements, as well as stringent data residency, operational autonomy, and resiliency requirements. Customers and partners using the AWS European Sovereign Cloud will benefit from the full capacity of AWS including the same familiar architecture, service portfolio, APIs, and security features available in our 33 existing AWS Regions. Today, we are thrilled to reveal an initial roadmap of services that will be available in the AWS European Sovereign Cloud. This announcement highlights the breadth and depth of the AWS European Sovereign Cloud service portfolio, designed to meet customer and partner demand while delivering on our commitment to offer the most advanced set of sovereignty controls and features available in the cloud.

The AWS European Sovereign Cloud is architected to be sovereign-by-design, just as the AWS Cloud has been since day one. We have designed a secure and highly available global infrastructure, built safeguards into our service design and deployment mechanisms, and instilled resilience into our operational culture. Our customers benefit from a cloud built to help them satisfy the requirements of the most security-sensitive organizations. Each Region is comprised of multiple Availability Zones and each Availability Zone is made up of one or more discrete data centers, each with redundant power, connectivity, and networking. The first Region of the AWS European Sovereign Cloud will be located in the State of Brandenburg, Germany, with infrastructure wholly located within the European Union (EU). Like our existing Regions, the AWS European Sovereign Cloud will be powered by the AWS Nitro System. The Nitro System powers all our modern Amazon Elastic Compute Cloud (Amazon EC2) instances and provides a strong physical and logical security boundary to enforce access restrictions so that nobody, including AWS employees, can access customer data running in Amazon EC2.

Service roadmap for the AWS European Sovereign Cloud

When launching a new Region, we start with the core services needed to support critical workloads and applications and then continue to expand our service catalog based on customer and partner demand. The AWS European Sovereign Cloud will initially feature services from a range of categories, including for artificial intelligence – Amazon SageMaker, Amazon Q, and Amazon Bedrock, compute – Amazon EC2 and AWS Lambda, containers – Amazon Elastic Kubernetes Service (Amazon EKS) and Amazon Elastic Container Service (Amazon ECS), database – Amazon Aurora, Amazon DynamoDB, and Amazon Relational Database Service (Amazon RDS), networking – Amazon Virtual Private Cloud (Amazon VPC), security – AWS Key Management Service (AWS KMS) and AWS Private Certificate Authority, and storage – Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Block Store (Amazon EBS). The AWS European Sovereign Cloud will feature its own dedicated identity and access management (IAM), billing, and usage metering systems that are operated independently from existing Regions. These systems will allow customers using the AWS European Sovereign Cloud to keep all customer data, as well as all the metadata they create (such as the roles, permissions, resource labels, and configurations they use to run AWS) in the EU. Customers using the AWS European Sovereign Cloud will also be able to take advantage of the AWS Marketplace, a curated digital catalog that makes it convenient to find, test, buy, and deploy third-party software. To help customers and partners plan their deployments to the AWS European Sovereign Cloud, we’ve published the roadmap of initial services at the end of this blogpost.

Start building for sovereignty today on AWS

AWS is committed to offering our customers the most advanced set of sovereignty controls and features available in the cloud. We have a wide range of offerings to help you meet your unique digital sovereignty requirements, including our eight existing Regions in Europe, AWS Dedicated Local Zones, and AWS Outposts. The AWS European Sovereign Cloud is an additional option to choose from. You can start building in our existing sovereign-by-design Regions and, if needed, migrate to the AWS European Sovereign Cloud. If you have stringent isolation and in-country data residency requirements, you will also be able to use Dedicated Local Zones or Outposts to deploy AWS European Sovereign Cloud infrastructure in locations you select.

Today, you can conduct proof-of-concept exercises and gain hands-on experience that will help you hit the ground running when the AWS European Sovereign Cloud launches in 2025. For example, you can use AWS CloudFormation to create and provision AWS infrastructure deployments predictably and repeatedly in an existing Region to prepare for the AWS European Sovereign Cloud. Using AWS CloudFormation, you can leverage services like Amazon EC2, Amazon Simple Notification Service (Amazon SNS), and Elastic Load Balancing to build highly reliable, highly scalable, cost-effective applications in the cloud in a repeatable, auditable, and automatable manner. You can use Amazon SageMaker to build, train, and deploy your machine learning models (including large language and other foundation models). You can use Amazon S3 to benefit from automatic encryption on all object uploads. If you have a regulatory need to store and use your encryption keys on premises or outside AWS, you can use the AWS KMS External Key Store.

Whether you’re migrating to the cloud for the first time, considering the AWS European Sovereign Cloud, or modernizing your applications to take advantage of cloud services, you can benefit from our experience helping organizations of all sizes move to and thrive in the cloud. We provide a wide range of resources to adopt the cloud effectively and accelerate your cloud migration and modernization journey, including the AWS Cloud Adoption Framework and AWS Migration Acceleration Program. Our global AWS Training and Certification helps learners and organizations build in-demand cloud skills and validate expertise with free and low-cost training and industry-recognized AWS Certification credentials, including more than 100 training resources for AI and machine learning (ML).

Customers and partners welcome the AWS European Sovereign Cloud service roadmap

Adobe is the world leader in creating, managing, and optimizing digital experiences. For over twelve years, Adobe Experience Manager (AEM) Managed Services has leveraged the AWS Cloud to support Adobe customers’ use of AEM Managed Services. “Over the years, AEM Managed Services has focused on the four pillars of security, privacy, regulation, and governance to ensure Adobe customers have best-in-class digital experience management tools at their disposal,” Mitch Nelson, Senior Director, Worldwide Managed Services at Adobe. “We are excited about the launch of the AWS European Sovereign Cloud and the opportunity it presents to align with Adobe’s Single Sovereign Architecture for AEM offering. We look forward to being among the first to provide the AWS European Sovereign Cloud to Adobe customers.”

adesso SE is a leading IT services provider in Germany with a focus on helping customers optimize core business processes with modern IT. adesso SE and AWS have been working together to help organizations drive digital transformations, quickly and efficiently, with tailored solutions. “With the European Sovereign Cloud, AWS is providing another option that can help customers navigate the complexity around changing rules and regulations. Organizations across the public sector and regulated industries are already using the AWS Cloud to help meet their digital sovereignty requirements, and the AWS European Sovereign Cloud will unlock additional opportunities,” said Markus Ostertag, Chief AWS Technologist, adesso SE. “As one of Germany’s largest IT service providers, we see the benefits that the European Sovereign Cloud service portfolio will provide to help customers innovate while getting the reliability, resiliency, and availability they need. AWS and adesso SE share a mutual commitment to meeting the unique needs of our customers, and we look forward to continuing to help organizations across the EU drive advancements.”

Genesys, a global leader in AI-powered experience orchestration, empowers more than 8,000 organizations in over 100 countries to deliver personalized, end-to-end experience at scale. With Genesys Cloud running on AWS, the companies have a longstanding collaboration to deliver scalable, secure, and innovative services to joint global clientele. “Genesys is at the forefront of helping businesses use AI to build loyalty with customers and drive productivity and engagement with employees,” said Glenn Nethercutt, Chief Technology Officer at Genesys. “Delivery of the Genesys Cloud platform on the AWS European Sovereign Cloud will enable even more organizations across Europe to experiment, build, and deploy cutting-edge customer experience applications while adhering to stringent data sovereignty and regulatory requirements. Europe is a key player in the global economy and a champion of data protection standards, and upon its launch, the AWS European Sovereign Cloud will offer a comprehensive suite of services to help businesses meet both data privacy and regulatory requirements. This partnership reinforces our continued investment in the region and Genesys and AWS remain committed to working together to help address the unique challenges faced by European businesses, especially those in highly regulated industries such as finance and healthcare.”

Pega provides a powerful platform that empowers global clients to use AI-powered decisioning and workflow automation solutions to solve their most pressing business challenges – from personalizing engagement to automating service to streamlining operations. Pega’s strategic work with AWS has allowed Pega to transform its as-a-Service business to become a highly scalable, reliable, and agile way for our clients to experience Pega’s platform across the globe. “The collaboration between AWS and Pega will deepen our commitment to our European Union clients to storing and processing their data within region,” said Frank Guerrera, chief technical systems officer at Pegasystems. “Our combined solution, taking advantage of the AWS European Sovereign Cloud, will allow Pega to provide sovereignty assurances at all layers of the service, from Pega’s platform and supporting technologies all the way to the enabling infrastructure. This solution combines Pega Cloud’s already stringent approach to data isolation, people, and process with the new and innovative AWS European Sovereign Cloud to deliver flexibility for our public sector and highly regulated industry clients.”

SVA System Vertrieb Alexander GmbH is one of the leading founder-owned system integrators in Germany with more than 3,200 talented employees at 27 offices across the country that are delivering best-in-class solutions to more than 3,000 customers. The 10-year collaboration between SVA and AWS has helped support customers across all industries and verticals to migrate and modernize workloads from on-premises to AWS or build new solutions from scratch. “The AWS European Sovereign Cloud is addressing specific needs for highly regulated customers, can lower the barriers and unlock huge digitalization potential for these verticals,” said Patrick Glawe, AWS Alliance Lead at SVA System Vertrieb Alexander GmbH. “Given our broad coverage across the public sector and regulated industries, we listen carefully to the discussions regarding cloud adoption and will soon be offering an option to design a highly innovative ecosystem that meets the highest standards of data protection, regulatory compliance, and digital sovereignty requirements. This will have a major impact on the European Union’s digitalization agenda.”

We remain committed to giving our customers more control and more choice to take advantage of the innovation the cloud can offer while helping them meet their unique digital sovereignty needs, without compromising on the full power of AWS. Learn more about the AWS European Sovereign Cloud on our European Digital Sovereignty website and stay tuned for more updates as we continue to drive toward the 2025 launch.

Initial planned services for the AWS European Sovereign Cloud
Analytics

  • Amazon Athena
  • Amazon Data Firehose
  • Amazon EMR
  • Amazon Kinesis Data Streams
  • Amazon Managed Service for Apache Flink
  • Amazon Managed Streaming for Apache Kafka (Amazon MSK)
  • Amazon OpenSearch Service
  • AWS Glue
  • AWS Lake Formation

Application Integration

  • Amazon EventBridge
  • Amazon Simple Notification Service (Amazon SNS)
  • Amazon Simple Queue Service (Amazon SQS)
  • Amazon Simple Workflow Service (Amazon SWF)
  • AWS Step Functions

Artificial Intelligence / Machine Learning

  • Amazon Bedrock
  • Amazon Q
  • Amazon SageMaker

AWS Marketplace

AWS Support

Business Applications

  • Amazon Simple Email Service (Amazon SES)

Cloud Financial Management

  • AWS Budgets
  • AWS Cost Explorer

Compute

  • Amazon EC2 Auto Scaling
  • Amazon Elastic Compute Cloud (Amazon EC2)
  • AWS Batch
  • AWS Lambda
  • EC2 Image Builder

Containers

  • Amazon Elastic Container Registry (Amazon ECR)
  • Amazon Elastic Container Service (Amazon ECS)
  • Amazon Elastic Kubernetes Service (Amazon EKS)
  • AWS Fargate

Database

  • Amazon Aurora
  • Amazon DynamoDB
  • Amazon ElastiCache
  • Amazon Redshift
  • Amazon Relational Database Service (Amazon RDS)
  • Amazon RDS for Oracle
  • Amazon RDS for SQL Server

Developer Tools

  • AWS CodeDeploy
  • AWS X-Ray
 Management & Governance

  • Amazon CloudWatch
  • AWS CloudFormation
  • AWS CloudTrail
  • AWS Config
  • AWS Control Tower
  • AWS Health Dashboard
  • AWS License Manager
  • AWS Management Console
  • AWS Organizations
  • AWS Systems Manager
  • AWS Trusted Advisor

Migration & Modernization

  • AWS Database Migration Service (AWS DMS)
  • AWS DataSync
  • AWS Transfer Family

Networking & Content Delivery

  • Amazon API Gateway
  • Amazon Route 53
  • Amazon Virtual Private Cloud (Amazon VPC)
  • AWS Cloud Map
  • AWS Direct Connect
  • AWS Site-to-Site VPN
  • AWS Transit Gateway
  • Elastic Load Balancing (ELB)

Security, Identity, & Compliance

  • Amazon Cognito
  • Amazon GuardDuty
  • AWS Certificate Manager (ACM)
  • AWS Directory Service
  • AWS Firewall Manager
  • AWS IAM Identity Center
  • AWS Identity and Access Management (IAM)
  • AWS Key Management Service (AWS KMS)
  • AWS Private Certificate Authority
  • AWS Resource Access Manager (AWS RAM)
  • AWS Secrets Manager
  • AWS Security Hub
  • AWS Shield Advanced
  • AWS WAF
  • IAM Access Analyzer

Storage

  • Amazon Elastic Block Store (Amazon EBS)
  • Amazon Elastic File System (Amazon EFS)
  • Amazon FSx for Lustre
  • Amazon FSx for NetApp ONTAP
  • Amazon FSx for OpenZFS
  • Amazon FSx for Windows File Server
  • Amazon Simple Storage Service (Amazon S3)
  • AWS Backup
  • AWS Storage Gateway

Contact your AWS Account Manager to discuss your AWS Services requirements further.

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

French version

Annonce des premiers services disponibles dans l’AWS European Sovereign Cloud, basés sur toute la puissance d’AWS

Le mois dernier, nous avons annoncé un investissement de 7,8 milliards d’euros dans l’AWS European Sovereign Cloud, un nouveau cloud indépendant pour l’Europe qui sera lancé d’ici fin 2025. L’AWS European Sovereign Cloud vise à offrir aux organisations du secteur public et aux clients des industries hautement réglementées une nouvelle option pour répondre à leurs exigences spécifiques en matière de souveraineté numérique, de localisation des données, d’autonomie opérationnelle et de résilience. Les clients et partenaires utilisant l’AWS European Sovereign Cloud bénéficieront de toute la puissance d’AWS, mais également de la même architecture à laquelle ils sont habitués, du même portefeuille étendu de services, des mêmes API et des mêmes fonctionnalités de sécurité que dans les 33 Régions AWS déjà en service. Aujourd’hui, nous sommes ravis de dévoiler une première feuille de route des services qui seront disponibles dans l’AWS European Sovereign Cloud. Cette annonce offre un aperçu de la richesse et de la diversité des services de l’AWS European Sovereign Cloud, conçu pour répondre aux besoins de nos clients et partenaires, tout en respectant notre engagement à offrir l’ensemble le plus avancé d’outils et de fonctionnalités de contrôle disponibles dans le cloud au service de la souveraineté.

L’AWS European Sovereign Cloud a été pensé pour être souverain dès sa conception, tout comme l’AWS Cloud depuis l’origine. Nous avons mis en place une infrastructure mondiale sécurisée à haut niveau de disponibilité, intégré des systèmes de protection pour la conception et le déploiement de nos services et développé une culture opérationnelle de la résilience. Nos clients bénéficient ainsi d’un cloud conçu pour les aider à répondre aux exigences de sécurité les plus strictes. Chaque Région est composée de plusieurs zones de disponibilité comprenant chacune un ou plusieurs centres de données distincts avec une alimentation, une connectivité et un réseau redondants. La première Région de l’AWS European Sovereign Cloud sera située dans le land de Brandebourg, en Allemagne, avec une infrastructure entièrement localisée au sein de l’Union Européenne (UE). Comme dans nos Régions existantes, l’AWS European Sovereign Cloud s’appuiera sur AWS Nitro System. Ce système, à la base de nos instances Amazon Elastic Compute Cloud (Amazon EC2) implémente une séparation physique et logique robuste, afin que personne, y compris au sein d’AWS, ne puisse accéder aux données des clients traitées dans Amazon EC2.

Feuille de route des services pour l’AWS European Sovereign Cloud

Lors du lancement d’une nouvelle Région, nous commençons par mettre en place les services de base nécessaires à la gestion des applications critiques, avant d’étendre notre catalogue de services en fonction des demandes de nos clients et partenaires. L’AWS European Sovereign Cloud proposera initialement des services de différentes catégories, notamment pour l’intelligence artificielle avec Amazon SageMaker, Amazon Q et Amazon Bedrock, pour le calcul avec Amazon EC2 et AWS Lambda, pour les conteneurs avec Amazon Elastic Kubernetes Service (Amazon EKS) et Amazon Elastic Container Service (Amazon ECS), pour les bases de données avec Amazon Aurora, Amazon DynamoDB et Amazon Relational Database Service (Amazon RDS), pour la mise en réseau avec Amazon Virtual Private Cloud (Amazon VPC), pour la sécurité avec AWS Key Management Service (AWS KMS) et AWS Private Certificate Authority et pour le stockage avec Amazon Simple Storage Service (Amazon S3) et Amazon Elastic Block Store (Amazon EBS). L’AWS European Sovereign Cloud disposera de ses propres systèmes dédiés de gestion des identités et des accès (IAM), de facturation et de mesure de l’utilisation, fonctionnant de manière indépendante des Régions existantes. Ces systèmes permettront aux clients utilisant l’AWS European Sovereign Cloud de conserver toutes leurs données ainsi que toutes les métadonnées qu’ils créent (comme les rôles, les permissions, les étiquettes de ressources et les configurations utilisées pour exécuter les services) dans l’Union européenne. Les clients d’AWS European Sovereign Cloud pourront également profiter de l’AWS Marketplace, un catalogue numérique organisé qui facilite la recherche, le test, l’achat et le déploiement de logiciels tiers. Afin d’aider les clients et les partenaires à préparer leurs déploiements sur l’AWS European Sovereign Cloud, nous publions la feuille de route des services initiaux à la fin de cet article.

Commencez dès aujourd’hui à développer vos solutions souveraines sur AWS

AWS s’engage à proposer l’ensemble le plus avancé d’outils et de fonctionnalités de contrôle disponibles dans le cloud au service de la souveraineté. Nous disposons d’une large gamme de solutions pour vous aider à répondre à vos exigences uniques en matière de souveraineté numérique, y compris nos huit Régions existantes en Europe, les AWS Dedicated Local Zones et les AWS Outposts. L’AWS European Sovereign Cloud constitue une option supplémentaire. Vous pouvez commencer à développer vos projets dans nos Régions existantes, toutes souveraines dès leur conception, et migrer si nécessaire vers l’AWS European Sovereign Cloud. En cas d’exigences strictes pour l’isolation et la localisation des données dans un pays, vous pourrez également utiliser les Dedicated Local Zones ou les Outposts pour déployer l’infrastructure de l’AWS European Sovereign Cloud là où vous le désirez.

Dès aujourd’hui, vous pouvez construire des démonstrateurs (PoC) et acquérir une expérience pratique qui vous permettra d’être opérationnel dès le lancement de l’AWS European Sovereign Cloud en 2025. Vous pouvez par exemple utiliser AWS CloudFormation pour créer et déployer de manière prévisible et répétée des déploiements d’infrastructure AWS dans une Région existante afin de vous préparer à l’AWS European Sovereign Cloud. Avec AWS CloudFormation, vous pouvez exploiter des services comme Amazon EC2, Amazon Simple Notification Service (Amazon SNS) et Elastic Load Balancing afin de développer des applications cloud hautement fiables et hautement évolutives de manière reproductible, auditable et automatisable. Amazon SageMaker vous permet de créer, d’entraîner et de déployer tous vos modèles d’apprentissage automatique, y compris des grands modèles de langage (LLM). Et avec Amazon S3, vous pouvez bénéficier du chiffrement automatique pour tous les objets importés. Enfin, si vous devez stocker et utiliser vos clés de chiffrement sur site ou en dehors d’AWS en raison de certaines réglementations, vous pouvez utiliser AWS KMS External Key Store.

Que vous vous apprêtiez à migrer vers le cloud pour la première fois, que vous envisagiez de passer à l’AWS European Sovereign Cloud ou que vous ayez pour projet de moderniser vos applications pour profiter des services cloud, notre expérience peut vous être précieuse. Nous aidons des organisations de différentes tailles à réussir leur transition vers le cloud. Nous mettons à votre disposition une large gamme de ressources pour adopter efficacement le cloud, accélérer votre migration ou votre modernisation, à l’image du Framework d’adoption du cloud AWS et du programme d’accélération des migrations AWS. Notre programme de certification AWS permet aux professionnels et aux organisations de développer des compétences cloud très demandées et de valider leur expertise grâce à des formations gratuites ou peu coûteuses ainsi qu’à des certifications AWS reconnues par l’ensemble de l’industrie. Nous proposons ainsi plus de 100 ressources de formation en intelligence artificielle et en apprentissage automatique.

Nos clients et partenaires accueillent favorablement le portefeuille de services de l’AWS European Sovereign Cloud

Adobe est le leader mondial de la création, de la gestion et de l’optimisation des expériences numériques. Depuis plus de douze ans, les services gérés Adobe Experience Manager (AEM) s’appuient sur le cloud Amazon Web Services (AWS) pour accompagner les clients d’Adobe dans leur utilisation d’AEM. « Au fil des années, les services d’AEM se sont concentrés sur les quatre piliers que sont la sécurité, la confidentialité, la réglementation et la gouvernance, afin de garantir aux clients d’Adobe l’accès aux meilleurs outils de gestion d’expérience numérique du marché », a déclaré Mitch Nelson, Senior Director, Worldwide Managed Services, Adobe. « Nous sommes ravis du lancement d’AWS European Sovereign Cloud, qui représente une opportunité unique de s’aligner sur l’architecture souveraine d’Adobe pour l’offre AEM. Nous espérons être parmi les premiers à proposer AWS European Sovereign Cloud aux clients d’Adobe. »

adesso SE est un important fournisseur de services informatiques en Allemagne, spécialisé dans l’optimisation des processus opérationnels essentiels à l’aide de technologies informatiques modernes. En collaboration avec AWS, adesso SE accompagne les organisations dans leurs transformations numériques avec des solutions personnalisées et efficaces. Pour Markus Ostertag, Chief AWS Technologist chez adesso SE, « l’European Sovereign Cloud d’AWS, est une nouvelle option qui va permettre aux clients de se frayer un chemin dans la complexité toujours croissante des réglementations. Les organisations publiques et les industries réglementées utilisent déjà le Cloud AWS pour répondre à leurs exigences en matière de souveraineté numérique, et l’AWS European Sovereign Cloud leur ouvrira de nouvelles perspectives. » Il poursuit : « En tant que l’un des principaux fournisseurs de services informatiques en Allemagne, nous voyons les avantages que le portefeuille de services de l’European Sovereign Cloud apporteront pour stimuler l’innovation tout en garantissant fiabilité, résilience et disponibilité. AWS et adesso SE partagent un engagement commun à répondre aux besoins spécifiques de nos clients, et nous sommes impatients de continuer à accompagner les différentes organisations à travers l’Union européenne dans leurs avancées technologiques. »

Genesys, leader mondial dans l’orchestration des expériences clients alimentées par l’IA, permet à plus de 8 000 organisations réparties dans plus de 100 pays de proposer des expériences personnalisées de bout en bout à grande échelle. En partenariat avec Amazon Web Services (AWS), Genesys Cloud tire parti de cette plateforme depuis longtemps pour fournir des services sécurisés, évolutifs et innovants à une clientèle mondiale commune. Glenn Nethercutt, Chief Technology Officer chez Genesys, commente : « Genesys joue un rôle de premier plan en aidant les entreprises à utiliser l’IA pour fidéliser leurs clients mais aussi améliorer la productivité et l’engagement de leurs employés. Le déploiement de la plateforme Genesys Cloud sur l’AWS European Sovereign Cloud permettra à davantage d’organisations à travers l’Europe d’explorer, développer et déployer des applications avancées d’expérience client, tout en respectant les exigences et les réglementations les plus strictes en matière de souveraineté des données. L’Europe est un acteur clé de l’économie mondiale et un défenseur des normes de protection des données. Avec le lancement prochain de l’AWS European Sovereign Cloud, une gamme complète de services sera proposée pour aider les entreprises à répondre aux exigences réglementaires et de confidentialité des données. Ce partenariat renforce notre investissement continu dans la région. Genesys et AWS restent engagés à collaborer pour relever les défis uniques auxquels les entreprises européennes sont confrontées, en particulier celles des secteurs hautement réglementés comme la finance et la santé. »

Pega propose une plateforme performante qui permet aux clients internationaux de relever leurs défis commerciaux les plus urgents grâce à des solutions d’aide à la prise de décision et d’automatisation des flux basées sur l’IA. Des solutions qui vont de la personnalisation des interactions client à l’automatisation des services en passant par l’optimisation des opérations. Le partenariat stratégique avec AWS a permis à Pega de transformer son activité en mode SaaS (logiciel en tant que service) en une solution hautement évolutive, fiable et agile, offrant à nos clients une expérience optimale de la plateforme Pega, partout dans le monde. Frank Guerrera, Chief Technical Systems Officer chez Pegasystems, précise : « La collaboration entre AWS et Pega renforcera notre engagement envers nos clients de l’Union européenne pour le stockage et le traitement de leurs données dans la région. Notre solution combinée, tirant parti de l’AWS European Sovereign Cloud, permettra à Pega d’offrir des garanties de souveraineté à tous les niveaux du service, de la plateforme Pega et ses technologies jusqu’à l’infrastructure sous-jacente. Cette solution associe l’approche déjà rigoureuse de Pega Cloud en matière d’isolation des données, de ressources humaines et de processus à celle, nouvelle et innovante, de l’AWS European Sovereign Cloud pour offrir une flexibilité accrue à nos clients du secteur public et des industries hautement réglementées. »

SVA System Vertrieb Alexander GmbH est l’un des principaux intégrateurs de systèmes en Allemagne. Fondé et dirigé par ses propriétaires, il emploie plus de 3 200 employés répartis dans 27 bureaux à travers le pays, et fournit des solutions de pointe à plus de 3 000 clients. Les 10 années de collaboration avec AWS ont permis d’aider des clients de tous les secteurs à migrer et à moderniser leurs applications depuis les infrastructures sur site vers AWS, mais aussi à créer de nouvelles solutions à partir de zéro. « L’AWS European Sovereign Cloud répond aux besoins spécifiques des clients issus d’industries hautement réglementées, peut contribuer à réduire les obstacles existants et libérer un formidable potentiel de numérisation », a déclaré Patrick Glawe, AWS Alliance Lead, SVA System Vertrieb Alexander GmbH. « En tant que partenaire privilégié du secteur public et des industries réglementées, nous suivons de près les discussions sur l’adoption du cloud et nous allons bientôt proposer une option permettant de concevoir un écosystème hautement innovant répondant aux normes les plus strictes en matière de protection des données, de conformité réglementaire et de souveraineté numérique. Cela aura un impact majeur sur le programme de numérisation de l’Union européenne. »

Nous réaffirmons notre engagement à offrir à nos clients plus de contrôle et de choix afin qu’ils puissent tirer pleinement parti des innovations offertes par le cloud, tout en les aidant à répondre à leurs besoins spécifiques en matière de souveraineté numérique, sans aucun compromis sur la puissance d’AWS. Découvrez-en davantage sur l’AWS European Sovereign Cloud sur notre site internet dédié à la souveraineté numérique européenne et suivez l’évolution du projet à mesure que nous nous rapprochons de son lancement en 2025.
 

German version

Bekanntgabe der ersten Services in der AWS European Sovereign Cloud, angetrieben von der vollen Leistungsfähigkeit von AWS

Letzten Monat haben wir bekanntgegeben, dass wir 7,8 Milliarden Euro in die AWS European Sovereign Cloud investieren, eine neue unabhängige Cloud für Europa, die bis Ende 2025 eröffnen soll. Wir bauen die AWS European Sovereign Cloud auf, um Organisationen des öffentlichen Sektors und Kunden in stark regulierten Branchen mehr Wahlmöglichkeiten zu bieten. Wir möchten ihnen dabei helfen, ihre spezifischen Anforderungen an die digitale Souveränität sowie die strengen Vorgaben in Bezug auf den Ort der Datenverarbeitung, die betriebliche Autonomie und die Resilienz zu erfüllen. Kunden und Partner werden von der vollen Leistungsstärke von AWS profitieren, wenn sie die AWS European Sovereign Cloud nutzen. Dazu gehören auch die bekannte Architektur, das Service-Portfolio, die APIs und die Sicherheitsfunktionen, die bereits in unseren 33 bestehenden AWS-Regionen verfügbar sind. Wir freuen uns sehr, heute eine erste Roadmap mit den Services, die in der AWS European Sovereign Cloud verfügbar sein werden, vorzustellen. Diese Bekanntgabe unterstreicht den Umfang des Service-Portfolios der AWS European Sovereign Cloud, das nicht nur die Ansprüche unserer Kunden und Partner erfüllt, sondern auch unser Versprechen, die fortschrittlichsten Souveränitätskontrollen und -funktionen zu bieten, die überhaupt in der Cloud verfügbar sind.

Die AWS European Sovereign Cloud basiert, so wie auch die AWS Cloud seit Tag eins, auf dem „sovereign-by-design“-Ansatz. Wir haben eine sichere und hochverfügbare globale Infrastruktur entwickelt, Schutzmaßnahmen in unser Service-Design und unsere Bereitstellungsmechanismen integriert und Resilienz fest in unserer Betriebskultur verankert. Unsere Kunden profitieren von einer Cloud, die sie dabei unterstützt, selbst die Anforderungen der sicherheitssensibelsten Organisationen zu erfüllen. Jede Region besteht aus mehreren Verfügbarkeitszonen (Availability Zones, AZs) und jede AZ aus einem oder mehreren diskreten Rechenzentren, deren Stromversorgung, Konnektivität und Netzwerk komplett redundant aufgebaut sind. Die erste Region der AWS European Sovereign Cloud ist in Brandenburg geplant, die Infrastruktur wird vollständig in der EU angesiedelt sein. Die AWS European Sovereign Cloud wird wie auch unsere bestehenden Regionen das AWS Nitro System nutzen. Das Nitro System bildet die Grundlage für alle unsere modernen Amazon Elastic Compute Cloud (EC2) Instanzen und basiert auf einer starken physikalischen und logischen Sicherheitsabgrenzung. Damit werden Zugriffsbeschränkungen realisiert, so dass niemand, einschließlich AWS-Mitarbeitern, Zugriff auf Kundendaten, die auf Amazon EC2 laufen, hat.

Service-Roadmap für die AWS European Sovereign Cloud

Wenn wir eine neue Region in Betrieb nehmen, beginnen wir zunächst mit den zentralen Services, die für kritische Arbeitslasten und Anwendungen benötigt werden. Danach erweitern wir den Servicekatalog je nach Bedarf unserer Kunden und Partner. Die AWS European Sovereign Cloud wird zu Beginn Services aus verschiedenen Kategorien bieten, u. a. für künstliche Intelligenz Amazon SageMaker, Amazon Q und Amazon Bedrock; für Compute Amazon EC2 und AWS Lambda; für Container Amazon Elastic Kubernetes Service (Amazon EKS) und Amazon Elastic Container Service (Amazon ECS); für Datenbanken Amazon Aurora, Amazon DynamoDB und Amazon Relational Database Service (Amazon RDS); für Networking Amazon Virtual Private Cloud (Amazon VPC); für Sicherheit AWS Key Management Service (AWS KMS) und AWS Private Certificate Authority; sowie für Speicherung Amazon Simple Storage Service (Amazon S3) und Amazon Elastic Block Store (Amazon EBS). Die AWS European Sovereign Cloud wird über eigene dedizierte Systeme für Identity und Access Management (IAM), Abrechnung und Nutzungsüberwachung verfügen, die unabhängig von bestehenden Regionen betrieben werden. Diese Systeme ermöglichen es Kunden bei der Nutzung der AWS European Sovereign Cloud, alle Kundendaten und von ihnen erstellte Metadaten (etwa Rollen, Berechtigungen, Ressourcenbezeichnungen und Konfigurationen für den Betrieb von AWS), innerhalb der EU zu behalten. Außerdem haben Kunden, welche die AWS European Sovereign Cloud nutzen, Zugriff auf den AWS Marketplace, einen kuratierten digitalen Katalog, mit dem sich leicht Drittanbieter-Software finden, testen, kaufen und integrieren lässt. Um Kunden und Partnern dabei zu helfen, die Bereitstellung der AWS European Sovereign Cloud zu planen, stellen wir am Ende dieses Blogbeitrags eine Roadmap der ersten Services bereit.

Beginnen Sie noch heute mit der Umsetzung Ihrer digitalen Souveränität mit AWS

Bei AWS haben wir uns zum Ziel gesetzt, unseren Kunden die fortschrittlichsten Steuerungsmöglichkeiten für Souveränitätsanforderungen und Funktionen anzubieten, die in der Cloud verfügbar sind. Mit unserem breitgefächerten Angebot, darunter z. B. unsere acht bestehenden Regionen in Europa, AWS Dedicated Local Zones und AWS Outposts, helfen wir Ihnen, Ihre individuellen Anforderungen an die digitale Souveränität zu erfüllen. Die AWS European Sovereign Cloud bietet Ihnen eine weitere Wahlmöglichkeit. Sie können in unseren bestehenden „sovereign-by-design“-Regionen anfangen und bei Bedarf in die AWS European Sovereign Cloud migrieren. Wenn Sie weitere Optionen benötigen, um eine Isolierung zu ermöglichen und strenge Anforderungen an den Ort der Datenverarbeitung in einem bestimmten Land zu erfüllen, können Sie auf AWS Dedicated Local Zones oder AWS Outposts zurückgreifen, um die Infrastruktur der AWS European Sovereign Cloud am Ort Ihrer Wahl zu nutzen.

Sie können schon heute Machbarkeitsstudien durchführen und praktische Erfahrung sammeln, sodass Sie sofort loslegen können, wenn die AWS European Sovereign Cloud 2025 eröffnet wird. Beispielsweise können Sie AWS CloudFormation nutzen, um AWS Ressourcen aus einer bestehenden Region automatisiert bereitzustellen und sich damit auf die AWS European Sovereign Cloud vorzubereiten. Mithilfe von AWS CloudFormation können Sie Services wie Amazon EC2, Amazon Simple Notification Service (Amazon SNS) und Elastic Load Balancing nutzen, um sehr zuverlässige, stark skalierbare und kosteneffiziente Anwendungen in der Cloud zu entwickeln – wiederholbar, prüfbar und automatisierbar. Sie können Amazon SageMaker nutzen, um Ihre Modelle für maschinelles Lernen (darunter auch große Sprachmodelle (LLMs) oder andere Grundlagenmodelle) zu entwickeln, zu trainieren und bereitzustellen. Mit Amazon S3 profitieren Sie von der automatischen Verschlüsselung aller Objekt-Uploads. Sollten Sie aufgrund rechtlicher Vorgaben Ihre Verschlüsselungsschlüssel vor Ort oder außerhalb von AWS speichern und nutzen müssen, können Sie den AWS KMS External Key Store nutzen.

Ganz gleich, ob Sie zum ersten Mal in die Cloud migrieren, die AWS European Sovereign Cloud in Erwägung ziehen oder Ihre Anwendungen modernisieren, um Cloud-Services zu Ihrem Vorteil zu nutzen – Sie profitieren in jedem Fall von unserer Erfahrung, denn wir helfen Organisationen jeder Größe, in die Cloud zu migrieren und in der Cloud zu wachsen. Wir bieten eine große Bandbreite an Ressourcen, mit denen Sie die Cloud effektiv nutzen und Ihre Cloud-Migration sowie Ihre Modernisierungsreise beschleunigen können. Dazu gehören das AWS Cloud Adoption Framework und das AWS Migration Acceleration Programm. Unser globales AWS Training and Certification Programm hilft allen Lernenden und Organisationen, benötigte Cloud-Fähigkeiten zu erlangen und die vorhandene Expertise zu validieren – mit kostenlosen und kostengünstigen Schulungen und branchenweit anerkannten AWS-Zertifizierungen, darunter auch mehr als 100 Schulungen für KI und maschinelles Lernen (ML).

Kunden und Partner begrüßen die Service-Roadmap der AWS European Sovereign Cloud

Adobe ist weltweit führend in der Erstellung, Verwaltung und Optimierung digitaler Erlebnisse. Adobe Experience Manager (AEM) Managed Services nutzt seit über 12 Jahren die AWS Cloud, um Adobe-Kunden die Nutzung von AEM Managed Services zu ermöglichen. „Im Laufe der Jahre hat AEM Managed Services sich auf die vier Grundpfeiler Sicherheit, Datenschutz, Regulierung und Governance konzentriert, um sicherzustellen, dass Adobe-Kunden branchenführende Werkzeuge zur Verwaltung ihrer digitalen Erlebnisse zur Verfügung haben“, sagt Mitch Nelson, Senior Director, Worldwide Managed Services bei Adobe. „Wir freuen uns über die Einführung der AWS European Sovereign Cloud und die Möglichkeit, diese an Adobes Single Sovereign Architecture for AEM Angebot auszurichten. Wir freuen uns darauf, zu den Ersten zu gehören, die Adobe-Kunden die AWS European Sovereign Cloud zur Verfügung stellen“.

adesso SE ist ein führender deutscher IT-Service-Provider, der Kunden dabei hilft, zentrale Unternehmensprozesse mithilfe moderner IT zu optimieren. Durch die Zusammenarbeit von adesso SE und AWS können Organisationen ihre digitale Transformation mithilfe maßgeschneiderter Lösungen schnell und effektiv vorantreiben. „Mit der AWS European Sovereign Cloud bietet AWS eine weitere Möglichkeit, die Kunden dabei hilft, den komplexen Herausforderungen der sich ständig ändernden Bestimmungen und Vorschriften zu begegnen. Organisationen aus dem öffentlichen Sektor und aus stark regulierten Branchen nutzen die AWS Cloud bereits, um die Anforderungen an ihre digitale Souveränität erfüllen zu können. Die AWS European Sovereign Cloud wird ihnen zusätzliche Chancen und Möglichkeiten eröffnen“, so Markus Ostertag, Chief AWS Technologist, adesso SE. „Als einer der größten IT-Service-Provider Deutschlands können wir deutlich sehen, welche Vorteile das Service-Portfolio der AWS European Sovereign Cloud bietet und wie es Kunden hilft, Innovationen voranzutreiben und gleichzeitig die benötigte Verlässlichkeit, Resilienz und Verfügbarkeit zu erlangen. AWS und adesso SE haben ein gemeinsames Ziel, denn wir streben beide danach, die individuellen Anforderungen unserer Kunden zu erfüllen. Wir freuen uns darauf, weiterhin EU-weit Unternehmen dabei zu helfen, sich weiterzuentwickeln.“

Genesys, eine weltweit führende KI-gestützte Plattform für die Orchestrierung von Kundenerlebnissen, unterstützt mehr als 8.000 Organisationen in über 100 Ländern dabei, personalisierte End-To-End-Erlebnisse nach Maß bereitzustellen. Genesys Cloud wird auf AWS betrieben und die beiden Unternehmen arbeiten schon lange eng zusammen, um ihrer gemeinsamen globalen Kundenbasis skalierbare, sichere und innovative Services zu bieten. „Genesys ist ein Vorreiter auf ihrem Gebiet. Wir helfen Unternehmen dabei, mithilfe von KI die Kundenloyalität zu verbessern und die Produktivität und das Engagement der Mitarbeitenden zu steigern“, erklärt Glenn Nethercutt, Chief Technology Officer bei Genesys. „Mit der Bereitstellung der Cloud-Plattform von Genesys in der AWS European Sovereign Cloud ermöglichen wir es noch mehr Unternehmen in ganz Europa, hochmoderne Anwendungen für ein besseres Kundenerlebnis zu entwickeln und bereitzustellen, und gleichzeitig strenge gesetzliche Vorgaben sowie Anforderungen an die digitale Souveränität einzuhalten. Europa ist ein wichtiger Akteur in der globalen Wirtschaft und ein Verfechter strenger Datenschutzstandards. Bei ihrer Einführung wird die AWS European Sovereign Cloud eine umfassende Service-Suite bieten, um Unternehmen dabei zu helfen, sowohl datenschutzrechtliche als auch regulatorische Anforderungen zu erfüllen. Die Partnerschaft verstärkt unsere anhaltenden Investitionen in der Region. Genesys und AWS werden weiterhin zusammenarbeiten, um die einzigartigen Herausforderungen anzugehen, denen sich europäische Unternehmen gegenübersehen – vor allem jene in stark regulierten Branchen wie dem Finanz- und Gesundheitswesen.“

Pega bietet globalen Kunden eine starke Plattform für die KI-gestützte Entscheidungsfindung und Workflow-Automatisierung, mit der sie ihre größten Herausforderungen meistern – von der Personalisierung des Engagements über die Automatisierung von Services bis hin zur Optimierung von Betriebsabläufen. Dank der strategischen Zusammenarbeit mit AWS konnte Pega ihr As-a-Service-Geschäft transformieren und Kunden einen stark skalierbaren, verlässlichen und agilen Weg bieten, die Pega-Plattform in aller Welt zu erleben. „Die Zusammenarbeit von AWS und Pega wird unsere Verpflichtung gegenüber unseren Kunden in der EU stärken, ihre Daten in der Region zu speichern und zu verarbeiten“, freut sich Frank Guerrera, Chief Technical Systems Officer bei Pegasystems. „Unsere gemeinsame Lösung, die die Vorteile der AWS European Sovereign Cloud nutzen wird, erlaubt Pega, Souveränitätszusagen auf allen Ebenen des Services zu treffen, von der Pega-Plattform über unterstützende Technologien bis hin zur erforderlichen Infrastruktur. Diese Lösung vereint den bereits vorhandenen strengen Ansatz der Pega Cloud an Datenisolierung, Menschen und Prozesse mit der neuen, innovativen AWS European Sovereign Cloud, um unseren Kunden aus dem öffentlichen Sektor und aus stark regulierten Branchen mehr Flexibilität zu bieten.“

SVA System Vertrieb Alexander GmbH ist einer der führenden inhabergeführten IT-Dienstleister Deutschlands und bietet seinen mehr als 3.000 Kunden mit über 3.200 talentierten Mitarbeitenden an 27 Standorten im Land branchenführende Lösungen. Die bereits zehn Jahre andauernde Zusammenarbeit von SVA und AWS hat dabei geholfen, Kunden aus allen Branchen bei der Migration und Modernisierung ihrer Workloads von eigenen Standorten zu AWS zu unterstützen oder beim Aufbau ganz neuer Lösungen. „Die AWS European Sovereign Cloud ist auf die spezifischen Anforderungen stark regulierter Kunden ausgerichtet. Sie kann die Hürden für diese Branchen mindern und ihnen ein riesiges Digitalisierungspotenzial eröffnen“, sagt Patrick Glawe, AWS Alliance Lead bei SVA System Vertrieb Alexander GmbH. „Angesichts unserer umfassenden Lösungen für den öffentlichen Sektor und regulierte Branchen verfolgen wir aufmerksam die Diskussionen rund um den Einsatz der Cloud und werden bald eine Option anbieten, mit der ein hochinnovatives Ökosystem entwickelt werden kann, das die höchsten Anforderungen an den Datenschutz, an die Einhaltung gesetzlicher Vorschriften und an die digitale Souveränität erfüllt. Das wird enorme Auswirkungen auf die Digitalisierungspläne der Europäischen Union haben.“

Wir sind weiterhin bestrebt, unseren Kunden mehr Kontrolle und weitere Optionen anzubieten, damit sie die Vorteile der Innovationsmöglichkeiten, die ihnen die Cloud bietet, nutzen und gleichzeitig alle individuellen Anforderungen an die digitale Souveränität erfüllen können – ohne auf die volle Leistungsfähigkeit von AWS verzichten zu müssen. Erfahren Sie mehr über die AWS European Sovereign Cloud auf unserer European Digital Sovereignty Website. Wir werden Sie vor dem Start 2025 kontinuierlich auf dem Laufenden halten.
 

Italian version

Presentiamo l’offerta di servizi base disponibili nell’AWS European Sovereign Cloud, basato sull’eccezionale potenza di calcolo di AWS

Il mese scorso abbiamo annunciato il nostro investimento nell’AWS European Sovereign Cloud pari a 7,8 miliardi di Euro, per sviluppare un nuovo cloud indipendente, dedicato al mercato europeo, che entrerà in servizio per la fine del 2025. Stiamo sviluppando l’AWS European Sovereign Cloud per offrire a una clientela formata da imprese del settore pubblico, e di settori altamente regolamentati, una scelta più ampia di soluzioni che rispondano alle loro specifiche esigenze in fatto di sovranità digitale, e che soddisfino rigorosi requisiti in tema di residenza dei dati, autonomia operativa e resilienza.

I clienti e i partner che sfruttano l’AWS European Sovereign Cloud potranno beneficiare di tutto il potenziale offerto da AWS che include la stessa architettura di sempre, basata su un ventaglio di servizi, API e funzionalità di sicurezza già disponibili nelle 33 Regioni AWS esistenti. Oggi, siamo lieti di annunciare la prima roadmap dei servizi disponibili nell’AWS European Sovereign Cloud. Questo annuncio sottolinea quanto sia ampio e strutturato il portfolio di servizi che saranno disponibili all’interno di questo Cloud, ideati per rispondere alle esigenze di clienti e partner, confermando il nostro impegno a fornire il set più avanzato di controlli sovrani e funzionalità disponibili in un ambiente cloud.

Il AWS European Sovereign Cloud è stato progettato per essere “sovereign-by-design”, proprio come abbiamo ideato il Cloud AWS sin dalle origini. Abbiamo progettato un’infrastruttura globale sicura e altamente accessibile, implementato salvaguardie all’interno dei nostri meccanismi di progettazione e implementazione del servizio e integrato la resilienza nella nostra cultura operativa. I nostri clienti possono beneficiare di un cloud ideato per aiutarli a rispondere alle esigenze di interlocutori che operano in settori critici per la sicurezza. Ogni regione è composta da una serie di Zone di Disponibilità, ognuna composta da uno o più data center riservati, dotati di alimentazione, connettività e rete ridondante. La prima regione del AWS European Sovereign Cloud nel Lander tedesco di Brandeburgo, mentre l’infrastruttura sarà situata interamente all’interno dell’Unione Europea. Al pari delle nostre Regioni già esistenti, l’AWS European Sovereign Cloud sarà basato sul AWS Nitro System. Il Nitro System alla base dei servizi offerti dal nostro avvenieristico Amazon Elastic Compute Cloud (Amazon EC2) garantendo un perimetro di sicurezza fisico e logico di livello assoluto, capace di applicare restrizioni di accesso in modo tale che nessuno, nemmeno i dipendenti AWS, possano accedere ai dati dei clienti in esecuzione su Amazon EC2.

Roadmap dell’implementazione dei servizi offerti nell’AWS European Sovereign Cloud

Quando attiviamo una nuova Regione, partiamo dai servizi di base necessari per supportare carichi di lavoro e applicazioni fondamentali, per poi espandere la nostra offerta di servizi in base alle richieste di clienti e partner. Nella fase iniziale, il AWS European Sovereign Cloud offrirà servizi provenienti da un ampio ventaglio di categorie, come quelli dedicati all’intelligenza artificiale – Amazon SageMaker, Amazon Q, e Amazon Bedrock, al calcolo informatico – Amazon EC2 e AWS Lambda, ai container – Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon Elastic Container Service (Amazon ECS), ai database – Amazon Aurora, Amazon DynamoDB, e Amazon Relational Database Service (Amazon RDS), al networking – Amazon Virtual Private Cloud (Amazon VPC), alla sicurezza – AWS Key Management Service (AWS KMS) e AWS Private Certificate Authority, oltre allo storage – Amazon Simple Storage Service (Amazon S3) e Amazon Elastic Block Store (Amazon EBS). Il AWS European Sovereign Cloud potrà vantare propri sistemi indipendenti di identificazione e accesso (IAM), di fatturazione e di rendicontazione dell’utilizzo, tutti operati in modo autonomo dalle Regioni esistenti. Questi sistemi sono ideati per consentire agli utenti che sfruttano il AWS European Sovereign Cloud di mantenere tutti i dati dei clienti, compresi i metadati creati come ruoli, permessi, etichette di risorse e configurazioni usate per operare in AWS, all’interno dell’Unione Europea. Inoltre, i clienti che usano il AWS European Sovereign Cloud saranno in grado di sfruttare il Marketplace AWS, ovvero, un catalogo digitale che rende più semplice individuare, testare, acquistare e implementare software di terze parti. Per assistere clienti e partner nella loro implementazione del AWS European Sovereign Cloud, abbiamo pubblicato una roadmap dei servizi base consultabile al termine di questo articolo.

Crea da subito la tua sovranità digitale su AWS

AWS si impegna a offrire ai propri clienti il più avanzato set di controlli e funzionalità di sovranità disponibili sul cloud. Mettiamo a disposizione un’ampia gamma di soluzioni dedicate alle tue specifiche esigenze in fatto di sovranità digitale, incluse le nostre otto Regioni esistenti in Europa, AWS Dedicated Local Zones e AWS Outposts, mentre il AWS European Sovereign CloudS è un’ulteriore opzione su cui fare affidamento. Puoi iniziare a lavorare all’interno delle nostre Regioni “sovereign-by-design”, e in caso di necessità, migrare all’interno del AWS European Sovereign Cloud. Se devi ottemperare a rigorose normative in materia di compartimentazione e residenza locale dei dati, possiamo mettere a disposizione anche Dedicated Local Zones o Outposts per usufruire dell’architettura offerta dal Cloud sovrano europeo AWS nella località di tua scelta.

Oggi puoi condurre esercitazioni di “proof-of-concept” per acquisire esperienza pratica capace di apportare un impatto significativo alla tua attività quando l’AWS European Sovereign Cloud sarà attivo nel 2025. Ad esempio, puoi sfruttare la AWS CloudFormation per avviare e impostare l’implementazione dell’infrastruttura AWS in modo puntuale e ripetuto all’interno di una Regione esistente come attività preparatoria all’adozione del AWS European Sovereign Cloud. Grazie alla AWS CloudFormation, puoi sfruttare servizi come Amazon EC2, Amazon Simple Notification Service (Amazon SNS) e il sistema Elastic Load Balancing per creare applicazioni nel cloud che spiccano per affidabilità, scalabilità ed economicità in un modo ripetibile, verificabile e automatizzato. Puoi usare Amazon SageMaker per progettare, addestrare e impegnare i tuoi modelli di machine learning (inclusi i modelli linguistici di grandi dimensioni e i modelli di fondazione). Puoi usare Amazon S3 per sfruttare i vantaggi della crittografia automatica su tutti i caricamenti di oggetti. Se hai esigenze normative che richiedono di archiviare e utilizzare le tue chiavi di crittografia in locale o all’esterno di AWS, puoi usare il AWS KMS External Key Store.

Qualora tu stia effettuando per la prima volta la migrazione verso il cloud, prendendo in considerazione l’utilizzo del AWS European Sovereign Cloud o aggiornando i tuoi applicativi per avvalerti dei servizi cloud, puoi beneficiare dalla nostra esperienza nell’assistere realtà di ogni dimensione che intendono adottare il cloud per sfruttare al meglio il suo potenziale. Offriamo un’ampia gamma di risorse da adottare in modo efficiente nel cloud, così da accelerare il tuo percorso di modernizzazione e migrazione verso il cloud, tra cui spiccano l’AWS Cloud Adoption Framework e l’AWS Migration Acceleration Program. Il nostro programma globale di Formazione e Certificazione AWS è al fianco di personale in formazione e imprese per sviluppare competenze cloud richieste dal mercato e convalidare le proprie conoscenze attraverso percorsi formativi gratuiti e a basso costo, insieme alle credenziali di certificazione AWS riconosciute dal settore che includono oltre 100 risorse didattiche per l’IA e il machine learning (ML).

Clienti e partner danno il benvenuto alla roadmap dell’implementazione dei servizi offerti nell’AWS European Sovereign Cloud

Adobe è il leader mondiale nella creazione, gestione e ottimizzazione delle esperienze digitali. Da oltre dodici anni, Adobe Experience Manager (AEM) Managed Services sfrutta il cloud AWS per supportare l’utilizzo di AEM Managed Services da parte dei clienti Adobe. “Nel corso degli anni, AEM Managed Services si è dimostrato un servizio incentrato su quattro elementi fondamentali come sicurezza, privacy, regolamentazione e governance per garantire che i clienti Adobe possano usare i migliori strumenti di gestione digitale disponibili sul mercato” Ha confermato Mitch Nelson, Senior Director, Workdwide Managed Services di Adobe. “Siamo lieti di presentare l’AWS European Sovereign Cloud e l’opportunità che rappresenta per allinearsi con l’architettura Single Sovereign di Adobe per l’offerta AEM. Non vediamo l’ora di essere tra i primi a fornire il servizio AWS European Sovereign Cloud ai clienti Adobe.”

Adesso SE è un fornitore leader di servizi IT localizzato in Germania, sempre al fianco dei clienti che intendono ottimizzare i principali processi aziendali grazie a una tecnologia digitale all’avanguardia. Adesso SE e AWS lavorano al fianco delle imprese per guidare le trasformazioni digitali in modo rapido ed efficiente grazie a soluzioni su misura. “Con il Cloud sovrano europeo, AWS mette in campo un’ulteriore soluzione ideata per aiutare i clienti a superare agevolmente la complessità di regole e normative in perenne evoluzione. Operatori del settore pubblico e di settori regolamentati stanno già sfruttando AWS Cloud per soddisfare i propri requisiti di sovranità digitale e l’AWS European Sovereign Cloud sbloccherà nuove e interessanti opportunità“, ha affermato Markus Ostertag, Chief AWS Technologist di Adesso SE. “In quanto uno dei principali fornitori tedeschi di servizi IT, siamo consapevoli dei vantaggi che il portfolio di servizi del Cloud sovrano europeo potrà offrire ai clienti che intendono innovare senza rinunciare all’affidabilità, alla resilienza e alla disponibilità di cui hanno bisogno. AWS e Adesso SE sono unite nel soddisfare le specifiche esigenze dei nostri clienti e non vediamo l’ora di continuare a supportare le imprese di tutta l’Unione Europea nel loro percorso di innovazione“.

Genesys, leader globale nell’orchestrazione dell’esperienza basata sull’IA, consente a più di 8.000 imprese dislocate in oltre 100 paesi di offrire esperienze personalizzate e complete su ampia scala. Grazie all’implementazione di Genesys Cloud su AWS, le due aziende firmano una partnership a lungo termine per fornire servizi scalabili, sicuri e innovativi alla loro clientela globale. “Con le sue soluzioni all’avanguardia, Genesys è al fianco delle imprese che intendono sfruttare l’IA per fidelizzare la clientela, aumentando al contempo i livelli di produttività e di coinvolgimento dei dipendenti”, ha affermato Glenn Nethercutt, Chief Technology Officer di Genesys. “L’implementazione della piattaforma Genesys Cloud sul Cloud sovrano europeo AWS potrà consentire a un numero ancora più elevato di imprese in tutta Europa di sperimentare, creare e adottare applicazioni all’avanguardia dedicate alla customer experience, rispettando le normative e i più rigorosi requisiti in fatto di sovranità dei dati. Oltre a essere una potenza mondiale a livello economico, l’Europa si distingue per le sue norme di protezione dei dati e in questo contesto favorevole, l’AWS European Sovereign Cloud sin dalla sua entrata in servizio potrà offrire un ventaglio completo di servizi dedicati alle imprese chiamate a soddisfare sia i requisiti di privacy dei dati che quelli normativi. Questa partnership è il segno tangibile del nostro impegno finanziario a lungo termine nella regione, con Genesys e AWS che confermano e rafforzano il proprio impegno nel rispondere alle sfide che le imprese europee sono chiamate ad affrontare, soprattutto nei settori altamente regolamentati come finanza e sanità”.

Pega fornisce una piattaforma a prestazioni elevate che mette i nostri clienti globali nelle migliori condizioni per sfruttare le nostre soluzioni IA dedicate all’automatizzazione di processi decisionali e flussi di lavoro, ideate per rispondere alle più importanti esigenze aziendali, dalla personalizzazione dell’engagement all’automazione dell’assistenza, fino all’ottimizzazione dell’operatività. La collaborazione strategica tra Pega e AWS ha consentito a Pega di trasformare il proprio modello di “business as-a-Service” in un modello altamente scalabile, affidabile e agile in grado di consentire ai nostri clienti di sperimentare la piattaforma Pega in tutto il mondo. “La collaborazione tra AWS e Pega sarà l’occasione per rafforzare il nostro impegno verso i nostri clienti basati nell’Unione Europea che necessitano di conservare ed elaborare i propri dati all’interno di questa regione”, ha affermato Frank Guerrera, chief technical systems officer di Pegasystems. “Potendo sfruttare l’AWS European Sovereign Cloud, la nostra soluzione integrata consentirà a Pega di garantire sovranità su tutti i livelli di servizio, dalla piattaforma di Pega passando per le tecnologie di supporto, fino all’infrastruttura di implementazione. Questa soluzione abbina il rigoroso approccio verso l’isolamento dei dati, la clientela e le procedure garantito dal Cloud di Pega con il nuovo e innovativo Cloud sovrano europeo firmato AWS per offrire flessibilità ai nostri clienti del settore pubblico e dei settori altamente regolamentati”.

SVA System Vertrieb Alexander GmbH è uno dei più importanti system integrator in Germania, la cui proprietà è ancora detenuta dal fondatore, con una forza lavoro di oltre 3200 talenti distribuiti in 27 uffici su tutto il territorio nazionale, che fornisce soluzioni all’avanguardia a una platea di oltre 3000 clienti. Da 10 anni, la collaborazione tra SVA e AWS si distingue per il continuo sostegno a clienti di ogni settore e ambito operativo che intendono aggiornare e migrare i propri flussi di lavoro da soluzioni in-house verso AWS, oppure, creare soluzioni ex-novo. “l’AWS European Sovereign Cloud risponde a specifiche esigenze dei clienti altamente regolamentati, contribuendo così alla riduzione delle barriere di ingresso per sbloccare il loro immenso potenziale nell’ambito digitale,” ha detto Patrik Glawe, AWS Alliance Lead presso SVA System Vertrieb Alexander GmbH. “ Potendo contare su un’ampia copertura del settore pubblico e dei settori altamente regolamentati, conosciamo alla perfezione le esigenze di chi vuole passare al cloud e stiamo lavorando per offrire a stretto giro una soluzione capace di progettare un ecosistema altamente innovativo in grado di soddisfare i più elevati standard di protezione dei dati, conformità normativa e requisiti di sovranità digitale. Il nostro lavoro avrà un impatto significativo sull’agenda di digitalizzazione dell’Unione Europea.”

Ribadiamo il nostro impegno nel garantire ai nostri clienti livelli ancora più elevati di scelta e di controllo per sfruttare al massimo i vantaggi offerti dal cloud, il tutto fornendo loro assistenza nel rispondere a specifiche esigenze in fatto di sovranità digitale, senza rinunciare a tutta la potenza di AWS. Per saperne di più sul AWS European Sovereign Cloud, consulta il sito web della Sovranità Digitale europea per non perderti gli ultimi aggiornamenti mentre proseguiamo nel nostro lavoro in vista della presentazione nel 2025.
 

Spanish version

Anuncio de los servicios disponibles inicialmente en la AWS European Sovereign Cloud, respaldada por todo el potencial de AWS

El mes pasado, compartimos nuestra decisión de invertir 7.800 millones de euros en la AWS European Sovereign Cloud, una nueva nube independiente para Europa cuyo lanzamiento está previsto para finales de 2025. Estamos diseñando la AWS European Sovereign Cloud para ofrecer más opciones a organizaciones del sector público y clientes de industrias muy reguladas contribuyendo así a cumplir tanto sus necesidades particulares de soberanía digital como los estrictos requisitos de resiliencia, autonomía operativa y residencia de datos. Los clientes y socios que usen la AWS European Sovereign Cloud se beneficiarán de la plena capacidad de AWS, incluyendo la arquitectura, la cartera de servicios, las API y las características de seguridad ya disponibles en nuestras 33 regiones de AWS. Hoy, anunciamos con entusiasmo una hoja de ruta sobre los servicios iniciales que estarán a disposición en la AWS European Sovereign Cloud. Este comunicado pone de manifiesto el gran alcance de la cartera de servicios de la AWS European Sovereign Cloud, diseñada para satisfacer la demanda de clientes y socios y, al mismo tiempo, ser fieles a nuestro compromiso de proporcionar el conjunto de funciones y controles de soberanía más avanzado que existe en la nube.

La AWS European Sovereign Cloud es construida soberana por diseño, como lo ha sido la nube de AWS desde el primer día. Hemos creado una infraestructura global segura y altamente disponible, integrado medidas de protección en nuestros mecanismos de diseño e implementación de servicios e infundido resiliencia en nuestra cultura operativa. Nuestros clientes se benefician de una nube ideada para ayudarles a satisfacer los requisitos de organizaciones que dan la máxima importancia a la seguridad. Cada región está compuesta por múltiples zonas de disponibilidad formadas a su vez por uno o más centros de datos, cada uno con potencia, conectividad y redes redundantes. La primera región de la AWS European Sovereign Cloud se ubicará en el estado federado de Brandeburgo (Alemania), con toda su infraestructura emplazada dentro de la Unión Europea (UE). Como las regiones existentes, la AWS European Sovereign Cloud funcionará gracias a la tecnología del AWS Nitro System, que es la base de todas nuestras modernas instancias de Amazon Elastic Compute Cloud (Amazon EC2) y proporciona sólida seguridad física y lógica para hacer cumplir las restricciones de modo que nadie, ni siquiera los empleados de AWS, puedan acceder a los datos de los clientes en Amazon EC2.

Hoja de ruta sobre los servicios de la AWS European Sovereign Cloud

Al lanzar una nueva región, empezamos por los servicios básicos necesarios para garantizar las aplicaciones y cargas de trabajo cruciales y, a partir de ahí, ampliamos continuamente nuestro catálogo de servicios de acuerdo con la demanda de clientes y socios. La AWS European Sovereign Cloud contará inicialmente con servicios de varias categorías, incluyendo inteligencia artificial [Amazon SageMaker, Amazon Q y Amazon Bedrock], computación [Amazon EC2 y AWS Lambda], contenedores [Amazon Elastic Kubernetes Service (Amazon EKS) y Amazon Elastic Container Service (Amazon ECS)], bases de datos [Amazon Aurora, Amazon DynamoDB y Amazon Relational Database Service (Amazon RDS)], networking [Amazon Virtual Private Cloud (Amazon VPC)], seguridad [AWS Key Management Service (AWS KMS) y AWS Private Certificate Authority] y almacenamiento [Amazon Simple Storage Service (Amazon S3) y Amazon Elastic Block Store (Amazon EBS)]. La AWS European Sovereign Cloud dispondrá de sistemas propios de administración de identidades y acceso (IAM), facturación y medición de uso operados independientemente desde las regiones existentes. Mediante dichos sistemas, los clientes que usen la Nube Soberana Europea de AWS podrán conservar todos los datos de sus propios clientes, así como los metadatos que creen (como roles, permisos, etiquetas de recursos y configuraciones para ejecutar AWS) en la UE. Los clientes que usen la AWS European Sovereign Cloud también podrán sacar partido de AWS Marketplace, un catálogo digital cuidadosamente seleccionado que facilita la búsqueda, las pruebas, la compra y la implementación de software de terceros. Para ayudar a clientes y socios a planear la implementación de la AWS European Sovereign Cloud, hemos publicado una hoja de ruta sobre los servicios iniciales al final de este artículo.

Cómo empezar a construir soberanía hoy mismo con AWS

AWS tiene el compromiso de proporcionar a los clientes el conjunto de funciones y controles de soberanía más avanzado que existe en la nube. Contamos con una amplia oferta para ayudar a cumplir necesidades particulares de soberanía digital, incluyendo nuestras seis regiones en la Unión Europea, AWS Dedicated Local Zones y AWS Outposts. La AWS European Sovereign Cloud es una opción más que se puede elegir. Es posible empezar a trabajar en nuestras regiones soberanas por diseño y, de ser necesario, realizar la migración a la AWS European Sovereign Cloud. Quien deba cumplir estrictos requisitos de aislamiento y residencia de datos a escala nacional también podrá usar Dedicated Local Zones u Outposts para implementar la infraestructura de la AWS European Sovereign Cloud en las ubicaciones seleccionadas.

Actualmente, es posible llevar a cabo pruebas de concepto y adquirir experiencia práctica para empezar con buen pie cuando se lance la AWS European Sovereign Cloud en 2025. Por ejemplo, se puede usar AWS CloudFormation para crear y aprovisionar las implementaciones de la infraestructura de AWS de forma predecible y repetida en una región existente como preparación para la AWS European Sovereign Cloud. AWS CloudFormation permite aprovechar servicios como Amazon EC2, Amazon Simple Notification Service (Amazon SNS) y Elastic Load Balancing para diseñar en la nube aplicaciones de lo más fiables, escalables y rentables de manera reproducible, auditable y automatizable. Asimismo, se puede usar Amazon SageMaker para diseñar, probar e implementar modelos de aprendizaje automático (incluyendo modelos de lenguaje grande y otros modelos fundacionales). También se puede usar Amazon S3 para beneficiarse del cifrado automático en todas las cargas de objetos. Quien tenga necesidad de almacenar y utilizar sus claves de cifrado dentro o fuera de AWS por motivos de regulación puede recurrir a External Key Store de AWS KMS.

Tanto si uno decide realizar la migración a la nube por primera vez, se plantea usar la AWS European Sovereign Cloud o desea modernizar sus aplicaciones para sacar partido de los servicios en la nube, puede beneficiarse de nuestra experiencia en ayudar a organizaciones de todos los tamaños a apostar con éxito por la nube. Ofrecemos una amplia gama de recursos para adoptar la nube de forma efectiva y acelerar el proceso de migración y modernización, incluyendo AWS Cloud Adoption Framework y Migration Acceleration Program de AWS. Nuestro programa global AWS Training and Certification ayuda a quienes están aprendiendo y a organizaciones a obtener capacidades solicitadas en el ámbito de la nube y validar su experiencia con cursos gratuitos o de bajo coste y credenciales de AWS Certification reconocidas por la industria, incluyendo más de 100 recursos de formación en materia de inteligencia artificial y aprendizaje automático.

Clientes y socios reciben con brazos abiertos la hoja de ruta sobre los servicios de la AWS European Sovereign Cloud

Adobe es el líder mundial en la creación, gestión y optimización de experiencias digitales. Durante más de doce años, la nube de AWS ha ayudado a los clientes de Adobe a usar Adobe Experience Manager (AEM) Managed Services. “A lo largo del tiempo, AEM Managed Services se ha centrado en los cuatro pilares de seguridad, privacidad, regulación y gobernanza para garantizar que los clientes de Adobe tengan a su disposición las mejores herramientas de gestión de la experiencia digital”, declaró Mitch Nelson, director senior de Servicios Administrados Mundiales en Adobe. “Nos entusiasma tanto el lanzamiento de la AWS European Sovereign Cloud como la oportunidad que ofrece de alinearse con la Single Sovereign Architecture de Adobe para la oferta de AEM. Deseamos estar entre los primeros en proporcionar la AWS European Sovereign Cloud a los clientes de Adobe.”

adesso SE es un proveedor de servicios informáticos líder en Alemania que se centra en ayudar a los clientes a optimizar los principales procesos empresariales con una infraestructura de TI moderna. adesso SE y AWS vienen colaborando para impulsar la transformación digital de las organizaciones de forma rápida y eficiente mediante soluciones personalizadas. “Con la nube soberana europea, AWS ofrece otra opción que puede ayudar a los clientes a lidiar con la complejidad de los cambios en normas y reglamentos. Varias organizaciones del sector público e industrias reguladas ya usan la nube de AWS para cumplir sus requisitos de soberanía digital, y la AWS European Sovereign Cloud proporcionará oportunidades adicionales”, afirmó Markus Ostertag, responsable de tecnología de AWS en adesso SE. “Como uno de los proveedores de servicios informáticos más importantes de Alemania, somos conscientes de los beneficios que aportará la cartera de servicios de la Nube Soberana Europea a la hora de ayudar a los clientes a innovar y, al mismo tiempo, obtener la fiabilidad, resiliencia y disponibilidad que necesitan. AWS y adesso SE comparten el compromiso mutuo de satisfacer las necesidades particulares de los clientes y deseamos seguir ayudando a avanzar a organizaciones de toda la UE”.

Genesys, líder mundial en orquestación de experiencias impulsadas por la inteligencia artificial, ayuda a más de 8000 organizaciones en más de 100 países a proporcionar una experiencia end-to-end personalizada a escala. Al combinar Genesys Cloud con AWS, las compañías mantienen su larga colaboración para ofrecer servicios escalables, seguros e innovadores a una clientela global común. “Genesys está a la vanguardia cuando se trata de ayudar a las empresas a usar la inteligencia artificial para fidelizar a los clientes y fomentar la productividad y el compromiso de los empleados”, declaró Glenn Nethercutt, director tecnológico en Genesys. “Integrar la plataforma Genesys Cloud en la AWS European Sovereign Cloud permitirá que aún más organizaciones europeas diseñen, prueben e implementen aplicaciones de experiencia del cliente punteras y, al mismo tiempo, cumplan los estrictos requisitos de regulación y soberanía de datos. Europa desempeña un papel clave en la economía global y da ejemplo en materia de estándares de protección de datos; en el momento de su lanzamiento, la AWS European Sovereign Cloud ofrecerá un completo paquete de servicios para ayudar a las empresas a cumplir los requisitos de regulación y privacidad de datos. Esta colaboración reafirma nuestra continua inversión en la región, y Genesys y AWS mantienen el compromiso de trabajar juntos para abordar los desafíos únicos que afrontan las empresas europeas, especialmente aquellas que operan en industrias muy reguladas, como la financiera y la sanitaria”.

Pega proporciona una potente plataforma que permite que los clientes internacionales usen nuestras soluciones de automatización de flujos de trabajo y toma de decisiones basadas en la inteligencia artificial para resolver sus retos empresariales más urgentes, desde la personalización del compromiso hasta la automatización del servicio y la optimización de las operaciones. El estratégico trabajo de Pega con AWS ha favorecido la transformación de su modelo de negocio como servicio para que constituya una forma extremadamente escalable, fiable y ágil de poner la plataforma de Pega a disposición de nuestros clientes a escala global. “La colaboración entre AWS y Pega reforzará nuestro compromiso con los clientes de la Unión Europea de almacenar y procesar sus datos dentro de la región”, aseguró Frank Guerrera, director técnico de sistemas en Pegasystems. “Nuestra solución combinada, aprovechando la AWS European Sovereign Cloud, permitirá que Pega ofrezca garantías de soberanía en todos los niveles del servicio, desde la plataforma y las tecnologías de soporte hasta la infraestructura básica. Esta solución aúna el estricto enfoque de Pega Cloud sobre los procesos, las personas y el aislamiento de datos con la nueva e innovadora Nube Soberana Europea de AWS para ofrecer flexibilidad a nuestros clientes del sector público e industrias muy reguladas”.

SVA System Vertrieb Alexander GmbH, propiedad del fundador, es un integrador de sistemas líder en Alemania, con más de 3200 empleados y 27 oficinas distribuidas por el país, que ofrece soluciones sin parangón a más de 3000 clientes. La colaboración entre SVA y AWS, iniciada hace 10 años, ha permitido ayudar a clientes de diferentes industrias y verticales a modernizar las cargas de trabajo y realizar su migración a AWS o a diseñar nuevas soluciones desde cero. “La AWS European Sovereign Cloud aborda necesidades específicas de clientes sometidos a una elevada regulación, puede eliminar barreras y liberar un enorme potencial de digitalización para estas verticales”, comentó Patrick Glawe, responsable de AWS Alliance en SVA System Vertrieb Alexander GmbH. Debido a nuestro amplio alcance en el sector público e industrias reguladas, seguimos atentamente los debates sobre la adopción de la nube y pronto ofreceremos la opción de diseñar un ecosistema extremadamente innovador que se ajuste a los estándares más altos en materia de protección de datos, cumplimiento normativo y soberanía digital. Esto ejercerá un gran impacto en la agenda de digitalización de la Unión Europea”.

Reafirmamos nuestro compromiso de ofrecer a los clientes más control y opciones para sacar provecho de la innovación que ofrece la nube y, al mismo tiempo, ayudarlos a cumplir sus necesidades particulares de soberanía digital sin poner en riesgo todo el potencial de AWS. En nuestro sitio web de soberanía digital en Europa ofrecemos más información sobre la AWS European Sovereign Cloud. Asimismo, invitamos a todos los interesados a seguir atentamente nuestras próximas noticias de cara al lanzamiento de 2025.
 

Max Peterson

Max Peterson
Max is the Vice President of AWS Sovereign Cloud. He leads efforts to ensure that all AWS customers around the world have the most advanced set of sovereignty controls, privacy safeguards, and security features available in the cloud. Before his current role, Max served as the VP of AWS Worldwide Public Sector (WWPS) and created and led the WWPS International Sales division, with a focus on empowering government, education, healthcare, aerospace and satellite, and nonprofit organizations to drive rapid innovation while meeting evolving compliance, security, and policy requirements. Max has over 30 years of public sector experience and served in other technology leadership roles before joining Amazon. Max has earned both a Bachelor of Arts in Finance and Master of Business Administration in Management Information Systems from the University of Maryland.

[$] Mount notifications

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

There are a handful of extensions to the “new” mount API that Christian
Brauner wanted to discuss as part of a filesystem session at
the
2024 Linux Storage,
Filesystem, Memory Management, and BPF Summit. In the session, though,
the only one that he got to was a followup to last year’s discussion on mount-operation monitoring.
There is a need for user-space programs to be able to follow mount
operations (e.g. mount and unmount) that happen in the system, especially
for tools like container
managers or systemd.