User namespaces are a key part of the
kernel’s toolkit for assembling containers; processes within a user
namespace can appear to have full root access to the system while gaining
no extra privileges in the wider system. At least, that is the intent. In
practice, keeping privilege contained within a user namespace has often
turned out to be difficult. As an example, consider this
small patch series from Josef Bacik, which is intended to address some
situations where a process within a user namespace can elevate the
privileges of processes outside of it.
In this 34th quarterly recap post, discover the most impactful AWS serverless launches, features, and resources from Q3 2026 that you might have missed.
In case you missed our last ICYMI, read about what happened in Q2 2026.
Figure 1: 2026 Q3 calendar
Amazon EventBridge
Amazon EventBridgerelaunched the Custom event bus for organizations where many teams share events. A central team creates one bus, shares it across accounts with AWS Resource Access Manager, and controls who can publish and subscribe. Application teams create Subscribers in their own accounts instead of chaining forwarding rules between buses. The new bus keeps events for a retention period you choose, preserves order within a key the publisher sets, and accepts Avro, Protocol Buffers, and JSON, including CloudEvents. It runs alongside the classic bus, so adoption is incremental.
Figure 2: Shared Custom event bus with subscribers in team accounts
AWS Lambda functions outside an Amazon Virtual Private Cloud (VPC) with 2 GB of memory or more now get scalable network bandwidth. The bandwidth increases from 625 Mbps at 2 GB up to 3,000 Mbps at 10 GB. Functions that pull large amounts of data from Amazon S3 or external sources finish sooner, as the ETL fan-out pattern in the post shows.
SnapStart now supports container images, cutting startup for larger images from several seconds to as low as sub-second. Provisioned mode for Amazon Simple Queue Service (Amazon SQS) event source mappings now scales to 10,000 event pollers, five times the previous limit, for up to 100,000 concurrent invocations. Lambda can also read function code from your own S3 bucket. Lambda skips copying the package to its own storage, so code storage quotas stop being a concern and functions activate faster after updates.
Running self-hosted AI agent sandboxes gives every agent session its own MicroVM in your account, with separate credentials, file system, and network boundary. Each MicroVM launches from a pre-captured snapshot, so new sessions skip application initialization.
Figure 4: Self-hosted agent sandboxes on AWS Lambda MicroVMs architecture
The new AgentCore runtime, a capability of Amazon Bedrock AgentCore, reclaims unused memory during a session, so you pay for what you use, and keeps cold starts consistent. Runtime instances run agents on Amazon EC2 instance types you choose, much as Lambda Managed Instances does for functions. AgentCore payments, a capability of Amazon Bedrock AgentCore, is generally available, and temporal policies authorize tool calls based on what the agent already did in the session.
Strands harness is an open source, general-purpose agent you start with one line of Python or TypeScript and run locally or deploy anywhere. Across six benchmarks using the same models, it cost 28% less than other popular harnesses with similar accuracy, mostly because of its default context management. Harness Optimizer tunes prompts, tool descriptions, and skills automatically, strands-dynamodb-storage adds durable agent storage on Amazon DynamoDB, and Strands Evals now evaluates agents built with other frameworks.
Kiro
Figure 6: Kiro Crew session view
Kiro Crew is an open source workspace that runs agent work across sessions, schedules, and subagents from a desktop app, web dashboard, or terminal. Kiro on the web is generally available, cloud sessions keep CLI and IDE tasks running after you close your laptop, and workflows run multi-step plans across several agents in the background.
Serverless blog posts
Here are the Q3 2026 serverless blog posts, grouped by the month they published.
The Serverless landing page has overall information about building serverless applications. The Lambda resources page contains case studies, webinars, whitepapers, customer stories, reference architectures, and even more Getting Started tutorials.
You can also follow the Developer Advocacy team to get the latest news, follow conversations, and interact with the team.
Version 10.6p2 of
OpenSSH has been released with a workaround for a critical vulnerability that
affects Linux systems that use musl libc
with PAM disabled, such as Alpine
Linux. OpenSSH developer Damien Miller said:
If you operate a Linux system that uses musl libc without PAM (Alpine Linux
is one example) then stop reading and set PasswordAuthentication=no or disable
SSH for these systems IMMEDIATELY.
This vulnerability does not exist on non-Linux systems, Linux/glibc systems
and Linux systems that use PAM for password authentication.
We consider the root cause of this bug to be outside OpenSSH itself, but
we’re in a good position to deliver a mitigation quickly.
The Alpine Linux project has announced that
it will be backporting the OpenSSH fix “all the way back to Alpine 3.16“,
which was released in May
2022.
Вече действително си имаме президентка. Ако доскоро Илияна Йотова заемаше поста на държавния глава само защото Румен Радев го напусна, за да стане премиер, на 1 ноември 2026 г. тя стана първата жена в България, избрана за президент. Следва да отбележим: това се случи, преди „стъкленият таван“ в политиката да е строшен в държави като САЩ и Германия, да не говорим за Русия. Ниската избирателна активност не прави Йотова по-малко президент – такива са изборните правила и те са спазени.
Според данни от екзитполове за нея са гласували повече жени, отколкото мъже. Тези данни следва да се приемат с едно наум поради сериозното разминаване между резултатите от екзитполовете и от изборите, но с друга информация за профилите на гласувалите, за съжаление, не разполагаме. И все пак, тъй като профилите на гласоподавателите по пол и възраст са аналогични на тези от първия тур, може да предположим, че са по-скоро коректни.
Ала фактът, че жена е избрана за президент, добра новина ли е за жените в България?
Жени антифеминистки в българската политика
Наличието на жени в политиката само по себе си не означава феминизъм. Ето няколко от многото примери за антифеминистки позиции на жени в българската политика:
През 1997 г. се учредява Партията на българските жени (ПБЖ).
През 2001 г. партията, чиято председателка е Весела Драганова, става мандатоносител на политическия проект на бившия цар Симеон Сакскобургготски, през 2024 г. – на проекта на бившия главен прокурор Иван Гешев, а междувременно е участвала във всевъзможни коалиции. Ето едно от основните неща, с които ПБЖ намира за нужно да се представи (оригиналният правопис е запазен):
Въпреки наименованието: Партия на българските жени, идеите не са феминистки, а в традициите на християнството, защитавайки изконните български ценности – родина, дом, семейство, деца, духовни традиции – ценности, чиито най-голям радетел е била и е българската майка.
Настоящата председателка на парламента Михаела Доцова също държи да се знае, че не е феминистка.
Тя споделя това в началото на април 2026 г., когато още е кандидат-депутатка от „Прогресивна България“, в интервю на Мартин Богданов, по-известен с псевдонима Карбовски. Думите на Доцова предизвикаха реакции, след като тя застана начело на Народното събрание, заради един очевиден парадокс. Жена, заела един от най-високите постове в България в резултат на това, че жени преди нея са се преборили първо за правото си да избират, а след това и за правото да бъдат избирани, не се идентифицира с отстояването на равни права от страна на жените.
Но едва ли някоя жена е навредила през последните десетилетия повече на правата на жените в България от бившата председателка на БСП Корнелия Нинова.
Никоя от родните уонаби традсъпруги не може да стъпи на малкия ѝ пръст в това отношение. Борбата на Нинова срещу Конвенцията на Съвета на Европа за превенция и борба с насилието над жени и домашното насилие (Истанбулската конвенция) допринесе за връщането на еманципацията на жените в България с десетилетия назад. Не толкова заради омаловажаването на проблема с домашното насилие, от което потърпевши са най-вече жените, а основно заради отрицанието на социалната значимост на пола.
След успеха на кампанията срещу Истанбулската конвенция вече официално (бетонирано и от Конституционния съд) единствената социална роля на жената е в биологичното ѝ възпроизводство – тоест да бъде майка.
За близо десетте си години в Президентството Илияна Йотова би могла да овластява жените в България, като бъде техният глас. Би могла например да популяризира трудовите и социалните права на майките, които не се познават добре. Или Директивата на ЕС за равно заплащане на мъжете и жените за равен труд. За тази директива, чиято цел е да се осигури прозрачност в заплащането, в България почти не се говореше, преди тя да бъде въведена на 7 юни 2026 г.
Йотова би могла и да възрази на оттеглянето на България от Истанбулската конвенция. Впрочем тя първоначално го направи – на форум за правата на жените разкритикува оттеглянето от Конвенцията. Но скоро след това зае „мултивекторна“ – казано с терминологията на „Прогресивна България“ – позиция по въпроса. Тоест си изми ръцете като Пилат Понтийски, обявявайки се за референдум за Конвенцията. После гласът ѝ по темата напълно заглъхна.
Но през десетте си години в Президентството Йотова не акцентира върху пола си.
С оглед на политическата ѝ кариера стратегията на тази линия на поведение е печеливша. За да стане първата жена, избрана за президент в държава, в която единствената социална роля на жената по конституция е да бъде майка, желателно е да не насочва общественото внимание върху факта, че е жена.
Впрочем единственият път по време на дебата между нея и Андрей Гюров, когато тя се идентифицира с пола си, беше в конституционно „правилния“ контекст – изтъкна, че е майка и баба.
В последно време се наблюдава промяна в единствената характеристика на Йотова, подчертаваща женствеността ѝ – буйната коса. Вече няколко пъти, например на дебата с Гюров и на пресконференцията след победата на втория тур, косата ѝ е частично прибрана назад, което разкрива лицето ѝ, но ѝ придава и по-строг вид.
Между Харис и Йотова обаче има поне две ключови разлики.
Първо, Илияна Йотова се кандидатира за президентския пост скоро след като Румен Радев взе властта, така че можа да се възползва от инерцията от победата на „Прогресивна България“. А Камала Харис се кандидатира в период, когато неодобрението към Джо Байдън беше много високо.
Второ, въпреки че Харис беше в по-лоша изходна позиция от Йотова, правата на жените бяха сред основните теми в кампанията ѝ. Особено репродуктивните права, защото две години по-рано Върховният съд на САЩ прие решение, според което правото на аборт вече не е защитено от Конституцията. Илияна Йотова не само не се застъпва за правата на жените, а и
участва в своеобразно легитимиране на мизогинията.
Тя отказа да даде интервю на множество авторитетни медии, например CNN, но пък даде на Мартин Карбовски (в комбинация с Явор Дачков). Карбовски (както и Дачков), при когото се изредиха и много от политиците на „Прогресивна България“, от години е ретранслатор на пропутински опорни точки и се е превърнал в своеобразна трибуна на новата власт. Морализаторският му патос и позициите му в защита на „традиционните ценности“ обаче са в странен дисонанс с контракултурния му образ в миналото, чиято бунтарщина се изразява не на последно място в откровена мизогиния.
Есето на Карбовски Rape Party, публикувано в „Егоист“ в края на 90-те например, е посветено на „рейпването“ (изнасилването). В него авторът, който пише от свое име, а не от това на литературен герой, нормализира сексуалното насилие над жени:
Всеки мъж е опитвал да рейпва – най-малкото заради алкохол или поне защото Кърт Кобейн и Слави Трифонов пеят подобни песни. Аз съм се опитвал да насилвам жена два пъти.
Следват детайлни описания как точно е опитвал и защо не е успял, а за „утеха на феминистите и феминистките“ следва да послужи признанието, че „синините на сутринта по мене и по нея бяха равен брой“. Не става ясно дали според автора „феминистите и феминистките“ трябва да се чувстват спокойни и от това твърдение (оригиналният правопис е запазен):
… една жена трябва да бъде смляна от бой, съсипана психически или заплашена с пистолет, за да успее жалката мъжка технология на изнасилването. Жените са яки в бедрата, гъвкави са, умеят да се извиват и гърчат, юмруците и ноктите им не са за подценяване, ритниците им са страшно оръжие. А и основния проблем на мъжете е, че женските полови органи са вътре в тялото на жената и ако някой много мърда е трудно да уцелиш дупката.
Дори обаче да приемем, че това есе е просто литература, опитите на Карбовски да оневини мъж, изнасилил и убил жена, са реални. Става въпрос за убийството на Яна Кръстева в Борисовата градина през 2011 г. За него беше обвинен Николай Русинов – Чеци, впоследствие и осъден. Но междувременно Карбовски му даде трибуна, свидетелства в негова подкрепа в съда и тиражира версия, че клошарят Пламен Трифонов е убил младата жена. Поради това Трифонов, който за разлика от Чеци нямаше защитаващи го приятели, също беше обвиняем.
През 2020 г. пък дизайнерката Миглена Каканашева – Мегз обвини Карбовски, че я е изнудвал, за да прави секс с него, и публикува техни чатове за доказателство. Впоследствие той осъди ПИК за обиди по негов адрес по този повод, но твърденията му за клевета не бяха приети от съда.
При същия човек отива да дава интервю Илияна Йотова.
Илияна Йотова не изтъква пола си, но по време на дебата с Андрей Гюров на три пъти произвежда мелодрама.
Епизод 1 – болното дете
В отговор на упрека на Андрей Гюров, че е помилвала наркотрафиканти, Йотова дава пример за помилван от нея баща на болно дете, „което не може да приеме храна от никой друг, освен от своя баща“. И задава реторичния въпрос: „Вие как бихте постъпили в тази ситуация?“.
Да допуснем, че е вярна информацията, че мъжът е отглеждал детето си сам, а то е с аутизъм и отсъствието на баща му поставя живота му под риск, и затова Йотова е постъпила правилно в този случай. Това обаче не е оправдание за помилването на хора като Огнян Атанасов – Петричкия Ескобар и Динко Господинов – Лудия. Нито рискът за това дете е по-голям от риска за всички деца в България, които разполагат с лесен достъп до наркотици.
Представете си шофьор, обвинен, че е причинил катастрофа, в която са пострадали хора, да се оправдава в съда със следния аргумент: „Но пък веднъж качих в колата си дете, което се прибираше самичко в бурята, и го закарах до вкъщи. Вие как бихте постъпили в тази ситуация – ще го оставите ли да загине?“. Същата стойност има и оправданието на Йотова.
Епизод 2 – убитият баща
На въпрос на водещата кой е най-близкият ѝ човек, Илияна Йотова отговаря, че това е майка ѝ. Водещата явно решава, че отговорът е даден, и се опитва да продължи с въпросите, но Йотова настоява да обясни защо точно майка ѝ е най-близкият ѝ човек:
Твърде рано убиха баща ми, иначе беше той.
Така зрителите, които досега не са знаели този факт, научават, че бащата на президентката е бил убит, когато тя е била млада. Тази информация предизвиква и съчувствие, и любопитство, изобщо допринася за възприемането на опонентката на Гюров като човешко същество.
На заден план остава проблемът с отношението към майката, който следва от тази реплика – излиза, че според Йотова тя е най-близкият ѝ човек не защото притежава някакви качества, а поради липсата на бащата.
Епизод 3 (всъщност цяла сапунена опера) – „не закачайте семейството ми“
В края на панела от дебата, в който кандидат-президентите задават въпроси един на друг, Йотова формулира следното питане към Гюров:
Оставих последния си въпрос към г-н Гюров от човешката страна. Искам да Ви попитам, така, както сме работили, познаваме се, както изкарахме сега една много трудна кампания, по начина, по който тя беше проведена – с демагогия, с лъжи, с лични нападки, с тежки квалификации, през тролове, през елфи, през каквото се сетите, с това, че накарахте медии да посегнат на съпруга ми… Вие лично […] Аз Ви питам като човек, Вас лично – Вие съгласен ли сте с такава кампания?
Видимо обърканият Андрей Гюров, който вероятно не разбира какво има предвид опонентката му, отговаря с общи фрази в смисъл, че той и екипът му са водили позитивна кампания и не са си позволявали лични нападки. По-късно обаче, в самия край на дебата, когато вече няма възможност опонентът ѝ да реагира, Йотова се връща към темата и заявява:
Господин Гюров, моля Ви, не закачайте семейството ми. Защото разбрах, че кампанията, която проведохте срещу мен, Ви харесва и я одобрявате.
Съпругът на Илияна Йотова е в процес на възстановяване след прекарано тежко заболяване и трудно се придвижва. С твърденията си Йотова внушава, че Гюров е лично отговорен за това медии, неясно как, да посягат на мъжа ѝ и/или на цялото ѝ семейство.
Действителната история е съвсем различна. Всъщност история дори няма.
Влогърът Николай Караколев задава въпроси на Илияна Йотова и я снима, докато тя отива да гласува с мъжа си, който се придвижва с бастун. Тя охотно му отговаря, но на моменти видимо се притеснява как ще мине съпругът ѝ, и моли да му се направи път. Караколев в нито един момент от записа не се обръща към него, не му „посяга“ и не го „закача“ по никакъв начин. Може би Йотова интерпретира като посегателство срещу семейството си факта, че мъжът ѝ изобщо е сниман, но тя не отказва на Караколев интервюто.
Самият Караколев реагира с ироничен коментар: „Последно кой при кого ме е пратил???“, споделяйки видео, в което наред с призива на Йотова „не закачайте семейството ми“ се показва как той обвинява Гюров и Кандев в редица грехове.
Ще се еманципира ли Йотова от Радев?
Ако предизборната кампания разкри нещо за личността на Илияна Йотова, то е, че тя много добре знае в какви случаи как да се държи, но и че не се спира пред нищо, за да постигне целите си. Друг въпрос е, че за постигането на тези цели тя с лека ръка жертва истината, а и националните интереси.
В продължение на 10 години Йотова стои в сянката на Румен Радев, излъчва безличност и търпеливо чака да дойде нейният ред. Радев продължава да се държи, все едно ѝ е шеф. Пристигайки на пресконференцията след победата ѝ на втория тур, той вървеше няколко метра пред нея – ако човек не знаеше кой е спечелил изборите, щеше да помисли, че е Радев.
Постът на премиера обаче е по-проветрив от този на президента. Президентите в България се избират веднъж на пет години, премиерите – на четири (ако изобщо изкарат пълен мандат). Министър-председателите търпят повече критика и срещу управлението им се провеждат повече протести, като в резултат на някои от тях понякога падат правителства. В България обаче не само няма случай президент да бъде свален заради обществено недоволство, ами по правило държавният глава има най-висок рейтинг сред публичните личности.
С други думи, Йотова вече е над Радев, макар той да не дава вид, че осъзнава това.
Ако премиерът продължава да се държи с нея като с подчинена, тя може да реши да покаже къде му е мястото, и между тях да настъпи разкол. Такъв сценарий едва ли би променил възгледите на президентката за геополитическата ориентация, които вероятно са по-искрено проруски от тези на Радев – все пак тя идва от средите на БСП. Но евентуално напрежение между „Дондуков“ 2 и „Дондуков“ 1 може да отслаби властта на „Прогресивна България“.
Конфронтацията между президент и премиер, дори когато са от една политическа сила, има традиция. За това допринася и конституционната роля на президента, която го позиционира като независим от партиите, помогнали му да дойде на власт.
Началото беше положено от Жельо Желев, чиято пресконференция, останала в историята като „Боянските ливади“, доведе до падането от власт на правителството на Филип Димитров. Отношенията между Иван Костов и Петър Стоянов също се обтегнаха, а кулминация на напрежението между тях беше репликата на тогавашния президент „Иване, кажи си“.
Йотова не прилича на човек с мек нрав, така че разривът между нея и Радев вероятно е въпрос на време. Дали в резултат на евентуален такъв разрив президентката би се опитала да капитализира политически факта, че е жена, е друг въпрос. Ако може да извлече дивиденти от това, без да накриви шапката на Москва, защо не?
Независимо от личността, ценностите, делата и външнополитическата ориентация на Йотова
фактът, че в България за първи път е избрана президентка, сам по себе си е добра новина.
Това означава, че в бъдеще ще е възможно и други жени да заемат този пост. Някой ден на него може да застане жена, която я е грижа за правата на жените. Само дано днешните момичета, които един ден ще могат да се кандидатират за държавен глава, да имат опит какво е да живееш в свобода и да са наясно какво означават равни права.
Earlier this year, we announced that we’re expanding Experience AI, our AI literacy programme, across Latin America to bring AI education to nine more countries through support from Google.org. Working with local partner organisations, we offer Experience AI training and resources that teachers can use to enable young people to learn a foundational understanding of AI technologies, their social and ethical implications, and the role that AI can play in their lives.
Over the past few months, Experience AI launch events have already taken place in Brazil, Chile, Argentina, and Mexico. At every event, we met educators, policymakers, universities, non-profit organisations, and technology leaders and explored how AI literacy can become part of classrooms across their country. Experience AI brought us all together around a shared goal: giving teachers the confidence and resources they need to help young people understand and engage with AI critically and responsibly.
Growing the Experience AI partner network in Latin America
Across Latin America, the local organisations we are partnering with to implement Experience AI bring deep expertise in teacher professional development and education. Partners include Fundación Sadosky in Argentina, Fundación Kodea in Chile, Sincroniza Educação in Brazil, and Educación para Compartir in Mexico.
Each partner is implementing the programme in a way that reflects its local education system and context. We work with them individually and also facilitate their collaboration around shared challenges.
A delivery model designed for lasting impact across Argentina
In Argentina, Experience AI was officially launched in June during a Google event in Buenos Aires.
Our Argentinian partner Fundación Sadosky is taking a distinctive approach to Experience AI teacher professional development by working through a network of public universities across the country, rather than relying on a central training team. Through this approach, Experience AI training will reach educators in diverse regions across the country as Fundación Sadosky builds on local expertise and existing educational networks.
Growing local capacity and developing regional trainers means Experience AI will make a lasting impact for teachers and learners, enabling high-quality AI education long after the programme’s first rollout.
The first cohort of participating universities is now working with teachers across several Argentinian provinces, before the programme expands nationwide. When fully established, Experience AI aims to support around 1,700 secondary school teachers and reach an estimated 153,000 students across Argentina.
Turning vision into action
It’s been very rewarding coming together with local partners, Google.org, universities, and education communities across Latin America around our shared vision of high-quality AI education for all young people.
After the launch events, the focus now turns to practical action: supporting teachers and bringing Experience AI into classrooms across the region.
As the programme grows, we also look forward to working with new partners across Latin America to bring AI literacy to even more educators and young people. By 2028, we and our Latin American partners aim to support 24,000 more educators and reach more than 1.25 million young people through Experience AI.
Sovereign Tech Agency is investing in the development of a Merkle Tree Certificate Authority at Let’s Encrypt through the end of 2027 with a contract totaling more than €1M. This is the largest single investment in post-quantum readiness at Let’s Encrypt to date. This investment will help pave the path for free post-quantum Merkle Tree Certificates for people globally.
Every time you open your bank, your tax portal, or your medical records, a certificate confirms you reached the website you typed in. Quantum computers put that confirmation at risk. Whether the web stays trustworthy shouldn’t depend on who can afford to upgrade first. With ISRG, we invest in making post-quantum security the default for everyone, built on open standards and open source software.
Merkle Tree Certificates
Merkle Tree Certificates are a new approach that adds post-quantum authentication to the web without sacrificing the speed and reliability that have made TLS universal. Replacing today’s certificate signatures with post-quantum equivalents would push a single TLS handshake well past 10 kilobytes, slowing connections and causing some to fail; MTCs keep the handshake small by covering a whole batch of certificates with one signature.
This investment supports ISRG’s efforts to prepare Let’s Encrypt for the post-quantum era by researching, developing, and deploying post-quantum Merkle Tree Certificates across its Certificate Authority infrastructure. Through 2027, this initiative will help ISRG:
Contribute to standardization of Merkle Tree Certificate Authorities at the IETF, the body that develops the Internet’s technical standards; in C2SP, a community project that publishes precise specifications for cryptographic protocols; and with root programs, the policies that decide which certificate authorities browsers and operating systems trust.
Transition the Merkle Tree Certificate Authority from initial standardization and staging tests to a fully reliable, compliant production launch.
Develop documentation, conduct outreach, and roll out Merkle Tree Certificates globally to subscribers.
We applaud the Sovereign Tech Agency and the German Federal Ministry for Digital Transformation and Government Modernisation for recognizing the connection between strong, well-supported digital infrastructure and innovation and economic growth.
With better and more secure tools people, companies, and institutions can focus more on the task at hand. We hope to see more public and private organizations who rely on open source critical digital infrastructure to step up and support it. If you or your organization would like to come on board as a funder of ISRG, we would be excited to begin a conversation with you at [email protected].
Today, we’re announcing a simple, cost-effective path for data lake modernization. Amazon S3 Tables now support managed migration of your Apache Hive tables to Apache Iceberg. Migration works with Parquet tables in Amazon S3 that are registered in the AWS Glue Data Catalog and allows you to upgrade your data lake with no pipelines to build or compute to provision, while production workloads keep running.
Apache Iceberg has become the open standard for large analytics datasets. It lets you manage petabyte-scale tables with features like schema evolution, hidden partitioning, and time travel queries, while keeping your data open and queryable with any Iceberg-compatible engine. Amazon S3 Tables offer fully managed storage purpose-built to keep Iceberg tables performant and cost-effective as they grow, with features like automatic maintenance, optimization, replication, and S3 Intelligent-Tiering built-in.
What is new Previously, migrating Apache Hive tables to Apache Iceberg could take weeks of engineering work to build and manage the required infrastructure. Converting data types and building rollback capabilities added operational complexity. Now, this is available as a managed, API-driven operation.
S3 Tables handle the entire migration workflow, including data validation, compatibility checks, type conversions, file recompression, and compaction. Before copying any data, S3 Tables identify every source object in scope and generate a compatibility report. You can sync as many times as you need without stopping writes to your source table, except for a few minutes during cutover. Once you are ready, you can complete the migration, minimizing time that tables are offline.
Compared to self-managed approaches, S3 Tables managed migrations are cost-effective because you pay only for the data copied, with no charge for the Hive-to-Iceberg conversion, and source objects in S3 Intelligent-Tiering stay in their current access tier.
A first look at the migration To migrate an AWS Glue Hive table, choose your destination table bucket in the S3 console, then choose Create table from migration.
Create a namespace and table name for your destination Iceberg table. The destination table is created using recommended default settings tuned for query performance and storage efficiency.
When you start the migration, S3 Tables validate the source table, generate a compatibility report, and begin copying data. The destination table is read-only during the migration. Once you complete migration, the destination table is promoted to read-write.
To catch up the destination table with changes in the source, call sync-table-migration as many times as you need before you complete the migration. Each sync copies only what changed.
If you’re using coding agents like Kiro, the migrating-hive-tables-to-s3-tables skill in the Agent Toolkit for AWS provides step-by-step migration guidance with safety guardrails for agents. The skill can:
Analyze existing IAM policies and recommend equivalent destination policies
Validate the migration plan before getting started
Execute the Start → Sync → Complete API calls
Monitor job progress and guide validation and cutover
Now available Amazon S3 Tables managed migration is available today in US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland, Stockholm) Regions. At launch, the capability supports AWS Glue-registered Hive tables stored in Parquet format within the same AWS account and AWS Region. If you want to call APIs, search documentation, find regional availability, or troubleshoot about this new feature, try using the AWS MCP Server and plugins with your preferred AI tool.
Organizations in regulated industries such as healthcare, financial services, and government often face strict data residency mandates that require all data, including database backups, to remain within their on-premises environment. You can keep backups on-premises with Amazon Relational Database Service (Amazon RDS) local backups on AWS Outposts by setting the backup target to AWS Outposts (--backup-target outposts). Your AWS Outposts must have Amazon Simple Storage Service (Amazon S3) on Outposts capacity to store those backups locally. While Amazon RDS local backups on Outposts can keep backup data on-premises, organizations that need high availability across two separate Outposts racks, without any data traversing the AWS Region, lack a built-in, native replication mechanism between Outpost-hosted RDS instances.
In this post, we demonstrate how you can configure PostgreSQL logical replication between two Amazon RDS instances running on separate AWS Outposts racks, so that all data remains within your on-premises environment. By using Customer-owned IP addresses (CoIP) and Local Gateways (LGW), you can establish secure, low-latency replication between Outposts without exposing any data to the Region.
Architecture overview
Our solution uses two AWS Outpost racks, each with its own Local Gateway (LGW) configured in Customer-owned IP (CoIP) mode. In this architecture, all database traffic flows through your on-premises network infrastructure:
Figure 1: Replication architecture across two AWS Outposts racks using Customer-owned IP addresses and Local Gateways
Prerequisites
Before beginning the configuration, make sure you have:
Two AWS Outpost racks with Local Gateways (LGW) configured in CoIP mode.
CoIP pools configured and shared with your AWS account.
LGW route table associations with your virtual private cloud (VPC) in place.
On-premises network connectivity between the two Outpost Local Gateways.
VPC with subnets spanning both Outposts.
Security groups configured to allow PostgreSQL traffic (port 5432).
Step 1: Create Outpost subnets with CoIP configuration
Each Outpost needs a subnet with CoIP auto-assign enabled.
While Amazon Elastic Compute Cloud (Amazon EC2) instances can inherit CoIP assignment from subnet settings, RDS instances require explicit CoIP enablement (covered in Step 3).
Important: The MapCustomerOwnedIpOnLaunch setting works for EC2 instances but doesn’t automatically apply to RDS instances. RDS requires explicit CoIP enablement during instance creation.
Create DB subnet group
Create a DB subnet group spanning both Outposts:
aws rds create-db-subnet-group \
--db-subnet-group-name rds-outposts-subnet-group \
--db-subnet-group-description "Subnet group spanning Outpost A and B" \
--subnet-ids subnet-outpost-a subnet-outpost-b
Step 2: Configure route tables for cross-Outpost communication
This configuration step is often overlooked. Each subnet’s route table requires two Local Gateway routes:
Cross-outpost route: To reach the other Outpost’s CoIP range.
Same-outpost hairpin route: To reach its own CoIP range, which is required because RDS DNS resolves to CoIP. This affects any resource on the subnet that needs to reach the RDS instance by endpoint, including Amazon EC2 application servers on the same Outpost.
Why the hairpin route is important
When you enable CoIP on RDS, the DNS endpoint resolves to the CoIP address instead of the private IP. EC2 instances (and other RDS instances) on the same subnet need a route through the LGW to reach CoIP addresses, even for same-Outpost traffic. Without the hairpin route, traffic to the local CoIP range matches the default route (NAT gateway or internet gateway) and is lost.
In this step, you create the Amazon RDS for PostgreSQL instances on each Outpost using the aws rds create-db-instance CLI command. CoIP provides local or external connectivity to resources in your Outpost subnets through your on-premises network. It provides lower latency for connections to the DB instance from outside of its VPC on your local network. When you create an Amazon RDS instance on an Outpost, you can enable CoIP to make sure the instance is reachable over your on-premises network through the Local Gateway rather than the Region.
The --enable-customer-owned-ip flag must be explicitly set. RDS doesn’t inherit the subnet’s MapCustomerOwnedIpOnLaunch setting.
Keep in mind that this property isn’t supported in AWS CloudFormation. Use the AWS Command Line Interface (AWS CLI), Terraform (customer_owned_ip_enabled = true), or the console (select Customer-owned IP address (CoIP) under Access type).
This automatically sets wal_level = logical, so PostgreSQL can capture the necessary change data for replication.
Create replication user and publication on the publisher
Connect to the publisher instance and execute:
-- Create a replication user
CREATE USER repluser WITH REPLICATION LOGIN PASSWORD 'YourStrongPassword';
-- Grant SELECT on tables to replicate (required for initial COPY)
GRANT SELECT ON ALL TABLES IN SCHEMA public TO repluser;
-- Create table to replicate (example: healthcare appointments)
CREATE TABLE patient_appointments (
appointment_id SERIAL PRIMARY KEY,
patient_id INTEGER NOT NULL,
patient_name VARCHAR(100), -- PHI: can be excluded from replication
ssn VARCHAR(11), -- PHI: can be excluded from replication
date_of_birth DATE, -- PHI: can be excluded from replication
diagnosis_code VARCHAR(10), -- PHI: can be excluded from replication
appointment_date DATE NOT NULL,
doctor_id INTEGER NOT NULL,
department VARCHAR(50),
billing_amount DECIMAL(10,2),
procedure_code VARCHAR(10),
visit_type VARCHAR(20)
);
-- Create a publication for the table
CREATE PUBLICATION my_publication FOR TABLE patient_appointments;
-- Or for all tables in the schema:
-- CREATE PUBLICATION my_publication FOR ALL TABLES;
Keep in mind that the replication user must have SELECT permission on all published tables. Without it, the initial table synchronization (COPY phase) hangs indefinitely in state ‘d’ (data copy).
Create matching schema and subscription on the subscriber
Connect to the subscriber instance and execute:
-- Create the target table with IDENTICAL schema
-- The table structure must match the publisher exactly
CREATE TABLE patient_appointments (
appointment_id SERIAL PRIMARY KEY,
patient_id INTEGER NOT NULL,
patient_name VARCHAR(100),
ssn VARCHAR(11),
date_of_birth DATE,
diagnosis_code VARCHAR(10),
appointment_date DATE NOT NULL,
doctor_id INTEGER NOT NULL,
department VARCHAR(50),
billing_amount DECIMAL(10,2),
procedure_code VARCHAR(10),
visit_type VARCHAR(20)
);
-- Create the subscription
CREATE SUBSCRIPTION my_subscription
CONNECTION 'host=rds-publisher.xxx.us-west-2.rds.amazonaws.com port=5432 dbname=postgres user=repluser password=YourStrongPassword '
PUBLICATION my_publication;
PostgreSQL 15+ on RDS defaults to rds.force_ssl = 1, which means the database rejects any non-SSL connection. When CoIP is enabled, RDS on Outposts automatically uses the CoIP address for all connections from both inside and outside of the VPC. Traffic routes through the Local Gateway even for same-outpost communication. PostgreSQL’s pg_hba.conf treats these CoIP-routed connections as non-local, and with rds.force_ssl = 1, the server requires SSL. If the CREATE SUBSCRIPTION connection string omits sslmode=require, the subscriber’s connection attempt is rejected with a no pg_hba.conf entry for host error. To avoid this, always include sslmode=require in the subscription connection string:
Perform an initial table sync (COPY of existing data).
Begin streaming ongoing changes in real-time.
Step 6: Monitor and verify replication
To monitor replication and verify that logical replication is functioning correctly between the publisher and subscriber instance, PostgreSQL provides several system catalog views and statistics views to monitor replication health. On the publisher instance, we query pg_stat_replication to confirm active write-ahead log (WAL) sender connections and track replication progress through sent and written log sequence number (LSN) positions. We also query pg_replication_slots to verify that the logical replication slot is active and its WAL retention status is healthy. On the subscriber instance, we query pg_subscription to confirm the subscription is enabled and connected to the correct upstream database. We query pg_subscription_rel to verify the synchronization state of each replicated table.
Check replication status on the publisher
-- View active replication connections
SELECT pid, usename, client_addr, state, sent_lsn, write_lsn
FROM pg_stat_replication;
-- View replication slots
SELECT slot_name, active, restart_lsn, confirmed_flush_lsn, wal_status
FROM pg_replication_slots;
Check subscription status on the subscriber
-- View subscription details
SELECT subname, subenabled, subconninfo FROM pg_subscription;
-- View subscription state
SELECT srsubstate FROM pg_subscription_rel;
-- States: 'i' = init, 'd' = data copy, 'r' = ready, 's' = synced, 'f' = finished table copy
Expected output after successful initial sync:
srsubstate
-----------
r
Test data replication
-- On publisher:
INSERT INTO patient_appointments (patient_id, appointment_date, doctor_id, department, billing_amount, visit_type)
VALUES (1001, '2026-07-15', 42, 'Cardiology', 250.00, 'Follow-up');
-- On subscriber (should appear within seconds):
SELECT count(*) FROM patient_appointments;
SELECT * FROM patient_appointments WHERE patient_id = 1001;
Troubleshooting common issues
Issue 1: RDS endpoint not reachable through CoIP
Symptom: TCP connection to CoIP address times out.
Diagnosis:
# From an EC2 instance on the same subnet
telnet rds-publisher.xxx.us-west-2.rds.amazonaws.com 5432
Check:
Route table has both cross-outpost and same-outpost hairpin routes.
Security groups allow port 5432 from CoIP ranges.
CoIP is enabled on the RDS instance (CustomerOwnedIpEnabled: true).
Issue 2: CoIP not assigned to RDS instance
Symptom: CustomerOwnedIpEnabled: false when describing the RDS instance.
Cause: RDS doesn’t inherit the subnet’s MapCustomerOwnedIpOnLaunch setting. Must be explicitly enabled.
Replication user lacks SELECT permission on published tables.
Table schema mismatch between publisher and subscriber.
Network connectivity issue during COPY phase.
Fix:
-- On publisher: grant SELECT permission
GRANT SELECT ON ALL TABLES IN SCHEMA public TO repluser;
-- On subscriber: drop and recreate subscription
ALTER SUBSCRIPTION my_subscription DISABLE;
ALTER SUBSCRIPTION my_subscription SET (slot_name = NONE);
DROP SUBSCRIPTION my_subscription;
-- Recreate subscription
CREATE SUBSCRIPTION my_subscription CONNECTION '...' PUBLICATION my_publication;
Issue 4: “no pg_hba.conf entry for host” error
Symptom: Connection refused with pg_hba error when connecting from CoIP address.
Cause: rds.force_ssl = 1 (default in PostgreSQL 15+) requires SSL for connections from non-VPC addresses.
Fix: Make sure sslmode=require is included in the connection string:
Issue 5: Subscription pointing to wrong publication
Symptom: Subscription connected but no data replicating.
Fix: Drop and recreate subscription with correct publication name:
ALTER SUBSCRIPTION my_subscription DISABLE;
ALTER SUBSCRIPTION my_subscription SET (slot_name = NONE);
DROP SUBSCRIPTION my_subscription;
-- Clean up orphaned slots on publisher if needed
-- SELECT pg_drop_replication_slot('my_subscription');
CREATE SUBSCRIPTION my_subscription
CONNECTION '...'
PUBLICATION correct_publication_name;
Data residency considerations
This architecture provides complete data residency by the following means:
No regional backups: Automated backups to Amazon S3 in the Region are disabled. All data remains on the Outposts.
On-premises replication: All replication traffic flows through Local Gateways and your on-premises network, never traversing the Region backbone.
Local recovery: If an Outpost fails, you can promote the subscriber to become the new primary, maintaining business continuity without regional dependencies.
Selective replication: With logical replication, you can exclude sensitive columns, such as protected health information (PHI) and personally identifiable information (PII), from replication by creating publications for specific columns or tables.
For customers who can accept local backups, RDS on Outposts supports local backup to S3 on Outposts for MySQL and PostgreSQL (not supported for Multi-AZ deployments or read replicas). This requires S3 on Outposts capacity.
Best practices and key takeaways
Throughout this implementation, we encountered several configuration details that are important for a successful deployment. The following best practices and key takeaways will help you avoid common pitfalls when setting up PostgreSQL logical replication between RDS instances on separate Outposts.
CoIP must be explicitly enabled on RDS: It isn’t inherited from subnet settings. Always include --enable-customer-owned-ip when creating RDS instances.
Both cross-outpost and hairpin routes are required: Without hairpin routes, same-subnet access to CoIP addresses fails because DNS resolves to CoIP instead of the private IP.
Replication user needs SELECT permission: Required for the initial COPY phase. Without it, the subscription hangs in state ‘d’.
Table schemas must be identical: The subscriber table must exactly match the publisher table structure, including column names, types, and constraints.
SSL is enforced by default: PostgreSQL 15+ defaults to rds.force_ssl = 1. Use sslmode=require for external connections.
Use Terraform or the CLI for deployment: AWS CloudFormation doesn’t support the EnableCustomerOwnedIp property. Use Terraform (customer_owned_ip_enabled = true) or the AWS CLI.
Monitor replication lag: Use the pg_stat_replication and pg_replication_slots views to monitor replication health and lag.
Plan for failover: Document procedures for promoting the subscriber to primary if Outpost A fails, including application connection string updates.
Comparison with Multi-AZ deployments
Multi-AZ deployments remain the recommended approach for high availability on Amazon RDS on AWS Outposts. They provide automatic failover with synchronous replication between a primary DB instance on one Outpost and a standby on a different Outpost. However, Multi-AZ requires two Outposts anchored to different Availability Zones, and local backups aren’t supported for Multi-AZ deployments. As AWS documentation notes, customers whose workloads must abide by data residency regulations should consult with regulators to determine whether Multi-AZ meets their requirements, because only Single-AZ instances support storing all automated backups and logs directly on the Outposts rack. This post presents an alternative approach that uses PostgreSQL logical replication between Outposts for organizations that need an additional layer of data resilience while keeping all data on-premises. It applies specifically where data residency requirements prevent the use of Regional backups and where the Multi-AZ infrastructure prerequisites (two Outposts across two Availability Zones) are not available. The two options have different characteristics:
Feature
Logical Replication
Multi-AZ on Outposts
Data Residency
Complete (no regional backups)
Automated backups to Region S3
Failover
Manual promotion
Automatic (1-2 minutes)
Replication Granularity
Table-level or column-level
Entire database instance
Cross-Region DR
Supported
Requires additional setup
Network Path
CoIP through Local Gateway
VPC internal (Multi-AZ)
Use Case
Strict data residency, selective replication
High availability with regional integration
For organizations that can accept automated backups to the Region, Multi-AZ deployments offer simpler management and automatic failover. For those with absolute data residency requirements, logical replication with CoIP provides complete control over data locality.
Clean up
When you’re done testing, remove the replication resources to avoid unnecessary costs and WAL accumulation.
On the target, drop the subscription first:
DROP SUBSCRIPTION my_subscription;
On the source, drop the publication:
DROP PUBLICATION my_publication;
Drop the test tables on both source and target:
DROP TABLE IF EXISTS patient_appointments;
If you created dedicated Amazon RDS instances for this walkthrough, delete them through the AWS Management Console or CLI to stop incurring charges. If you modified an existing parameter group, consider reverting rds.logical_replication to 0 if you no longer need logical replication, and reboot the instance.
Conclusion
In this post, we showed you how to configure PostgreSQL logical replication between Amazon RDS for PostgreSQL instances on separate AWS Outposts. This approach gives organizations with strict data residency requirements a way to keep all data on-premises. By using Customer-owned IP addresses and Local Gateways, you can establish secure, low-latency replication that keeps all data within your on-premises environment.
This architecture is particularly valuable for:
Healthcare providers managing PHI under the Health Insurance Portability and Accountability Act (HIPAA).
Financial institutions with data sovereignty requirements.
Government agencies with classified or sensitive data.
Organizations in regulated industries where data must remain on-premises.
The configuration requires careful attention to networking details, particularly the hairpin routes and explicit CoIP enablement. After it’s established, it provides a foundation for disaster recovery and high availability without compromising data residency.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.