Optimizing data with automated intelligent document processing solutions

Post Syndicated from Deependra Shekhawat original https://aws.amazon.com/blogs/architecture/optimizing-data-with-automated-intelligent-document-processing-solutions/

Many organizations struggle to effectively manage and derive insights from the large amount of unstructured data locked in emails, PDFs, images, scanned documents, and more. The variety of formats, document layouts, and text makes it difficult for any standard Optical Character Recognition (OCR) to extract key insights from these data sources.

To help organizations overcome these document management and information extraction challenges, AWS offers connected, pre-trained artificial intelligence (AI) service APIs that help drive business outcomes from these document-based rich data sources.

This blog post describes a cost-effective, scalable automated intelligent document processing solution that leverages a Natural Processing Language (NLP) engine using Amazon Textract and Amazon Comprehend. This solution helps customers take advantage of industry leading machine learning (ML) technology in their document workflows without the need for in-house ML expertise.

Customer document management challenges

Customers across industry verticals experience the following document management challenges:

  • Extraction process accuracy varies significantly when applied to diverse sources; specifically handwritten text, images, and scanned documents.
  • Existing scripting and rule-based solutions cannot provide customer domain or problem-specific classifiers.
  • Traditional document management systems cannot consider feedback from domain experts to improve the learning process.
  • The Personally Identifiable Information (PII) data-handling is not robust or customizable, causing data privacy leakage concern.
  • Many manual interventions are required to complete the entire process.

Automated intelligent document processing solution

We introduced an automated intelligent document processing implementation to address key document management challenges. At the heart of the solution is a NLP engine that combines:

The full solution also leverages other AWS services as described in the following diagram (Figure 1) and steps to develop and operate a cost-effective and scalable architecture for document processing. It effectively extracts text from document types including PDFs, images, scanned documents, Microsoft Excel workbooks, and more.

AI-based intelligent document processing engine

Figure 1: AI-based intelligent document processing engine

Solution overview

Let’s explore the automated intelligent document processing solution step by step.

  1. The document upload engine or business users upload the respective files or documents through a custom web application to the designated Amazon Simple Storage Service (Amazon S3) bucket.
  2. The event-based architecture signals an Amazon S3 push event to invoke the respective AWS Lambda function to start document pre-processing.
  3. The Lambda function evaluates the document payload, leverages Amazon Simple Queue Service (Amazon SQS) for async processing, prepares document metadata, stores it in Amazon DynamoDB, and calls the NLP engine to perform the information extraction process.
  4. The NLP engine leverages Amazon Textract for text extraction from a variety of sources and leverages document metadata to optimize the appropriate API calls (for example, form, tabular, or PDF).
    • Amazon Textract output is fed into Amazon Comprehend which consumes the extracted text and performs entity parsing, line/paragraph-based sentiment analysis, and document/paragraph classification. For better accuracy, we leverage a custom classifier within Amazon Comprehend.
    • Amazon Comprehend also provides key APIs to mask PII data before it is used for any further consumption. The solution offers the ability to configure masking rules for each PII entity per masking requirements.
    • To ensure the solution has capability to handle data from Microsoft Excel workbooks, we developed a custom parser using Python running inside an AWS Lambda function. Depending on the document metadata, this function can be invoked.
  5. Output of Amazon Comprehend is then fed to ML models deployed using Amazon SageMaker depending on additional use cases configured by the customer to complement the overall process with ML-based recommendations, predictions, and personalization.
  6. Once the NLP engine completes its processing, the job completion notification event signals another AWS Lambda function and updates the status in the respective Amazon SQS queue.
  7. The Lambda post-processing function parses the resultant content generated by the NLP engine and stores it in the Amazon DynamoDB and Amazon S3 bucket. This step is responsible for the required data augmentation, key entities validation, and default value assignment to create a data structure that could be consumed by the presentation/visualization layer.
  8. Users get the flexibility to see the extracted information and compare it with the original document extract in the custom user interface (UI). They can provide their feedback on extraction and entity parsing accuracy. From a user access management perspective, Amazon Cognito provides authorization and authentication.

Customer benefits

The automated intelligent document processing solution helps customers:

  • Increase overall document management efficiency by 50-60%, leveraging automation and nullifying manual interventions
  • Reduce in-house team involvement in administrative activities by up to 70% using integrated and connected processing workflows
  • Gain better visibility into key contractual obligations with features such as Document Classification (helps properly route documents to the respective process/team) and Obligation Extraction
  • Utilize a UI-based feedback mechanism for in-house domain experts/reviewers to see and validate the extracted information and offer feedback to inform further model training

From a cost-optimization perspective, depending on document type and required information, only the respective Amazon Textract APIs calls are submitted. (For example, it is not worth using form/table-based Textract API calls for a Know Your Customer (KYC) document such as a driver’s license or passport when the AnalyzeID API is the most efficient solution.)

To maximize solution benefits, customers should invest time in building well-defined taxonomies ahead of using the document processing solution to accommodate their own use cases or industry domain-specific requirements. Their taxonomy input highlights only relevant keys and takes respective actions in case the requires keys are not extracted.

Vertical industry use cases

As mentioned, this document processing solution can be used across industry segments. Let’s explore some practical use cases. For example, it can help insurance industry professionals to accelerate claim processing and customer KYC-related processes. By extracting the key entities from the claim documents, mapping them against the customer defined taxonomy, and integrating with Amazon SageMaker models for anomaly detection (anomalous claims), insurance providers can improve claim management and customer satisfaction.

In the healthcare industry, the solution can help with medical records and report processing, key medical entity extraction, and customer data masking.

The document processing solution can help the banking industry by automating check processing and delivering the ability to extract key entities like payer, payee, date, and amount from the checks.

Conclusion

Manual document processing is resource-intensive, time consuming, and costly. Customers need to allocate resources to process large volume documents, lowering business agility. Their employees are performing manual “stare and compare” tasks, potentially reducing worker morale and preventing them from focusing where their efforts are better placed.

Intelligent document processing helps businesses overcome these challenges by automating the classification, extraction, and analysis of data. This expedites decision cycles, allocates resources to high-value tasks, and reduces costs.

Pre-trained APIs of AWS AI services allow for quick classification, extraction, and data analyzation from scores of documents. This solution also has industry specific features that can quickly process specialized industry specific documents. This blog discussed the foundational architecture to helps to accelerate implementation of any specific document processing use case.

Прозорецът към вътрешния свят на клетката

Post Syndicated from original https://www.toest.bg/prozoretsut-kum-vutreshniya-svyat-na-kletkata/

Прозорецът към вътрешния свят на клетката

Най-прекият път към вътрешния свят на клетката е HLA системата (Human Leukocyte Antigens – човешки левкоцитни антигени). Тя е известна и като главен комплекс за тъканна съвместимост при човека. Състои се от над 200 гена, които изграждат „прозореца“ на клетката. Тези гени носят информация за белтъци, наречени гликопротеини, намиращи се на повърхността на клетките. За тях се закачват определени пептиди (части от белтъци), произхождащи от клетката.

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

Ако обаче липсва пай на прозореца или той не изглежда добре, най-вероятно в някоя от стъпките нещо се е объркало или повредило. Аналогично е и при клетката. В различни структури от вътрешността ѝ се обработват белтъци, режат се на малки части, преминават през редица други структури и накрая излизат на повърхността, свързани с HLA. След това Т-клетките се свързват с тези молекули и правят проверка (също както Том е привлечен от миризмата и вида на вкусния пай и отива да го „провери“). Т-клетките са вид имунни клетки и ролята им е да предпазват тялото от инфекции, като разпознават чужди пептиди, ако са се свързали на повърхността на HLA.

Прозорецът към вътрешния свят на клетката
Пътят на обработка на HLA молекули от клас I и клас II и свързването на пептиди, разпознавани от Т-клетките. Адаптирано по MHC Class I and II Pathways от BioRender.com (2022). Източник: https://app.biorender.com/biorender-templates

Главен комплекс за тъканна съвместимост при човека

HLA системата е жизненоважна при трансплантации на органи и тъкани, тъй като, колкото и да си приличаме (99,9% генетична сходност), тялото на реципиентa (приемащия) разпознава донорния орган като чужд и атакува клетките му (т.нар. реакция на отхвърляне). За да може даден орган да функционира в чуждо тяло, клетките му трябва да имат идентични HLA молекули с тези на реципиента.

Затова преди всяка трансплантация се прави т.нар. HLA типизиране – определя се HLA формулата на реципиента и на потенциалните донори и се търси съвместимост в най-висока степен. В България координацията и контролът на трансплантациите се ръководят от Изпълнителна агенция „Медицински надзор“ (ИАМН), чиято статистика сочи, че към момента 868 пациенти имат нужда от трансплантация на орган, а трансплантациите на стволови клетки за миналата година са 183.

Автоимунитет

Автоимунните болести са трудно лечими и при голяма част от тях механизмът на заболяването все още не е напълно изяснен. В основата му обаче отново стои HLA. За да е сигурно, че в организма няма възпалителни процеси, причинени както от външни фактори (например бактерии и вируси), така и от вътрешни (трансформация на здрави клетки в ракови), HLA свързва и „здрави“ пептиди. Т-клетките ги разпознават и не предприемат действия. При автоимунитета обаче въпросните здрави пептиди се разпознават като патология и имунната система се активира с цел да разруши увредената клетка.

Учените са установили, че определени HLA варианти (наречени алели на гените) предразполагат към развитието на определени автоимунни заболявания. В тази връзка изследването за носителство на даден алел на определен HLA ген може да потвърди поставената диагноза или да се изясни възможността за развитие и по-тежко протичане.

Болестта на Бехтерев (анкилозиращ спондилит) е тип артрит. Характерно за нея е хроничното възпаление на ставите, като в основата стои автоимунен механизъм. По-голямата част от пациентите са носители на HLA-B*27 алела. Изследване на HLA-B гена сочи към генетична предразположеност и може да потвърди диагнозата.

Друго автоимунно заболяване, при което се изследва HLA, е цьолиакията (глутенова непоносимост). Характерно за нея е възпалението на тънките черва при консумация на глутен. При съмнение за цьолиакия изследването на HLA би могло да докаже генетична предразположеност (при носителство на HLA-DQB1 алелите *02, *03:02 и DQA1*05).

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

Нарколепсията е и неврологично заболяване с характерно нарушение на циркадния ритъм, което води до умора и неконтролируемо желание за сън. Носителите на HLA-DQB1*06:02 и DQA1*01:02 са генетично предразположени към това заболяване. При силни емоции, като гняв, страх, радост, смях, страдащият от нарколепсия внезапно заспива, като преминава в REM фазата на съня. Заради тази специфика на заболяването нарколепсията представлява интерес за хората на изкуството и е в основата на научнофантастични и трилър филми, книги, подкасти.

Игра на криеница с туморните клетки

Всички здрави тъкани имат HLA гени от клас I на повърхността си. В основата на развитието на метастази при раковите заболявания стои изключително хитър механизъм за криене на туморните клетки от имунната система. Една туморна клетка би могла да се разпознае от имунната система и да бъде унищожена чрез сигнал за проблем отново с помощта на HLA.

HLA се свързват с молекули от грешно нагънати белтъци и по този начин клетката се разпознава като увредена. За да могат туморните клетки да оцелеят и да образуват клон от клетки, а в последните стадии на заболяването и да се разпространят в цялото тяло (метастази), те трябва да се скрият от имунната система. Имунните терапии в последните години са насочени към повторното активиране на HLA гените от клас I, защото при редица ракови заболявания HLA молекулите не се експресират на повърхността на клетката (не само че няма пай на прозореца, но на практика липсва прозорец).

Неканени гости

Чрез HLA инфектираните клетки се разпознават от имунната система и биват елиминирани. Поради тази причина голяма част от изследванията, свързани с COVID-19, са насочени към HLA предразположеност за заразяване и прогноза за по-леко или по-тежко протичане. Едно от най-мащабните проучвания от началото на пандемията, фокусирано върху този проблем, е организирано от учените от лабораторията на проф. Джил Холенбах, част от Калифорнийския университет в Сан Франциско. Заедно с други учени, лидери в областта на имуногенетиката, е създадена онлайн платформа – база данни за проучвания нa връзката между HLA и COVID-19.

Еволюция на HLA и бъдещи перспективи

След няколко десетилетия изследвания на HLA системата учените са установили, че гените са претърпели естествен подбор. Геномните изследвания на HLA чрез секвениране от ново поколение (NGS) трансформират познанията за еволюцията на тази изключително разнообразна област от генома. С напредването на технологиите за секвениране HLA типизирането вече може да се извърши и с трето поколение секвениране, което позволява по-голяма прецизност на секвениране и определяне на некодиращи области, мутации и нови алели.

Заглавно изображение: Животинска клетка под микроскоп.
Източник: The Greatest Garden

Kids’ coding languages

Post Syndicated from Marc Scott original https://www.raspberrypi.org/blog/kids-coding-languages/

Programming is becoming an increasingly useful skill in today’s society. As we continue to rely more and more on software and digital technology, knowing how to code is also more and more valuable. That’s why many parents are looking for ways to introduce their children to programming. You might find it difficult to know where to begin, with so many different kids’ coding languages and platforms available. In this blog post, we explore how children can progress through different programming languages to realise their potential as proficient coders and creators of digital technology.

Two kids share their Scratch coding project on a laptop.

ScratchJr

Everyone needs to start somewhere, and one great option for children aged 5–7 is ScratchJr (Scratch Junior), a visual programming language with drag-and-drop blocks for creating simple programs. ScratchJr is available for free on Android and iOS mobile devices. It’s great for introducing young children to the basics of programming, and they can use it to create interactive stories and games.

Scratch

Moving on from ScratchJr, there’s its web-based sibling Scratch. Scratch offers drag-and-drop blocks for creating programs and comes with an assortment of graphics, sounds, and music for your child to bring their programs to life. This visual programming language is designed specifically for children to learn programming fundamentals. Scratch is available in multiple spoken languages and is perfect for beginners. It allows kids to create interactive stories, animations, and games with ease.

The Raspberry Pi Foundation has a wealth of free Scratch resources we have created specifically for young people who are beginners, such as the ‘Introduction to Scratch’ project path. And if your child is interested in physical computing to interact with the real world using code, they can also learn how to use electronic components, such as buzzers and LEDs, with Scratch and a Raspberry Pi computer.  

Young person using a laptop to code in Scratch, our favourite of all kids' coding languages.

MakeCode

Another fun option for children who want to explore coding and physical computing is the micro:bit. This is a small programmable device with an LED display, buttons, and sensors, and it can be used to create games, animations, interactive projects, and lots more. To control a micro:bit, a visual programming language called MakeCode can be used. The micro:bit can also be programmed using Scratch or text-based languages such as Python, offering an easy transition for children as their coding skills progress. Have a look at our free collection of micro:bit resources to learn more.

HTML

Everyone is familiar with websites, but fewer people know how they are coded. HTML is a markup language that is used to create the webpages we use every day. It’s a great language for children to learn because they can see the results of their code in real time, in their web browser. They can use HTML and CSS to create simple webpages that include links, videos, pictures, and interactive elements, all the while learning how websites are structured and designed. We have many free web design resources for your child, including a basic ‘Introduction to web development’ project path.

Three kids coding at laptops.

Python 

If your child is becoming confident with Scratch and HTML, then using Python is the recommended next stage in their learning. Python is a high-level text-based programming language that is easy to read and learn. It is a popular choice for beginners as it has a simple syntax that often reads like plain English. Many free Python projects for young people are available on our website, including the ‘Introduction to Python’ path.

A kid coding in Python on a laptop.

The Python community is also really welcoming and has produced a myriad of online tutorials and videos to help learners explore this language. Python can be used to do some very powerful things with ease, which is why it is so popular. For example, it is relatively simple to create Python programs to engage in machine learning and data analysis. If you wanted to explore large language models such as GPT, on which the ChatGPT chatbot is based, then Python would be the language of choice.

JavaScript 

JavaScript is the language of the web, and if your child has become proficient in HTML, then this is the next language for them. JavaScript is used to create interactive websites and web applications. As young people become more comfortable with programming, JavaScript is a useful language to progress to, given how ubiquitous the web is today. It can be tricky to learn, but like Python, it has a vast number of libraries of functions that people have already created for it to achieve things more quickly. These libraries make JavaScript a very powerful language to use.

Try out kids’ coding languages

There are many different programming languages, and each one has its own strengths and weaknesses. Some are easy to learn and use, some are really fast, and some are very secure.

Two kids coding together on Code Club World.

Starting with visual languages such as Scratch or MakeCode allows your child to begin to understand the basic concepts of programming without needing any developed reading and keyboard skills. Once their understanding and skills have improved, they can try out text-based languages, find the one that they are comfortable with, and then continue to learn. It’s fairly common for people who are proficient in one programming language to learn other languages quite quickly, so don’t worry about which programming language your child starts with.

Whether your child is interested in working in software development or just wants to learn a valuable — and creative — skill, helping them learn to code and try out different kids’ coding languages is a great way for you to open up new opportunities for them.

The post Kids’ coding languages appeared first on Raspberry Pi Foundation.

Integrate Zabbix with your data pipelines by configuring real-time metric and event streaming

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/integrate-zabbix-with-your-data-pipelines-by-configuring-real-time-metric-and-event-streaming/25728/

Modern IT infrastructures tend to utilize multiple data sources to evaluate and react to the current state of the infrastructure. A set of internal solutions and dedicated software tools are used to correlate the collected information and react in a proper way to changes in the environment – be it a gradual increase or decrease in resource usage, unexpected load spikes or run-of-the-mill outages.

With the release of Zabbix 6.4, metrics collected by Zabbix and events generated based on trigger expressions can be integrated into such a data pipeline by using the new real-time metric and event streaming feature.

Zabbix real-time metric and event streaming

Before Zabbix 6.4 Zabbix supported real-time export of history, trends and events to files. The export was performed by exporting the data in newline-delimited JSON format. Additional scripting was mandatory if a user wanted to integrate this data within their data pipeline since Zabbix only exported the data to files without any further transformations or streaming.

On the other hand – real-time metric streaming can be a lot more flexible when it comes to integrating Zabbix with data pipelines, filtering the required data and securing the connection to the third party endpoint.

In addition to specifiying the streaming endpoint URL, Zabbix users can choose between streaming Item values and Events. On top of that, Tag filtering can be used to further narrow down the data that will be streamed to the endpoint.

Connectors

Real-time item value and event streaming can be configured by accessing the Administration – General – Connectors section. Here Zabbix administrators will have to create connectors and specify what kind of data the connector will be streaming. A single connector can only stream either Item values or events – if you wish to stream both, you will have to define at least two connectors, one for values and the other for events.

Configuring a new connector

Marking the Advanced configuration checkbox enables Zabbix administrators to further configure each individual connector – from specifying the number of concurrent sessions, limiting the number of attempts and specifying the connection Timeout to configuring HTTP proxies and enabling SSL connections.

An HTTP authentication method can also be specified for each connector. It is possible to use one of the following methods:

None – no authentication used;

Basic – basic authentication is used;

NTLM – NTLM (Windows NT LAN Manager) authentication is used;

Kerberos – Kerberos authentication is used;

Digest – Digest authentication is used;

Bearer – Bearer authentication is used.

In addition, the number of pre-forked connector worker instances must be specified in the Zabbix server configuration file in the StartConnectors parameter.

Setting StartConnectors parameter in Zabbix server configuration file

Protocol

Under the hood, the data is sent over HTTP using newline-delimited JSON export protocol.

The following example shows a trigger event for Zabbix agent being unreachable:

{"clock":1519304285,"ns":123456789,"value":1,"name":"Either Zabbix agent is unreachable on Host B or pollers are too busy on Zabbix Server","severity":3,"eventid":42, "hosts":[{"host":"Host B", "name":"Host B visible"},{"host":"Zabbix Server","name":"Zabbix Server visible"}],"groups":["Group X","Group Y","Group Z","Zabbix servers"],"tags":[{"tag":"availability","value":""},{"tag":"data center","value":"Riga"}]}

Do not get confused by the value field, the value if which will always be 1 for problem events, while for items, it will contain the item value:

{"host":{"host":"Host B","name":"Host B visible"},"groups":["Group X","Group Y","Group Z"],"item_tags":[{"tag":"foo","value":"test"}],"itemid":4,"name":"CPU Load","clock":1519304285,"ns":123456789,"value":0.1,"type":0}

Use cases

Finally, what particular use cases can we use the real-time metric streaming feature for? As I mentioned in the introduction, Zabbix item values and events could serve as an additional source of near real-time information about the current system behavior.

For example, we could stream item values and events to message brokers such as Kafka, RabbitMQ or Amazon Kinesis. Combine this with additional automation solutions and your services could dynamically scale (think K8s/Docker containers) depending on the current (or expected) load. Zabbix Kubernetes and Docker container monitoring templates very much complement such an approach.

The streamed data could also be used to gain new insights about the system behavior by streaming it to an AI engine or data lakes/data warehouses for long-term storage and analysis.

Българските парадокси. Декодиране на бъдещето

Post Syndicated from Емилия Милчева original https://www.toest.bg/bulgarskite-paradoksi-dekodirane-na-budeshteto/

Българските парадокси. Декодиране на бъдещето

България има редовно правителство и няма редовно правителство. И двете вероятности са верни, докато не бъде приключен вторият мандат, макар да не е връчен първият. А по конституция има опция и за трети мандат.

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

Подготовката на общата програма от експертите на ГЕРБ–СДС и ПП–ДБ не върви гладко и по всяка вероятност ще се проточи до обявяването на имената за кабинет, които поиска Борисов от ПП–ДБ.

Гласност за правителство

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

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

Наказания за всички от сърце

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

Така че страхът е един от елементите, свързващ паветата на общия път, от който една трета вече е извървяна, по оценка на Томислав Дончев (ГЕРБ). Стъпките са бавни, но ще ги извървим, каза по-рано Даниел Митов (ГЕРБ) след лидерската среща тази седмица между двете формации. От другата страна проф. Николай Денков е умиротворителят:

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

Някакво правителство

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

Според публично изразена надежда от съпредседателя на ПП Кирил Петков такова правителство (с мандат на ПП–ДБ) може да е с хоризонт до влизането в еврозоната. Съпартиецът му проф. Денков прецизира: за 18 месеца, до края на 2024 г. Химера предвид неяснотата дали изобщо България ще се вмести в новия срок – 1 януари 2025 г., който също не е сигурен, защото зависи какъв ще е конвергентният доклад идната пролет. А този доклад зависи от показателите на бюджета за 2023 г., който ще приеме парламентът – дали дефицитът ще е 3%, или повече, годишната инфлация, приемането на законите, необходими за еврозоната. По един от тях – промените в Кодекса за застраховане, имат възражения застрахователите, по другия – Закона за мерките срещу изпирането на пари, възразиха адвокатите с аргументите, че са доверени лица и не могат да работят срещу клиентите си, като донасят за тях в ДАНС.

Засега и двете сили (ГЕРБ–СДС и ПП–ДБ) правят „подскоци“ и „шоу за пред камерите“, коментира по БНР журналистът Петко Георгиев.

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

Както и да я наредят, бюджетът за 2023 г. ще е на първо място. Преди него обаче в парламента беше внесен законопроектът за домашното насилие, който 48-мото Народно събрание така и не прие. Подреждането на приоритетите в програмата и съответният тайминг са от съществено значение. Ако Планът за възстановяване и развитие и приемането в Шенген са с предимство, значи сред приоритетите е и законодателството за създаване на механизъм за разследване на главния прокурор и за реформа в Антикорупционната комисия (КПКОНПИ). Тръгнат ли обаче към избор на 11-те членове на ВСС, което трябваше да бъде направено още миналата есен, ще трябва да търсят още подкрепа, защото за тях е необходимо да гласуват две трети (160) от народните представители. Двете коалиции събират общо 133-ма депутати.

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

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

Декодирането на бъдещето е главоболна работа.

По буквите: Алексиева, Клоугарт, Кунева

Post Syndicated from Зорница Христова original https://www.toest.bg/po-bukvitie-aleksieva-klougart-kuneva/

„Вулкан“ от Елена Алексиева

По буквите: Алексиева, Клоугарт, Кунева

корица Люба Халева, Пловдив: ИК „Жанет 45“, 2023

По буквите: Алексиева, Клоугарт, Кунева

Единството в изкуството е приятно за публиката, но убийствено за способността ѝ да се изненадва. Във „Вулкан“ на Елена Алексиева няма такава опасност – изненадата не е „елемент“ в българския смисъл на думата, а her element – тоест самата стихия, материя на книгата.

Романът започва така, сякаш всяка глава е отделен разказ, с нови герои, нова ситуация, ново място – прочут пациент на д-р Алцхаймер, неговата болногледачка, обрасло с козинка момиче в българско село, новобогаташ с идея за развитието на лайняна енергия, журналистка…

В първия момент мислиш, че канавата е социална, заради драматичните контрасти в общественото положение на героите, също както в последния филм на Йостлунд, където сцените се сменят с подобна привидна непоследователност. Фекалната тема като че ли също преподчертава общия дух на „насмешлив реализъм“ – с буквалната, физическа карикатурност на героите, с натуралистичния комизъм на ситуациите, в които изпадат (скритите в гащите пари биват забравени и изпуснати в тоалетната), с точния брой щрихи, които хем ти позволяват да погледнеш през очите на даден герой, хем не те оставят да се идентифицираш докрай с него, защото мислите му са колкото убедителни, толкова и пародийни.

Тази насмешка обаче скоро прелива извън физическото, към онова, което героите възприемат като свой „духовен“ пласт – смешна мешавица от света на свръхестественото така, както се виждаше у нас през 90-те – малко източна мистика (в един от епизодите се явява демонът Мара, същият, който се опитва да попречи на Буда да постигне просветление, в друг – нова планета, която евентуално ще бъде открита и ще пренареди наталните карти на всички персонажи, и т.н.).

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

Връщането към 90-те и техният комичен потенциал обаче блясват най-силно в главата „Радикална херменевтика“, където читателят вече се смее с глас или буквално цвили, ако е завършил филология през въпросния период. Защото тук комедията престава да бъде физическа и ситуационна и прелива в комедия на стила, в умела пародия на литературно-научен „дискурс“, но и на анализираните от него пънкарски текстове. На песни от Сатан Пирдопски. Впрочем самите текстове са извънредно убедителни, чак ти се прищява наистина да бяха влезли в обращение през въпросното десетилетие.

С моя приятел микроба
влачим се двама към гроба.
Викам му: „Спри бе, микроб!
Рано е още за гроб!“

Но и литературният анализ на творбите е не по-малко убедителен – и то не учебникарският, а този, който действително можеше да се чуе из коридорите на университета. От „изобретяването“ на нови думи за самия литературен дискурс („творбец“), през здраво оплетената и осеяна с възелчета канава на изказа („Извън горното съображение обаче – и изцяло в духа на илюминативното формулиране на творбата като над-езиков локус на смислопораждащо сливане на презентация, репрезентация и перцепция в единна, непрестанно обогатяваща се общност на интерпретации…“), до буквалното чепкане на „деформиращата стихия на тоталитарния строй“ в редове като следните:

Вчера ме боля душата,
днеска ме боли гъзът.
Аз роден съм в комунизма –
да живей, живей трудът!

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

Впрочем Елена Алексиева изобщо не крие своите литературни препратки – „Кучешко сърце“ е споменато директно в разговора между хирурга и неговия потенциален пациент, а към края на книгата настойчиво започват да се появяват други литературни бащи (както казваха през 90-те): Аркадий и Борис Стругацки се вясват първо в съня на хирурга, после в съня на обраслото с козинка момиче – пряка препратка към Маймунката от „Пикник край пътя“, но и завръщане към източната тематика: момичето сънува, че един от братята е сънувал, че Маймунката ги сънува и оспорва формулировката на желанието, с което завършва повестта: „Щастие даром и никой да не бъде забравен.“

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

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

„Всичко това можеше да е твое“ от Йосефине Клоугарт

превод от датски Мария Змийчарова, корица София Карастоянова, София: изд. „Аквариус“, 2023

По буквите: Алексиева, Клоугарт, Кунева

Напоследък приятели ми споделят колко трудно харесват нови книги. И нови в смисъл на непознати, и нови в смисъл на писани сега. Че нещо в гладката им повърхност ги отблъсква, литературен small talk, празнословие, само че на хартия. Което е парадоксално, защото сега повече от всякога книгоиздаването изглежда заето с изследване на важните за конкретни читатели теми – да се говори за това, и за онова също, а и другото да не остане непогалено с литературно перо. В някакъв момент ще можеш да въведеш личните си данни в търсачката и да получиш книга, чийто герой прилича точно на теб – по раса, пол, занятие и т.н. Което обаче няма нищо общо със способността ѝ да те увлича, с твоята способност да прочетеш нещо важно за себе си в нея.

Харесах „Всичко това можеше да е твое“ на Йосефине Клоугарт по прочетено наслука изречение. Хареса ми стилът, който е като тресавището на Рупчев – напоен с образност и измамливо плавен, музикален по начин, който надхвърля фонетиката и дори интонационните линии, паузи и каденци. Музикален така, както могат да са музикални архитектурата или природата, благодарение на една всеобемаща хармония, в която си въвлечен не поради някаква предварителна своя същност, а просто защото си техен свидетел – и затова част от всичко. Ето тази барокова хармония у Клоугарт напомня за тресавище – с трептящата над погледа вода, с виещите се стъбла на тревите близо до повърхността, с мътното и сладостно усещане за опасност – значи усещане, че най-сетне нещо се случва, нещо, което да засяга читателя. (Неслучайно критиците сравняват Клоугарт с Вирджиния Улф.)

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

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

Йосефине Клоугарт е съавторка на Олафур Елиасон в албума му Your Glacial Expectations. И ѝ подхожда. Нейната проза е като неговите огледала – кръгли, полегнали в тревата отрязъци небе.

Това е първата книга на Клоугарт, преведена на български (поздравления за великолепната Мария Змийчарова), и последната, написана от авторката. Което значи, че бихме могли тепърва да очакваме още от същото.

„Кучето на Персефона“ от Виолета Кунева

корица Люба Халева, Пловдив: „Жанет-45“, 2023

По буквите: Алексиева, Клоугарт, Кунева

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

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

Един ден смъртта се появява
като бездомно кученце,
което подтичва след нас.
Ляга в краката ни.
Чуваме дишането му.
Купуваме каишка.
Стани, Смърт!
Седни!
Тихо!
До мен, Смърт!
Учи бързо.
Отговаря на всички имена.

Това са образи-завръзки, но не в класическия смисъл на фабулостроенето, а по-скоро като проблем в ума, който търси своето разрешение. Подобни завръзки има немалко: адът, който изглежда досущ като сегашното ежедневие, със същия панелен адрес и дори с готвача зад ъгъла, който е отворил ресторантче тук; или градинарят, който започва пролетта с отрова, защото служи на двама богове (единият назован, а другият?):

За отговорността да имаш красива градина

всяка пролет за градинаря
започва с отровата

сипва я внимателно в дупките на къртиците
полага я в корените на розите
пръска листата

това е важен ритуал –
жертвоприношение
за бога на красотата

голяма отговорност е
да служиш
на двама богове

мърмори градинарят

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

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

Поддържам тази версия, защото ми прави впечатление колко много от стихотворенията в книгата говорят за ценността на раната, за раната като място, през което струи светлина. Първо имаме страха, който като побесняло добиче разкъсва границите на вселената, и „преди да зараснат / от дупките прониква светлина“. В следващото стихотворение се страхуваме „светлината да не изтече под прикритието на думите“. А малко по-нататък Виолета Кунева говори за раната, която привлича ножа и „затова не я лекуваш“, а чакаш той да я намери, да легне в нея и да накара цветето ѝ да се разтвори. Същият любовен тон е през две стихотворения, този път не към раната, а към причинилия я страх – „мой добричък страх, / къде си? Така строго ме охраняваше – / другите лоши неща / не смееха да припарят“. Първото в мечтата на ангела е да бъде чуплив. В предишното стихотворение говорещият оставя лошата новина да го ужили – за да провери дали е жив.

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

Преди да паднем

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

но сега сме тук
и все още можем да учим
един от друг

Толкова за привидната монолитност на стихотворенията в „Кучето на Персефона“.

Активните дарители на „Тоест“ получават постоянна отстъпка в размер на 20% от коричната цена на всички заглавия от каталозите на „Аквариус“ и „Жанет 45“, както и на няколко други български издателства в рамките на партньорската програма Читателски клуб „Тоест“. За повече информация прочетете на toest.bg/club.

В емблематичната си колонка, започната още през 2008 г. във в-к „Култура“, Марин Бодаков ни представяше нови литературни заглавия и питаше с какво точно тези книги ни променят. Вярваме, че е важно тази рубрика да продължи. От човек до човек, с нова книга в ръка.

Битката за поезията. Бележки върху поетичния метод на Марин Бодаков

Post Syndicated from Яна Букова original https://www.toest.bg/bitkata-za-poeziata/

Битката за поезията. Бележки върху поетичния метод на Марин Бодаков

Поезията на Марин Бодаков е самотно явление в българската литература. С това определение нямам предвид самота и изолираност на нейния автор.

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

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

неговата поезия е поезия без аналог.

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

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

това не е така наречената изповедна поезия,

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

Той наблюдава и описва хора, природа, събития, но

това не е описателна поезия.

Той разказва неща, но

това не е наративна поезия.

Това е поезия, пълна с неочаквани обрати, с абсолютно нестандартно, неконвенционално съчленяване на думи и образи, но в никакъв случай

това не е сюрреална поезия.

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

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

Битката за поезията. Бележки върху поетичния метод на Марин Бодаков

Може би първият и най-ярък пример за метода на Марин Бодаков са заглавията.

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

Два примера:

Да се чете буквално

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

И още:

Учебна тревога

Н. М.

И този ден:
като лилия без име,
като лопата без гроб.
Като монах без Бог.

Няма пръст, на която да падне снегът,
просто пада.

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

В това разширяване и умножаване на значенията в заглавните фрази човек се пита дори по отношение на заглавието на самата тази книга: какво е „галерията на сърцето“? Едно пространство на сърцето, съхраняващо и излагащо красивото и важното, или е галерия на мина, където дълбаеш в тъмнина, без да знаеш на какво ще попаднеш? Или са и двете едновременно и с еднаква сила?

Обобщавайки, декларативно бих могла да заявя, че методът на Марин Бодаков е тишината.

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

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

Море

Небето ходи по водата
и стъпките му са вълни –
летища птичи.
Морето всъщност е баща удавен.
Боиме се да го целунем.

Дори в това толкова ранно младежко стихотворение разпознаваме всички елементи на неговата поетика: тези взаимни отражения, тези отскоци на образа, тези огромни символични фигури, които много често населяват поезията му, и това винаги лично участие. Марин винаги участва в стихотворенията си или като Аз, или като Ние. Той не е просто свидетел на света, той винаги е участник в света, отговорен участник в света. Понякога болезнено отговорен, поемащ изключително много отговорност, непосилно отговорен участник.

А още в първото стихотворение на този сборник, откриващо първата негова издадена книга, попадаме на стих, който е изцяло програмен: „Единствено покоят буди“ („Посвещение“). Това е този постоянен тих тътен в поезията на Марин Бодаков.

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

Това е поезия за човешката тленност и уязвимост, поезия за предателствата на тялото, поезия за постоянната битка между ужаса и красотата.

Една постоянна битка с неясен резултат. И естествено, както вече споменах, поезия безпощадно оголена към Аза, към всяко извъртане, към всяко самоуспокоение, към всеки собствен образ, който си изграждаме, за да ни е удобно да живеем. Този образ, този свой образ Марин непрестанно руши в поезията си. Пак безпощадно. Както казва той: „Разпервам рани – и политам.“

И още едно просто, лаконично стихотворение, което се нарича „Обич“:

Помня този човек,
раната му като кораб,
корабът му като завивка,
завивката му като мочурище,
мочурището като звезда
и звездата като рана.
Човек като човек.

Толкова просто, ясно и жестоко може да се опише човешкото.

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

Първият е мотивът за Тялото –

за неговата слабост, недостатъчност, за неговата погрешна скроеност, онтологично погрешна скроеност. Още в първите му, младежки стихосбирки то присъства като поле на недостатъчност и тревога: „в несъвършените ми членове, / в подножието на скръбта ми“ („Акт 1“), или „с петачетата на плътта си“ („Пиано бар“), или дори „по-малко тяло ми дай“ („6 октомври“). Но за това тяло той говори и с упование в едно особено красиво стихотворение:

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

(известна предпазливост III)

Постепенно обаче това тяло отслабва, поддава се на времето, извършва предателства: „изтощено, грозно, / … не ме сприятелява със себе си“ („Добър живот“).

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

Глаголът

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

да го начуква по-дълбоко,
да ридае

И по различен начин в това толкова красиво стихотворение:

Смутени обреди

Докосваш ме
с мощта на траурната музика
и тежестта на слабините
заплашва с чудо

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

Друго ключово понятие в поезията на Марин Бодаков е думата Война.

Това, за съжаление, е особено актуална дума в настоящия момент, по особено трагичен и заплашителен начин актуална. За Марин обаче човешкото същество е винаги в екзистенциалната позиция на война. Неговата поезия е пълна с военна лексика: вражески лагери, враг, обстрел, екзекуция. Човешката кондиция е състояние на война, човешкото същество по определение се намира в постоянна, несправедлива, безсмислена катастрофа, под обстрел, под обсада. „Черни и златни ели има навън, почваме да си шушукаме: / толкова е удобно между тях да ни разстрелят.“ („Срамувам се вместо други“) Или: „Пак надушвам месарската кука, / която се готви за нас“ („Изгубени 2“). Усещането за катастрофата, надвисналата опасност, неизбежният срив, отворената бездна, в която човекът рискува да потъне, са постоянни мотиви в поезията на Марин. Но едно стихотворение обобщава всичко това по най-страшния начин не само заради картината, която обрисува, но заради ужасяващата си екзистенциална истинност:

В памет на Невена Стефанова

Това не е въпрос,
на който трябва спешно да ми отговорите,
но все пак:

кои от своите приятели
сте виждали чисто голи, настръхнали,
готови за разстрел?

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

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

Тази красота е много сериозна част от поезията на Марин, една от опорите на поезията на Марин.

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

Нежна небрежност

умилителна дупчица по бельото
няма кой да я види
някой близък

щом прокараш над нея ютията,
зимен дим

И другото:

Докато сутрин обувам чорапа,

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

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

Коледна песен

(Втора сутрин намирам картоф в чорапа на празника.)
Трябва да стигна морето,
да оставя велосипеда преди острите камъни,
както си правила преди година…
Ти, светлината над името ми, вълната в него,
с две малки рибки.

Едновременно с това красотата съществува като почти единственото, пределното и сюблимно оръжие на живота срещу нищото. Отново не е случайно, че във всички стихотворения, които дават заглавията на последните му книги, красотата съществува като оръжие. Както в програмното стихотворение „Битката за теб“ (тук давам само финала):

Колкото да премиташ есента пред витрината,
красотата, червена и златна, ще продължава да пада сред теб,
да те саботира.

И ето, нека видим тялото през стъклото на светлината, през красотата:

Тялото е витраж

по стъпалата от пръстите
на краката
светлината пренася своя загадъчен куфар надолу

нагоре

Постепенно те двете се сливат в едно, така както съществуват в реалния свят:

катастрофата и красотата, ужасът и светлината. Това е метафизиката на Марин, това равновесие на ужас и светлина.

Заявява го меко, но категорично. Навсякъде.

Битката продължава, изходът ѝ е нерешен. Всеки нов прочит на Мариновите стихотворения натежава в едната или в другата посока. И сякаш остава у читателя с неговия личен поглед, с неговата лична чувствителност да даде превес.

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

Фетиш

Усърдната природа не прощава:
законът не важи на територията
на тялото

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

И никому не е от полза да споделям,
че опитните ти пети допускат грешки,
че красноречието им смущава…

Каквото да гласува светлината,
петите го престъпват невредими…

Детска книга на непознат език

Post Syndicated from Тоест original https://www.toest.bg/detska-kniga-na-nepoznat-ezik/

Детска книга на непознат език

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

Марин Бодаков (1971–2021) е голям български поет, журналист и преподавател, дългогодишен литературен редактор във в. „Култура“ (2000–2018) и в. „К“ (2018–2019), създател и водещ на рубриката „По буквите“ в „Тоест“ (преди това „Ходене по буквите“ във в. „Култура“). Марин е автор на 9 стихосбирки, сред които „Обявяване на провала“ (2002), „Наивно изкуство“ (2011), „Северна тетрадка“ (2013), „Битката за теб“ (2016), „Мечка страх“ (2018), както и посмъртно издадената „Галерията на сърцето“ (2022). Носител е на националната награда за поезия „Иван Николов“ (2011) и на отличието „Рицар на книгата“ (2014). Посмъртно е удостоен с наградите за цялостен принос „Перото“ (2021) и „Христо Г. Данов“ (2022).

Според Екатерина Йосифова „четящият стихотворение сутрин… добре понася другите часове“ от деня. Убедени, че поезията държи умовете ни будни, а сърцата – отворени, в края на всеки месец ви предлагаме по едно стихотворение. Защото и в най-смутни времена доброто стихотворение е добра новина.

AWS Security Profile: Tatyana Yatskevich, Principal Solutions Architect for AWS Identity

Post Syndicated from Maddie Bacon original https://aws.amazon.com/blogs/security/aws-security-profile-tatyana-yatskevich-principal-solutions-architect-for-aws-identity/

AWS Security Profile: Tatyana Yatskevich, Principal Solutions Architect for AWS Identity

In the AWS Security Profile series, I interview some of the humans who work in AWS Security and help keep our customers safe and secure. In this profile, I interviewed Tatyana Yatskevich, Principal Solutions Architect for AWS Identity.

How long have you been at AWS and what do you do in your current role?

I’ve been at AWS for about five and a half years now. I’ve had several different roles, but I’m currently part of the Identity Solutions team, which is a team of solutions architects who are embedded into the Identity and Control Service. Our team focuses on staying current with customer use cases and emerging problems in the identity space so that we can facilitate the development of new capabilities and prescriptive guidance from AWS.

To keep up with the demand in certain industries, we work with some enterprise customers that operate large cloud environments on AWS. Knowing what these customers need to do to achieve their business outcomes while operating under stringent regulatory compliance requirements helps us provide valuable input into our service and feature development process and support customers in their cloud journey in the most efficient manner.

How did you get started in security?

At the beginning of my career, I mostly just happened to work on security-related projects. I performed security and vulnerability assessments, facilitated remediation work, and managed traditional on-premises security solutions such as web proxies, firewalls, and VPNs. Through these projects, I developed an interest in the security field because of its wide reach and impact, and because it presents a lot of opportunities for growth and problem solving as new challenges arise almost daily. My roles at AWS have been a logical continuation of my security-focused career. Here, I’ve mostly been motivated by empowering security teams to become business enablers, rather than being perceived as blockers to innovation and agility.

How do you explain your job to non-technical friends and family?

I usually give an example of a service or feature that most of us interact with on a regular basis, such as a banking application. I explain that it takes a lot of engineering work to build that application from the ground up and deliver on the user experience and security. That engineering work involves the use of many different technologies that support the user sign-in process, or storage of your personal information like your social security or credit card numbers. My job is to help companies that provide these services implement the proper security controls so that your personal information is used in accordance with local laws and isn’t disclosed for unauthorized use.

In your opinion, what’s one of the coolest things happening in identity right now?

I think it’s the increased role of identity, authentication, and authorization controls in the overall security model of newly built applications. It spans from helping to ensure secure workforce mobility now that providing access to business applications from anywhere is critical to business competitiveness, to keeping Internet of Things (IoT) infrastructure protected and operated in accordance with zero trust. The realization of the power and the increasing usage of identity-specific controls to manage access to digital assets is the coolest trend in identity right now.

What are you currently working on that you’re excited about?

One of the areas that I’m highly invested in is data perimeters. A data perimeter is a set of capabilities that help customers keep their data within their organizational boundary and mitigate the risks of data exfiltration or unintended access to data. We have customers in a wide variety of industries, such as the financial sector, telecom, media and entertainment, and public sector. There are compliance and regulatory requirements that they operate under. A lot of those requirements emphasize controls that guard sensitive data from unauthorized access and prevent movement of that data to places outside of company’s control.

To help customers meet these requirements in a scalable way, we continuously invest in the development of new capabilities. I talk to some of our largest enterprise customers on a regular basis to understand their challenges in this area, and I work with service teams to introduce new capabilities to meet new requirements. I also lead efforts to extend customer-facing guidance and solutions so that customers can design and implement data perimeters on their own. And I present at AWS events to reach more customers, with the most recent being our presentation with Goldman Sachs at re:Invent 2022.

Tell me about that presentation.

I co-presented a chalk talk with Shubham Shukla, Vice President of Cloud Enablement at Goldman Sachs, called Establishing a Data Perimeter on AWS. The session gave an overview of data perimeter capabilities and showcased Goldman Sachs’ experience implementing data perimeter controls at scale in their multi-account AWS environment. What’s cool about that session, I think, is that it’s always good to present about AWS best practices and our view of how certain things should be done, but it’s extra powerful when we include a customer. This is especially true when a large enterprise customer such as Goldman Sachs shares their experience and talks about how they do certain things in practice, like mapping specific requirements to the actual implementation and talking through lessons learned and their perspective on the problem and solution. A lot of our customers are interested in learning from other customers how to build and operate enterprise security controls at scale. We did a similar presentation with Vanguard at re:Inforce 2022, and I look forward to future opportunities to showcase the awesome work being done by our customers.

What is your favorite Amazon Leadership Principle and why?

Customer Obsession. For me, the core of it is building deeper, longer lasting relationships with our customers and taking their learnings back to our business to work backwards from the actual customer needs. Building better products, helping customers meet their business goals, and having wide-reaching impact is what makes me so excited to come to work every day.

What’s the thing you’re most proud of in your career?

As part of my former role as a security consultant in the AWS Professional Services organization, I led security-related projects to either help customers migrate their workloads to AWS or perform security assessments of their existing AWS environment. Part of that role involved developing mechanisms to better engage with customers on security-related topics and help them develop their own security strategy for running workloads on AWS. That work sometimes involved challenging conversations with customers. I would explain the value of the technology that AWS provides and help customers figure out how to implement AWS services to meet both their business and security needs. I took learnings from these conversations and developed some internal assets that helped newer AWS security consultants conduct those conversations more effectively, and I mentored them throughout the process.

If you had to pick an industry outside of security, what would you want to do?

I would be in the travel industry. I absolutely love visiting new places and exploring nature. I love learning the history and culture of different regions, and trying out different cuisines. It’s something that helps me learn more about myself through new experiences and ultimately be a happier person.

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

Want more AWS Security news? Follow us on Twitter.

Author

Maddie Bacon

Maddie (she/her) is a technical writer for Amazon Security with a passion for creating meaningful content that focuses on the human side of security and encourages a security-first mindset. She previously worked as a reporter and editor, and has a BA in Mathematics. In her spare time, she enjoys reading, traveling, and staunchly defending the Oxford comma.

Tatyana Yatskevich

Tatyana Yatskevich

Tatyana is a Principal Solutions Architect in AWS Identity. She works with customers to help them build and operate in AWS in the most secure and efficient manner.

Improved Alerting with Atlas Streaming Eval

Post Syndicated from Netflix Technology Blog original https://netflixtechblog.com/improved-alerting-with-atlas-streaming-eval-e691c60dc61e

Ruchir Jha, Brian Harrington, Yingwu Zhao

TL;DR

  • Streaming alert evaluation scales much better than the traditional approach of polling time-series databases.
  • It allows us to overcome high dimensionality/cardinality limitations of the time-series database.
  • It opens doors to support more exciting use-cases.

Engineers want their alerting system to be realtime, reliable, and actionable. While actionability is subjective and may vary by use-case, reliability is non-negotiable. In other words, false positives are bad but false negatives are the absolute worst!

A few years ago, we were paged by our SRE team due to our Metrics Alerting System falling behind — critical application health alerts reached engineers 45 minutes late! As we investigated the alerting delay, we found that the number of configured alerts had recently increased dramatically, by 5 times! The alerting system queried Atlas, our time series database on a cron for each configured alert query, and was seeing an elevated throttle rate and excessive retries with backoffs. This, in turn, increased the time between two consecutive checks for an alert, causing a global slowdown for all alerts. On further investigation, we discovered that one user had programmatically created tens of thousands of new alerts. This user represented a platform team at Netflix, and their goal was to build alerting automation for their users.

While we were able to put out the immediate fire by disabling the newly created alerts, this incident raised some critical concerns around the scalability of our alerting system. We also heard from other platform teams at Netflix who wanted to build similar automation for their users who, given our state at the time, wouldn’t have been able to do so without impacting Mean Time To Detect (MTTD) for all others. Rather, we were looking at an order of magnitude increase in the number of alert queries just over the next 6 months!

Since querying Atlas was the bottleneck, our first instinct was to scale it up to meet the increased alert query demand; however, we soon realized that would increase Atlas cost prohibitively. Atlas is an in-memory time-series database that ingests multiple billions of time-series per day and retains the last two weeks of data. It is already one of the largest services at Netflix both in size and cost. While Atlas is architected around compute & storage separation, and we could theoretically just scale the query layer to meet the increased query demand, every query, regardless of its type, has a data component that needs to be pushed down to the storage layer. To serve the increasing number of push down queries, the in-memory storage layer would need to scale up as well, and it became clear that this would push the already expensive storage costs far higher. Moreover, common database optimizations like caching recently queried data don’t really work for alerting queries because, generally speaking, the last received datapoint is required for correctness. Take for example, this alert query that checks if errors as a % of total RPS exceeds a threshold of 50% for 4 out of the last 5 minutes:

name,errors,:eq,:sum,
name,rps,:eq,:sum,
:div,
100,:mul,
50,:gt,
5,:rolling-count,4,:gt,

Say if the datapoint received for the last time interval leads to a positive evaluation for this query, relying on stale/cached data would either increase MTTD or result in the perception of a false negative, at least until the missing data is fetched and evaluated. It became clear to us that we needed to solve the scalability problem with a fundamentally different approach. Hence, we started down the path of alert evaluation via real-time streaming metrics.

High Level Architecture

The idea, at a high level, was to avoid the need to query the Atlas database almost entirely and transition most alert queries to streaming evaluation.

Alert queries are submitted either via our Alerting UI or by API clients, which are then saved to a custom config database that supports streaming config updates (full snapshot + update notifications). The Alerting Service receives these config updates and hashes every new or updated alert query for evaluation to one of its nodes by leveraging Edda Slots. The node responsible for evaluating a query, starts by breaking it down into a set of “data expressions” and with them subscribes to an upstream “broker” service. Data expressions define what data needs to be sourced in order to evaluate a query. For the example query listed above, the data expressions are name,errors,:eq,:sum and name,rps,:eq,:sum. The broker service acts as a subscription manager that maps a data expression to a set of subscriptions. In addition, it also maintains a Query Index of all active data expressions which is consulted to discern if an incoming datapoint is of interest to an active subscriber. The internals here are outside the scope of this blog post.

Next, the Alerting service (via the atlas-eval library) maps the received data points for a data expression to the alert query that needs them. For alert queries that resolve to more than one data expression, we align the incoming data points for each one of those data expressions on the same time boundary before emitting the accumulated values to the final eval step. For the example above, the final eval step would be responsible for computing the ratio and maintaining the rolling-count, which is keeping track of the number of intervals in which the ratio crossed the threshold as shown below:

The atlas-eval library supports streaming evaluation for most if not all Query, Data, Math and Stateful operators supported by Atlas today. Certain operators such as offset, integral, des are not supported on the streaming path.

OK, Results?

First and foremost, we have successfully alleviated our initial scalability problem with the polling based architecture. Today, we run 20X the number of queries we used to run a few years ago, with ease and at a fraction of what it would have cost to scale up the Atlas storage layer to serve the same volume. Multiple platform teams at Netflix programmatically generate and maintain alerts on behalf of their users without having to worry about impacting other users of the system. We are able to maintain strong SLAs around Mean Time To Detect (MTTD) regardless of the number of alerts being evaluated by the system.

Additionally, streaming evaluation allowed us to relax restrictions around high cardinality that our users were previously running into — alert queries that were rejected by Atlas Backend before due to cardinality constraints are now getting checked correctly on the streaming path. In addition, we are able to use Atlas Streaming to monitor and alert on some very high cardinality use-cases, such as metrics derived from free-form log data.

Finally, we switched Telltale, our holistic application health monitoring system, from polling a metrics cache to using realtime Atlas Streaming. The fundamental idea behind Telltale is to detect anomalies on SLI metrics (for example, latency, error rates, etc). When such anomalies are detected, Telltale is able to compute correlations with similar metrics emitted from either upstream or downstream services. In addition, it also computes correlations between SLI metrics and custom metrics like the log derived metrics mentioned above. This has proven to be valuable towards reducing Mean Time to Recover (MTTR). For example, we are able to now correlate increased error rates with increased rate of specific exceptions occurring in logs and even point to an exemplar stacktrace, as shown below:

Our logs pipeline fingerprints every log message and attaches a (very high cardinality) fingerprint tag to a log events counter that is then emitted to Atlas Streaming. Telltale consumes this metric in a streaming fashion to identify fingerprints that correlate with anomalies seen in SLI metrics. Once an anomaly is found, we query the logs backend with the fingerprint hash to obtain the exemplar stacktrace. What’s more is we are now able to identify correlated anomalies (and exceptions) occurring in services that may be N hops away from the affected service. A system like Telltale becomes more effective as more services are onboarded (and for that matter the full service graph), because otherwise it becomes difficult to root cause the problem, especially in a microservices-based architecture. A few years ago, as noted in this blog, only about a hundred services were using Telltale; thanks to Atlas Streaming we have now managed to onboard thousands of other services at Netflix.

Finally, we realized that once you remove limits on the number of monitored queries, and start supporting much higher metric dimensionality/cardinality without impacting the cost/performance profile of the system, it opens doors to many exciting new possibilities. For example, to make alerts more actionable, we may now be able to compute correlations between SLI anomalies and custom metrics with high cardinality dimensions, for example an alert on elevated HTTP error rates may be able to point to impacted customer cohorts, by linking to precisely correlated exemplars. This would help developers with reproducibility.

Transitioning to the streaming path has been a long journey for us. One of the challenges was difficulty in debugging scenarios where the streaming path didn’t agree with what is returned by querying the Atlas database. This is especially true when either the data is not available in Atlas or the query is not supported because of (say) cardinality constraints. This is one of the reasons it has taken us years to get here. That said, early signs indicate that the streaming paradigm may help with tackling a cardinal problem in observability — effective correlation between the metrics & events verticals (logs, and potentially traces in the future), and we are excited to explore the opportunities that this presents for Observability in general.

Improved Alerting with Atlas Streaming Eval was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Top strategies for high volume tracing with Amazon OpenSearch Ingestion

Post Syndicated from Muthu Pitchaimani original https://aws.amazon.com/blogs/big-data/top-strategies-for-high-volume-tracing-with-amazon-opensearch-ingestion/

Amazon OpenSearch Ingestion is a serverless, auto-scaled, managed data collector that receives, transforms, and delivers data to Amazon OpenSearch Service domains or Amazon OpenSearch Serverless collections. OpenSearch Ingestion is powered by Data Prepper, an open-source, streaming ETL (extract, transform, and load) solution that’s part of the OpenSearch project. When you use OpenSearch Ingestion, you don’t need to maintain self-managed data pipelines to ingest logs, traces, metrics, and other data with OpenSearch Service. Amazon OpenSearch Ingestion responds to changing volumes of data, automatically scaling your ingest pipeline.

Distributed tracing is the leading way to locate, alert on, and remediate problems with your application and infrastructure. Distributed tracing is part of a broader observability solution, often combined with metrics and log data. OpenSearch Service gives you a native toolset to store and analyze large volumes of log, metric, and trace data. However, moving these large volumes of data is non-trivial to set up, monitor, and maintain.

In this post, we outline steps to set up a trace pipeline and strategies to deal with high volume tracing with Amazon OpenSearch Ingestion.

Solution overview

There is now a new option on the OpenSearch Service console called Pipelines under Ingestion in the navigation pane. We use this feature to create a trace pipeline.

You can also use the AWS Command Line Interface (AWS CLI), AWS CloudFormation, or AWS APIs to create a trace pipeline.

Prerequisites

Refer to Security in OpenSearch Ingestion to set up the permissions you need to create a pipeline and write to a pipeline, and the permissions the pipeline needs to write to a sink.

Create a trace pipeline

To create a trace pipeline, complete the following steps:

  1. On the OpenSearch Service console, choose Pipelines under Ingestion in the navigation pane.
  2. Choose Create pipeline.

Amazon OpenSearch Ingestion, powered by Data Prepper, uses pipelines as a mechanism to move the data from a source to a sink, with optional processors to mutate, route, sample, and detect anomalies for the data in the pipe. For more information, refer to Data Prepper. When you use Data Prepper, you build a YAML configuration file. When you use OpenSearch Ingestion, you upload your YAML configuration to the service. If you’re using the OpenSearch Service console, you can use one of the configuration blueprints that we provide. For distributed tracing, you will use an otel_trace_source and an OpenSearch Service domain as the sink.

  1. On the Configuration blueprints menu, choose AWS-TraceAnalyticsPipeline.

Choosing this blueprint will create a sample pipeline with otel_trace_source, an OpenSearch sink, along with span-pipeline and service-map-pipeline.

  1. Enter a name for this pipeline along with a minimum (1) and maximum (96) capacity value for Ingestion-OCUs.

Amazon OpenSearch Ingestion will scale automatically between these values to suit the volume of data you are ingesting.

  1. Edit the configuration’s hosts, aws.sts_role_arn, and region fields of the OpenSearch Service sink.
  2. Follow rest of the steps to complete the trace pipeline creation.

Sample trace pipeline

The following code shows the components of a sample trace pipeline:

version: "2"
entry-pipeline: 
  source:
    otel_trace_source:
      path: "/${pipelineName}/v1/traces"
  processor:
    - trace_peer_forwarder:
  sink:
    - pipeline:
        name: "span-pipeline"
    - pipeline:
        name: "service-map-pipeline"
span-pipeline:
  source:
    pipeline:
      name: "entry-pipeline"
  processor:
    - otel_trace_raw:
  sink:
    - opensearch:
        hosts: [ "https://search-mydomain-1a2a3a4a5a6a7a8a9a0a9a8a7a.us-east-1.es.amazonaws.com" ]
        aws:
          sts_role_arn: "arn:aws:iam::123456789012:role/Example-Role"
          region: "us-east-1"
        index_type: "trace-analytics-raw"
service-map-pipeline:
  source:
    pipeline:
      name: "entry-pipeline"
  processor:
    - service_map_stateful:
  sink:
    - opensearch:
        hosts: [ "https://search-mydomain-1a2a3a4a5a6a7a8a9a0a9a8a7a.us-east-1.es.amazonaws.com" ]
        aws:
          sts_role_arn: "arn:aws:iam::123456789012:role/Example-Role"
          region: "us-east-1"
        index_type: "trace-analytics-service-map"

The sample trace pipeline has three sub-pipelines in its configuration. These are entry-pipeline, span-pipeline, and service-map-pipeline. The following diagram illustrates the workflow.

entry-pipeline specifies the source of data as otel_trace_source, which creates an HTTP listener for receiving OpenTelemetry traces at the ingestion URL for the pipeline. You use a trace_peer_forwarder processor to eliminate duplicate HTTP requests and forward the data to the span-pipeline and service-map pipelines. span-pipeline gets the raw trace data from entry-pipeline and uses the otel_trace_raw processor to complete trace group-related fields for the incoming span records. You use the service_map_stateful processor to have Data Prepper create the distributed service map for visualization in OpenSearch Dashboards. After the sample trace pipeline is created, it’s ready to receive OpenTelemetry traces at its ingestion URL!

Reduce your storage footprint and optimize for cost

The volume of traces collected from instrumenting a modern production enterprise application can reach tens or hundreds of terabytes very quickly, especially when you store every trace from every request. The problem of managing the storage footprint becomes important. In this section, we discuss strategies for reducing your storage footprint and optimizing for cost.

Use storage tiering

OpenSearch Service has three storage tiers: hot, UltraWarm, and cold. You use the hot tier to store frequently accessed data for quick reading and writing, the UltraWarm tier for infrequently used, read-only data backed by Amazon Simple Storage Service (Amazon S3) for lower cost, and the cold tier to maintain re-attachable data at near-Amazon S3 cost. By adjusting relative retention periods between these tiers, you can store a high volume of traces. For example, instead of storing 1 weeks’ worth of traces in the hot tier, you can store 2 days of traces in the hot tier and 15 days in the UltraWarm tier.

Extract metrics without storing traces

You can also use Data Prepper’s aggregation process to extract metrics in the pipeline to avoid delivering all of your data to OpenSearch Service. For example, you may want to analyze request, error, and duration (RED) metrics of your traces to know the current state of your services. OpenSearch Ingestion can calculate these metrics in the pipeline, aggregating them and storing them in separate indexes for analysis, reducing the ingestion and storage footprint of your traces. The following pipeline configuration snippet shows how to use the aggregate processor to calculate a histogram of the duration metric:

...
  processor:
    - aggregate:
        identification_keys: ["serviceName", "traceId"]
        action:
          histogram:
            key: "durationInNanos"
            record_minmax: true
            units: "nanoseconds"
            buckets: [1000000000, 1500000000, 2000000000]
        group_duration: "20s"
   sink:
    - opensearch:
        hosts: ...
        aws_sts_role_arn: ...
        aws_region: ...
        aws_sigv4: true
        index: "red_metrics_from_traces"
  ...

Use sampling

When your application is running without issues, the proportion of error traces is just a small percentage of your overall trace volume. Storing all of the traces for successful requests increases the cost substantially, while offering low value. To reduce cost, you can sample your trace data, reducing the number of traces you store in OpenSearch Service. There are generally two techniques for sampling:

  • Head sampling – When you do head sampling, you ask OpenSearch Ingestion to make a sampling decision without looking at the whole trace. Head sampling is easy to configure and is efficient, but has a downside of possibly missing important traces.
  • Tail sampling – Tail sampling is where you analyze the entirety of the trace and then decide whether to sample the trace or not. This accurately captures all the needed traces at the cost of complexity in configuring and implementing.

The following configuration snippet shows an example of the percent_sampler, from the aggregate processor. In this example, you send only 25% of your traces to OpenSearch Service, based on head sampling:

  ...
  processor:
    - aggregate:
        identification_keys: ["serviceName"]
        action:
          percent_sampler:
            percent: 25
        group_duration: "30s"
  sink:
    - opensearch:
        hosts: ...
        aws_sts_role_arn: ...
        aws_region: ...
        aws_sigv4: true
        index: "sampled-traces"
  ...

Use conditional routing with sampling

Head sampling using the percentage_sampler is simple and straightforward, but is a blunt tool. A better way to sample would be to gather, for example, 10% of successful responses, and 100% of failed responses or 100% high duration traces. To solve this, use conditional routing. Routes define conditions that can be used within processors and sinks to direct the data flowing through different parts of pipeline. For example, the following configuration snippet routes traces whose status code indicates a failure to the error_trace pipeline. You forward 100% of the data in that pipe. You route traces whose duration metric is more than 1 second to the high_latency pipeline where you sample them at 80%. Other normal traces are only sampled at 20%.

  processor:
    - otel_trace_raw:
  route:
    - error_traces: "/traceGroupFields/statusCode == 2"
    - high_latency_traces: '/durationInNanos >= 1000000000'
    - normal_traces: '/traceGroupFields/statusCode!= 2 and /durationInNanos < 1000000000'
  sink:
    - pipeline:
        name: "trace-error-pipeline"
        routes:
          - error_traces
    - pipeline: 
        name: "trace-high-latency-metrics-pipeline"
        routes: 
          - high_latency_traces
    - pipeline: 
        name: "trace-normal-pipeline"
        routes: 
          - normal_traces
  ...

Conclusion

In this post, you learned how to configure an OpenSearch Ingestion pipeline and several strategies to keep in mind that help minimize cost while supporting a large-scale production system for distributed tracing. As next step, refer to the Amazon OpenSearch Developer Guide to explore logs and metric pipelines that you can use to build a scalable observability solution for your enterprise applications.

About the author

Muthu Pitchaimani is a Search Specialist with Amazon OpenSearch Service. He builds large-scale search applications and solutions. Muthu is interested in the topics of networking and security, and is based out of Austin, Texas.

How CyberCRX cut ML processing time from 8 days to 56 minutes with AWS Step Functions Distributed Map

Post Syndicated from Marcia Villalba original https://aws.amazon.com/blogs/aws/how-cybercrx-cut-ml-processing-time-from-8-days-to-56-minutes-with-aws-step-functions-distributed-map/

Last December, Sébastien Stormacq wrote about the availability of a distributed map state for AWS Step Functions, a new feature that allows you to orchestrate large-scale parallel workloads in the cloud. That’s when Charles Burton, a data systems engineer for a company called CyberGRX, found out about it and refactored his workflow, reducing the processing time for his machine learning (ML) processing job from 8 days to 56 minutes. Before, running the job required an engineer to constantly monitor it; now, it runs in less than an hour with no support needed. In addition, the new implementation with AWS Step Functions Distributed Map costs less than what it did originally.

What CyberGRX achieved with this solution is a perfect example of what serverless technologies embrace: letting the cloud do as much of the undifferentiated heavy lifting as possible so the engineers and data scientists have more time to focus on what’s important for the business. In this case, that means continuing to improve the model and the processes for one of the key offerings from CyberGRX, a cyber risk assessment of third parties using ML insights from its large and growing database.

What’s the business challenge?
CyberGRX shares third-party cyber risk (TPCRM) data with their customers. They predict, with high confidence, how a third-party company will respond to a risk assessment questionnaire. To do this, they have to run their predictive model on every company in their platform; they currently have predictive data on more than 225,000 companies. Whenever there’s a new company or the data changes for a company, they regenerate their predictive model by processing their entire dataset. Over time, CyberGRX data scientists improve the model or add new features to it, which also requires the model to be regenerated.

The challenge is running this job for 225,000 companies in a timely manner, with as few hands-on resources as possible. The job runs a set of operations for each company, and every company calculation is independent of other companies. This means that in the ideal case, every company can be processed at the same time. However, implementing such a massive parallelization is a challenging problem to solve.

First iteration
With that in mind, the company built their first iteration of the pipeline using Kubernetes and Argo Workflows, an open-source container-native workflow engine for orchestrating parallel jobs on Kubernetes. These were tools they were familiar with, as they were already using them in their infrastructure.

But as soon as they tried to run the job for all the companies on the platform, they ran up against the limits of what their system could handle efficiently. Because the solution depended on a centralized controller, Argo Workflows, it was not robust, and the controller was scaled to its maximum capacity during this time. At that time, they only had 150,000 companies. And running the job with all of the companies took around 8 days, during which the system would crash and need to be restarted. It was very labor intensive, and it always required an engineer on call to monitor and troubleshoot the job.

The tipping point came when Charles joined the Analytics team at the beginning of 2022. One of his first tasks was to do a full model run on approximately 170,000 companies at that time. The model run lasted the whole week and ended at 2:00 AM on a Sunday. That’s when he decided their system needed to evolve.

Second iteration
With the pain of the last time he ran the model fresh in his mind, Charles thought through how he could rewrite the workflow. His first thought was to use AWS Lambda and SQS, but he realized that he needed an orchestrator in that solution. That’s why he chose Step Functions, a serverless service that helps you automate processes, orchestrate microservices, and create data and ML pipelines; plus, it scales as needed.

Charles got the new version of the workflow with Step Functions working in about 2 weeks. The first step he took was adapting his existing Docker image to run in Lambda using Lambda’s container image packaging format. Because the container already worked for his data processing tasks, this update was simple. He scheduled Lambda provisioned concurrency to make sure that all functions he needed were ready when he started the job. He also configured reserved concurrency to make sure that Lambda would be able to handle this maximum number of concurrent executions at a time. In order to support so many functions executing at the same time, he raised the concurrent execution quota for Lambda per account.

And to make sure that the steps were run in parallel, he used Step Functions and the map state. The map state allowed Charles to run a set of workflow steps for each item in a dataset. The iterations run in parallel. Because Step Functions map state offers 40 concurrent executions and CyberGRX needed more parallelization, they created a solution that launched multiple state machines in parallel; in this way, they were able to iterate fast across all the companies. Creating this complex solution, required a preprocessor that handled the heuristics of the concurrency of the system and split the input data across multiple state machines.

This second iteration was already better than the first one, as now it was able to finish the execution with no problems, and it could iterate over 200,000 companies in 90 minutes. However, the preprocessor was a very complex part of the system, and it was hitting the limits of the Lambda and Step Functions APIs due to the amount of parallelization.

Second iteration with AWS Step Functions

Third and final iteration
Then, during AWS re:Invent 2022, AWS announced a distributed map for Step Functions, a new type of map state that allows you to write Step Functions to coordinate large-scale parallel workloads. Using this new feature, you can easily iterate over millions of objects stored in Amazon Simple Storage Service (Amazon S3), and then the distributed map can launch up to 10,000 parallel sub-workflows to process the data.

When Charles read in the News Blog article about the 10,000 parallel workflow executions, he immediately thought about trying this new state. In a couple of weeks, Charles built the new iteration of the workflow.

Because the distributed map state split the input into different processors and handled the concurrency of the different executions, Charles was able to drop the complex preprocessor code.

The new process was the simplest that it’s ever been; now whenever they want to run the job, they just upload a file to Amazon S3 with the input data. This action triggers an Amazon EventBridge rule that targets the state machine with the distributed map. The state machine then executes with that file as an input and publishes the results to an Amazon Simple Notification Service (Amazon SNS) topic.

Final iteration with AWS Step Functions

What was the impact?
A few weeks after completing the third iteration, they had to run the job on all 227,000 companies in their platform. When the job finished, Charles’ team was blown away; the whole process took only 56 minutes to complete. They estimated that during those 56 minutes, the job ran more than 57 billion calculations.

Processing of the Distributed Map State

The following image shows an Amazon CloudWatch graph of the concurrent executions for one Lambda function during the time that the workflow was running. There are almost 10,000 functions running in parallel during this time.

Lambda concurrency CloudWatch graph

Simplifying and shortening the time to run the job opens a lot of possibilities for CyberGRX and the data science team. The benefits started right away the moment one of the data scientists wanted to run the job to test some improvements they had made for the model. They were able to run it independently without requiring an engineer to help them.

And, because the predictive model itself is one of the key offerings from CyberGRX, the company now has a more competitive product since the predictive analysis can be refined on a daily basis.

Learn more about using AWS Step Functions:

You can also check the Serverless Workflows Collection that we have available in Serverless Land for you to test and learn more about this new capability.

— Marcia

Best Practices for managing data residency in AWS Local Zones using landing zone controls

Post Syndicated from Sheila Busser original https://aws.amazon.com/blogs/compute/best-practices-for-managing-data-residency-in-aws-local-zones-using-landing-zone-controls/

This blog post is written by Abeer Naffa’, Sr. Solutions Architect, Solutions Builder AWS, David Filiatrault, Principal Security Consultant, and Jared Thompson Hybrid Edge SA Specialist.

In this post, we discuss how you can leverage AWS Control Tower landing zone and AWS Organizations custom policies – guardrails – at the root level, known as Service Control Policies (SCPS) to enable certain data residency requirements on AWS Local Zones. Using the suggested controls lets you limit the ability to store data, process data outside a geographic location, and keep your data within specific Local Zone(s).

Data residency is a critical consideration for organizations that collect and store sensitive information, such as Personal Identifiable Information (PII), financial data, and healthcare data. With the rise of cloud computing and the global nature of the Internet, it can be challenging for organizations to make sure that their data is being stored and processed in compliance with local laws and regulations.

One potential solution for addressing data residency challenges with AWS is utilizing Local Zones, which places AWS infrastructure in large metro areas. This enables organizations to store and process data in specific geographic locations. By using Local Zones, organizations can architect their environment to meet data residency requirements when an AWS Region is unavailable within the same legal jurisdiction. Local Zones can be configured to utilize landing zone to further adhere to data residency requirements.

A landing zone is a well-architected, multi-account AWS environment that is scalable and secure. This is a starting point from which your organization can quickly launch and deploy workloads and applications with confidence in your security and infrastructure environment.

When leveraging a Local Zone to meet data residency requirements, you must have control over the in-scope data movement from the Local Zones to the AWS Region. This can be accomplished by implementing landing zone best practices and the suggested guardrails. The main focus of this post is the custom policies that restrict data snapshots, prohibit data creation within the Region, and limit data transfer to the Region. Furthermore, this post covers which prerequisites organizations should consider before implementing these guardrails.

Prerequisites

Landing zones best practices and custom guardrails can help when data must remain in a specific locality where the Local Zone is also located. This can be completed by defining and enforcing policies for data storage and usage within the landing zone organization that you set up. The following prerequisites should be considered before implementing the suggested guardrails:

  1. AWS Local Zones

Local Zones are enabled through the Amazon Elastic Compute Cloud (Amazon EC2) console or the AWS Command Line Interface (AWS CLI).

You can start using available AWS services on the designated Local Zone directly from the console. Moreover, you can manage the Local Zone using the same tools and interfaces that you use in AWS Region.

2. AWS Control Tower landing zone

AWS Control Tower is a managed service that provides a pre-packaged set of best-practice blueprints for setting up and governing multi-account AWS environments. You must have Control Tower fully implemented in your environment before you can deploy custom guardrails.

Control Tower launches a key resource associated with your account, called a landing zone, which serves as a home for your organizations and their accounts.

Note that Control Tower relies on Organizations to create and manage multi-account structures.

  1. Set up the data residency guardrails

Using Organizations, you must make sure that the Local Zone is enabled within a workload account in the landing zones.

Figure 1 Landing Zones Accelerator Local Zones workload on AWS high level Architecture

Figure 1: Landing Zones Accelerator – Local Zones workload on AWS high level Architecture

Utilizing Local Zones for regulated components

The availability of Local Zones provides an excellent opportunity to meet data residency requirements and comply with local regulations that restrict the use of the Region outside of your required geo-political boundary. By leveraging Local Zones, organizations can maintain compliance while utilizing AWS services to support their business needs. AWS owns and manages the infrastructure, including hardware, software, and networking for Local Zones. However, as part of the shared responsibility model, customers are responsible for the security of their applications and data, including access control, data encryption, etc.

You must also comply with all applicable regulations and security standards, such as HIPAA, PCI DSS, and GDPR. You should conduct regular security assessments and implement appropriate security controls to protect their applications and data.

In this post, we consider a scenario where there is a single Local Zones location in a metro. However, you must analyze the specific requirements of your workloads and the relevant regulations that apply to determine the most appropriate high availability configurations for your case.

Local Zones workload data residency guardrails

Organizations provides central governance and management for multiple accounts. Central security administrators use SCPs with Organizations to establish controls to which all AWS Identity and Access Management (IAM) principals (users and roles) adhere.

Now you can use SCPs to set permission guardrails. The suggested preventative controls that leverage the implementation of SCPs for data residency on Local Zones are shown in the next paragraph. SCPs let you set permission guardrails by defining the maximum available permissions for IAM entities in an account and all accounts within the Organization root or Organizational Unit (OU). If an SCP denies an action for an account, then none of the entities in any member account, including the member account’s root user, can take that action, even if their IAM permissions let them. The guardrails set in SCPs apply to all IAM entities in the account, which include all users, roles, and the account root user.

 Upon finalizing these prerequisites, you can create the guardrails for the chosen OU.

Note that although the following guidelines serve as helpful guardrails – SCPs – for data residency, you should consult internally with legal and security teams for specific organizational requirements.

 To exercise better control over the workload in Local Zones and prevent data transfer from Local Zones or data storage outside of the Local Zones, consider implementing the following guardrails:

  1. When your data residency requirements require restricting data transfer/saving to the Region, consider the following guardrails:

a. Deny copying data from Local Zones to the Region for Amazon EC2), Amazon Relational Database Service (Amazon RDS), Amazon ElastiCache, and data sync “DenyCopyToRegion”.

As the available services in Local Zones can vary based on location, you must review the services available in the chosen Local Zone and Adjust the SCPs accordingly.

b. Deny Amazon Simple Storage Service (Amazon S3) put action to the Region “DenyPutObjectToRegionalBuckets”.

If your data residency requirements mandate restrictions on data storage in the Region, then consider implementing this guardrail to prevent the use of Amazon S3 in the Region.

c. If your data residency requirements mandate restrictions on data storage in the Region, then consider implementing “DenyDirectTransferToRegion”

Out of Scope is metadata such as tags or operational data such as AWS Key Management Service (AWS KMS) keys.

 
{
  "Version": "2012-10-17",
  "Statement": [
      {
      "Sid": "DenyCopyToRegion",
      "Action": [
        "ec2:ModifyImageAttribute",
        "ec2:CopyImage",  
        "ec2:CreateImage",
        "ec2:CreateInstanceExportTask",
        "ec2:ExportImage",
        "ec2:ImportImage",
        "ec2:ImportInstance",
        "ec2:ImportSnapshot",
        "ec2:ImportVolume",
        "rds:CreateDBSnapshot",
        "rds:CreateDBClusterSnapshot",
        "rds:ModifyDBSnapshotAttribute",
        "elasticache:CreateSnapshot",
        "elasticache:CopySnapshot",
        "datasync:Create*",
        "datasync:Update*"
      ],
      "Resource": "*",
      "Effect": "Deny"
    },
    {
      "Sid": "DenyDirectTransferToRegion",
      "Action": [
        "dynamodb:PutItem",
        "dynamodb:CreateTable",
        "ec2:CreateTrafficMirrorTarget",
        "ec2:CreateTrafficMirrorSession",
        "rds:CreateGlobalCluster",
        "es:Create*",
        "elasticfilesystem:C*",
        "elasticfilesystem:Put*",
        "storagegateway:Create*",
        "neptune-db:connect",
        "glue:CreateDevEndpoint",
        "glue:UpdateDevEndpoint",
        "datapipeline:CreatePipeline",
        "datapipeline:PutPipelineDefinition",
        "sagemaker:CreateAutoMLJob",
        "sagemaker:CreateData*",
        "sagemaker:CreateCode*",
        "sagemaker:CreateEndpoint",
        "sagemaker:CreateDomain",
        "sagemaker:CreateEdgePackagingJob",
        "sagemaker:CreateNotebookInstance",
        "sagemaker:CreateProcessingJob",
        "sagemaker:CreateModel*",
        "sagemaker:CreateTra*",
        "sagemaker:Update*",
        "redshift:CreateCluster*",
        "ses:Send*",
        "ses:Create*",
        "sqs:Create*",
        "sqs:Send*",
        "mq:Create*",
        "cloudfront:Create*",
        "cloudfront:Update*",
        "ecr:Put*",
        "ecr:Create*",
        "ecr:Upload*",
        "ram:AcceptResourceShareInvitation"
      ],
      "Resource": "*",
      "Effect": "Deny"
    },
    {
      "Sid": "DenyPutObjectToRegionalBuckets",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": ["arn:aws:s3:::*"],
      "Effect": "Deny"
    }
  ]
}
  1. If your data residency requirements require limitations on data storage in the Region, then consider implementing this guardrail “DenyAllSnapshots” to restrict the use of snapshots in the Region.

Note that the following guardrail restricts the creation of snapshots on AWS Outposts as well. If you’re using Outposts in the same AWS account, then you may need to customize this guardrail to make sure that it aligns with your organization’s specific needs and requirements. For more information on data residency considerations for Outposts, please refer to Architecting for data residency with AWS Outposts rack and landing zone guardrails.

 
{
  "Version": "2012-10-17",
  "Statement": [

    {
      "Sid": "DenyAllSnapshots",
      "Effect":"Deny",
      "Action":[
        "ec2:CreateSnapshot",
        "ec2:CreateSnapshots",
        "ec2:CopySnapshot",
        "ec2:ModifySnapshotAttribute"
      ],
      "Resource":"arn:aws:ec2:*::snapshot/*"
    }
  ]
}
  1. This guardrail helps prevent the launch of EC2 instances or the creation of network interfaces by subnet as opposed to Local Zones You should keep data residency workloads within the Local Zones rather than the Region to make sure of better control over regulated workloads. This approach can help your organization achieve better control over data residency workloads and improve governance over your Organization.

 Make sure to update the Local Zones subnets < localzones_subnet_arns>.

{
"Version": "2012-10-17",
  "Statement":[{
    "Sid": "DenyNotLocalZonesSubnet",
    "Effect":"Deny",
    "Action": [
      "ec2:RunInstances",
      "ec2:CreateNetworkInterface"
    ],
    "Resource": [
      "arn:aws:ec2:*:*:network-interface/*"
    ],
    "Condition": {
      "ForAllValues:ArnNotEquals": {
        "ec2:Subnet": ["<localzones_subnet_arns>"]
      }
    }
  }]
}

Additional considerations

When implementing data residency guardrails on Local Zones, consider backup and disaster recovery strategies to make sure that your data is protected in the event of an outage or other unexpected events. This may include creating regular backups of your data, implementing disaster recovery plans and procedures, and using redundancy and failover systems to minimize the impact of any potential disruptions. Additionally, you should make sure that your backup and disaster recovery systems are compliant with any relevant data residency regulations and requirements. You should also test your backup and disaster recovery systems regularly to make sure that they are functioning as intended.

Additionally, the provided SCPs for Local Zones in the above example do not block the “logs:PutLogEvents”. Therefore, even if you implemented data residency guardrails on Local Zones, the application may log data to Amazon CloudWatch Logs in the Region.

Highlights

By default, application-level logs on Local Zones are not automatically sent to CloudWatch Logs in the Region. You can configure CloudWatch Logs agent on Local Zones to collect and send your application-level logs to CloudWatch Logs.

logs:PutLogEvents does transmit data to the Region, but it is not blocked by the provided SCPs, as it’s expected that most use cases still want to be able to use this logging API. However, if blocking is desired, then add the action to the first recommended guardrail. If you want specific roles to be allowed, then combine with the ArnNotLike condition example referenced in the Customization Guide.

Conclusion

The combined use of Local Zones and the suggested guardrails via Organizations policies enables you to exercise better control over the movement of the data. By creating a landing zone for your organization, you can apply SCPs to your Local Zones that will help make sure that your data remains within a specific geographic location, as required by the data residency regulations.

Note that, although custom guardrails can help you manage data residency on Local Zones, it’s critical to thoroughly review your policies, procedures, and configurations. This lets you make sure that they are compliant with all relevant data residency regulations and requirements. Regularly testing and monitoring your systems can help make sure that your data is protected and your organization stays compliant.

References

The collective thoughts of the interwebz