Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=0nr7cJRsTVg
Linux Mint 21.1 (“Vera”) released
Post Syndicated from original https://lwn.net/Articles/918251/
Linux Mint has announced the release of version 21.1 of the distribution in three editions: Cinnamon (what’s new), MATE (what’s new), and Xfce (what’s new).
Mint 21.1 is based on Ubuntu 22.04 and uses kernel version 5.15.
Linux Mint 21.1 is a long term support release which will be supported until 2027. It comes with updated software and brings refinements and many new features to make your desktop even more comfortable to use.
Trojaned Windows Installer Targets Ukraine
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/12/trojaned-windows-installer-targets-ukraine.html
Mandiant is reporting on a trojaned Windows installer that targets Ukrainian users. The installer was left on various torrent sites, presumably ensnaring people downloading pirated copies of the operating system:
Mandiant uncovered a socially engineered supply chain operation focused on Ukrainian government entities that leveraged trojanized ISO files masquerading as legitimate Windows 10 Operating System installers. The trojanized ISOs were hosted on Ukrainian- and Russian-language torrent file sharing sites. Upon installation of the compromised software, the malware gathers information on the compromised system and exfiltrates it. At a subset of victims, additional tools are deployed to enable further intelligence gathering. In some instances, we discovered additional payloads that were likely deployed following initial reconnaissance including the STOWAWAY, BEACON, and SPAREPART backdoors.
One obvious solution would be for Microsoft to give the Ukrainians Windows licenses, so they don’t have to get their software from sketchy torrent sites.
ICYMI: 10 cybersecurity acronyms you should know in 2023
Post Syndicated from Drew Burton original https://blog.rapid7.com/2022/12/20/icymi-10-cybersecurity-acronyms-you-should-know-in-2023/

Cybersecurity is acronym-heavy to say the least. If you’re reading this, you already know. From CVE to FTP, we in IT love our abbreviations, FR FR. Truthfully though, it can be a bit much, and even the nerdiest among us miss a few. So, In Case You Missed It, here are 10 cybersecurity acronyms you should know IRL, err in 2023.
HUMINT
Peppermint on a sticky day? How dare you. HUMINT is short for Human Intelligence. This abbreviation refers to information collected by threat researchers from sources across the clear, deep and dark web. Real people doing real things, you might say. These folks are out there hunting down potential threats and stopping them before they occur. Pretty cool stuff, TBH.
CSPM
Cloud Security Posture Management tools include use cases for compliance assessment, operational monitoring, DevOps integrations, incident response, risk identification, and risk visualization. Good posture: so hot RN.
IAM
Not the guy with the green eggs, this IAM stands for Identity and Access Management. CSO online says IAM is a “set of processes, policies, and tools for defining and managing the roles and access privileges of individual network entities (users and devices) to a variety of cloud and on-premises applications’. Green Eggs and Ham didn’t age well IMO, Sam was kind of a bully. JK JK.

XDR
AKA Extended Detection and Response. Forrester calls XDR the “evolution of endpoint detection and response”. Gartner says it’s integrating “multiple security products into a cohesive security operations system”. Essentially, XDR is about taking a holistic approach to more efficient, effective detection and response. It’s definitely not an Xtreme Dude Ranch. That’s just absurd.
XSPM
According to Hacker News, “Extended Security Posture Management is a multilayered process combining the capabilities of Attack Surface Management (ASM), Breach and Attack Simulation (BAS), Continuous Automated Red Teaming (CART), and Purple Teaming to continuously evaluate and score the infrastructure’s overall cyber resiliency.” Yes, that definition includes three additional acronyms. Plus, one of them is CART, SMH.
RASP
Runtime application self-protection tools can block malicious activity while an application is in production. If RASP detects a security event such as an attempt to run a shell, open a file, or call a database, it will automatically attempt to terminate that action, NBD.
MDR
Managed Detection and Response providers deliver technology and human expertise to perform threat hunting, monitoring, and response. The main benefit of MDR is that it helps organizations limit the impact of threats without the need for additional staffing. In other words, they are free to TCB instead of worrying about security stuff.
MSSP
A Managed Security Service Provider provides outsourced monitoring and management of security devices and systems. MSSPs deliver managed firewall, intrusion detection, virtual private network, vulnerability scanning, and other services. Oh BTW, sometimes MSSPs partner with MDR vendors to deliver services to their customers.
DAST
Dynamic Application Security Testing is the process of analyzing a web application to find vulnerabilities through simulated attacks. DAST is all about finding vulnerabilities in web applications and correcting them before they can be exploited by threat actors. A dastardly deed conducted with no ill will … if you will.
WAF
A Web Application Firewall is a type of firewall that filters, monitors, and blocks HTTP traffic to and from a web service. It is designed to prevent attacks exploiting a web application’s known vulnerabilities, such as SQL injection, cross-site scripting, file inclusion, and improper system configuration. Proper WAF definition there, zero Cardi B jokes. Those are NSFW.
Run fault tolerant and cost-optimized Spark clusters using Amazon EMR on EKS and Amazon EC2 Spot Instances
Post Syndicated from Kinnar Kumar Sen original https://aws.amazon.com/blogs/big-data/run-fault-tolerant-and-cost-optimized-spark-clusters-using-amazon-emr-on-eks-and-amazon-ec2-spot-instances/
Amazon EMR on EKS is a deployment option in Amazon EMR that allows you to run Spark jobs on Amazon Elastic Kubernetes Service (Amazon EKS). Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances save you up to 90% over On-Demand Instances, and is a great way to cost optimize the Spark workloads running on Amazon EMR on EKS. Because Spot is an interruptible service, if we can move or reuse the intermediate shuffle files, it improves the overall stability and SLA of the job. The latest versions of Amazon EMR on EKS have integrated Spark features to enable this capability.
In this post, we discuss these features—Node Decommissioning and Persistent Volume Claim (PVC) reuse—and their impact on increasing the fault tolerance of Spark jobs on Amazon EMR on EKS when cost optimizing using EC2 Spot Instances.
Amazon EMR on EKS and Spot
EC2 Spot Instances are spare EC2 capacity provided at a steep discount of up to 90% over On-Demand prices. Spot Instances are a great choice for stateless and flexible workloads. The caveat with this discount and spare capacity is that Amazon EC2 can interrupt an instance with a proactive or reactive (2-minute) warning when it needs the capacity back. You can provision compute capacity in an EKS cluster using Spot Instances using a managed or self-managed node group and provide cost optimization for your workloads.
Amazon EMR on EKS uses Amazon EKS to run jobs with the EMR runtime for Apache Spark, which can be cost optimized by running the Spark executors on Spot. It provides up to 61% lower costs and up to 68% performance improvement for Spark workloads on Amazon EKS. The Spark application launches a driver and executors to run the computation. Spark is a semi-fault tolerant framework that is resilient to executor loss due to an interruption and therefore can run on EC2 Spot. On the other hand, when the driver is interrupted, the job fails. Hence, we recommend running drivers on on-demand instances. Some of the best practices for running Spark on Amazon EKS are applicable with Amazon EMR on EKS.
EC2 Spot instances also helps in cost optimization by improving the overall throughput of the job. This can be achieved by auto-scaling the cluster using Cluster Autoscaler (for managed nodegroups) or Karpenter.
Though Spark executors are resilient to Spot interruptions, the shuffle files and RDD data is lost when the executor gets killed. The lost shuffle files need to be recomputed, which increases the overall runtime of the job. Apache Spark has released two features (in versions 3.1 and 3.2) that addresses this issue. Amazon EMR on EKS released features such as node decommissioning (version 6.3) and PVC reuse (version 6.8) to simplify recovery and reuse shuffle files, which increases the overall resiliency of your application.
Node decommissioning
The node decommissioning feature works by preventing scheduling of new jobs on the nodes that are to be decommissioned. It also moves any shuffle files or cache present in those nodes to other executors (peers). If there are no other available executors, the shuffle files and cache are moved to a remote fallback storage.
Fig 1 : Node Decommissioning
Let’s look at the decommission steps in more detail.
If one of the nodes that is running executors is interrupted, the executor starts the process of decommissioning and sends the message to the driver:
The executor looks for RDD or shuffle files and tries to replicate or migrate those files. It first tries to find a peer executor. If successful, it will move the files to the peer executor:
However, if It is not able to find a peer executor, it will try to move the files to a fallback storage if available.
Fig 2: Fallback Storage
The executor is then decommissioned. When a new executor comes up, the shuffle files are reused:
The key advantage of this process is that it enables migrates blocks and shuffle data, thereby reducing recomputation, which adds to the overall resiliency of the system and reduces runtime. This process can be triggered by a Spot interruption signal (Sigterm) and node draining. Node draining may happen due to high-priority task scheduling or independently.
When you use Amazon EMR on EKS with managed node groups/Karpenter, the Spot interruption handling is automated, wherein Amazon EKS gracefully drains and rebalances the Spot nodes to minimize application disruption when a Spot node is at elevated risk of interruption. If you’re using managed node groups/Karpenter, the decommission gets triggered when the nodes are getting drained and because it’s proactive, it gives you more time (at least 2 minutes) to move the files. In the case of self-managed node groups, we recommend installing the AWS Node Termination Handler to handle the interruption, and the decommission is triggered when the reactive (2-minute) notification is received. We recommend to use Karpenter with Spot Instances as it has faster node scheduling with early pod binding and binpacking to optimize the resource utilization.
The following code enables this configuration; more details are available on GitHub:
PVC reuse
Apache Spark enabled dynamic PVC in version 3.1, which is useful with dynamic allocation because we don’t have to pre-create the claims or volumes for the executors and delete them after completion. PVC enables true decoupling of data and processing when we’re running Spark jobs on Kubernetes, because we can use it as a local storage to spill in-process files too. The latest version of Amazon EMR 6.8 has integrated the PVC reuse feature of Spark, wherein if an executor is terminated due to EC2 Spot interruption or any other reason (JVM), then the PVC is not deleted but persisted and reattached to another executor. If there are shuffle files in that volume, then they are reused.
As with node decommission, this reduces the overall runtime because we don’t have to recompute the shuffle files. We also save the time required to request a new volume for an executor, and shuffle files can be reused without moving the files round.
The following diagram illustrates this workflow.
Fig 3: PVC Reuse
Let’s look at the steps in more detail.
If one or more of the nodes that are running executors is interrupted, the underlying pods get terminated and the driver gets the update. Note that the driver is the owner of the PVC of the executors, and they are not terminated. See the following code:
The ExecutorPodsAllocator tries to allocate new executor pods to replace the ones terminated due to interruption. During the allocation, it figures out how many of the existing PVCs have files and can be reused:
The ExecutorPodsAllocator requests for a pod and when it launches it, the PVC is reused. In the following example, the PVC from executor 6 is reused for new executor pod 11:
The shuffle files, if present in the PVC are reused.
The key advantage of this technique is that it allows us to reuse pre-computed shuffle files in their original location, thereby reducing the time of the overall job run.
This works for both static and dynamic PVCs. Amazon EKS offers three different storage offerings, which can be encrypted too: Amazon Elastic Block Store (Amazon EBS), Amazon Elastic File System (Amazon EFS), and Amazon FSx for Lustre. We recommend using dynamic PVCs with Amazon EBS because with static PVCs, you would need to create multiple PVCs.
The following code enables this configuration; more details are available on GitHub:
For this to work, we need to enable PVC with Amazon EKS and mention the details in the Spark runtime configuration. For instructions, refer to How do I use persistent storage in Amazon EKS? The following code contains the Spark configuration details for using PVC as local storage; other details are available on GitHub:
Conclusion
With Amazon EMR on EKS (6.9) and the features discussed in this post, you can further reduce the overall runtime for Spark jobs when running with Spot Instances. This also improves the overall resiliency and flexibility of the job while cost optimizing the workload on EC2 Spot.
Try out the EMR on EKS workshop for improved performance when running Spark workloads on Kubernetes and cost optimize using EC2 Spot Instances.
About the Author
Kinnar Kumar Sen is a Sr. Solutions Architect at Amazon Web Services (AWS) focusing on Flexible Compute. As a part of the EC2 Flexible Compute team, he works with customers to guide them to the most elastic and efficient compute options that are suitable for their workload running on AWS. Kinnar has more than 15 years of industry experience working in research, consultancy, engineering, and architecture.
Introducing the Security Design of the AWS Nitro System whitepaper
Post Syndicated from J.D. Bean original https://aws.amazon.com/blogs/security/introducing-the-security-design-of-the-aws-nitro-system-whitepaper/
AWS recently released a whitepaper on the Security Design of the AWS Nitro System. The Nitro System is a combination of purpose-built server designs, data processors, system management components, and specialized firmware that serves as the underlying virtualization technology that powers all Amazon Elastic Compute Cloud (Amazon EC2) instances launched since early 2018. With the Nitro System, AWS undertook an effort to reimagine the architecture of virtualization to deliver security, isolation, performance, cost savings, and a pace of innovation that our customers require.
This whitepaper is a detailed design document on the inner workings of the AWS Nitro System, and how we use it to help secure your most critical workloads. This is the first time that AWS has provided such a detailed design document on the Nitro System and how it offers a no-operator access design and strong tenant isolation. The whitepaper describes the security design of the Nitro System in detail to help you evaluate Amazon EC2 for your sensitive workloads.
Three key components of the Nitro System are used to implement this design:
- Purpose-built Nitro Cards – Hardware devices designed by AWS that provide overall system control and I/O virtualization that is independent of the main system board with its CPUs and memory.
- Nitro Security Chip – Enables a secure boot process for the overall system based on a hardware root of trust, the ability to offer bare metal instances, and defense-in-depth that offers protection to the server from unauthorized modification of system firmware.
- Nitro Hypervisor – A deliberately minimized and firmware-like hypervisor designed to provide strong resource isolation, and performance that is nearly indistinguishable from a bare metal server.
The whitepaper describes the fundamental architectural change introduced by the Nitro System compared to previous approaches to virtualization. It discusses the three key components of the Nitro System, and provides a demonstration of how these components work together by walking through what happens when a new Amazon Elastic Block Store (Amazon EBS) volume is added to a running EC2 instance. The whitepaper also discusses how the Nitro System is designed to eliminate the possibility of administrator access to an EC2 server, the overall passive communications design of the Nitro System, and the Nitro System change management process. Finally, the paper surveys important aspects of the EC2 system design that provide mitigations against potential side-channel issues that can arise in compute environments.
The whitepaper dives deep into each of these considerations, offering a detailed picture of the Nitro System security design. For more information about cloud security at AWS, contact us.
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.
AWS Week in Review – December 19, 2022
Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/aws-week-in-review-december-19-2022/
We are half way between the re:Invent conference and the end-of-year holidays, and I did expect the cadence of releases and news to slow down a bit, but nothing is further away from reality. Our teams continue to listen to your feedback and release new capabilities and incremental improvements.
This week, many items caught my attention. Here is my summary.
The AWS Pricing Calculator for Amazon EC2 is getting a redesign to provide you with a simplified, consistent, and efficient calculator to estimate costs. It also added a way to bulk estimate costs for EC2 instances, EC2 Dedicated Hosts, and Amazon EBS services. Try it for yourself today.
Amazon CloudWatch Metrics Insights alarms now enables you to trigger alarms on entire fleets of dynamically changing resources (such as automatically scaling EC2 instances) with a single alarm using standard SQL queries. For example, you can now write a query like this to collect data about CPU utilization over your entire dynamic fleet of EC2 instances.
SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId)
AWS Amplify is a command line tool and a set of libraries to help you to build web and mobile applications connected to a cloud backend. We released Amplify Library for Android 2.0, with improvements and simplifications for user authentication. The team also released Amplify JavaScript library version 5, with improvements for React and React Native developers, such as a new notifications channel, also known as in-app messaging, that developers can use to display contextual messages to their users based on their behavior. The Amplify JavaScript library has also received improvements to reduce the overall bundle size and installation size.
Amazon Connect added granular access control based on resource tags for routing profiles, security profiles, users, and queues. It also adds bulk import for user hierarchy tags. This allows you to use attribute-based access control policies for Amazon Connect resources.
Amazon RDS Proxy now supports PostgreSQL major version 14. RDS Proxy is a fully managed, highly available database proxy for Amazon Relational Database Service (Amazon RDS) that makes applications more scalable, more resilient to database failures, and more secure. It is typically used by serverless applications that can have a large number of open connections to the database server and may open and close database connections at a high rate, exhausting database memory and compute resources.
AWS Gateway Load Balancer endpoints now support Ipv6 addresses. You can now send IPv6 traffic through Gateway Load Balancers and its endpoints to distribute traffic flows to dual stack appliance targets.
Amazon Location Service now provides Open Data Maps maps, in addition to ESRI and Here maps. I also noticed that Amazon is a core member of the new Overture Maps Foundation, officially hosted by the Linux Foundation. The mission of the Overture Maps Foundation is to power new map products through openly available datasets that can be used and reused across applications and businesses. The program is driven by Amazon Web Services (AWS), Facebook’s parent company Meta, Microsoft, and Dutch mapping company TomTom.
AWS Mainframe Modernization is a set of managed tools providing infrastructure and software for migrating, modernizing, and running mainframe applications. It is now available in three additional AWS Regions and supports AWS CloudFormation, AWS PrivateLink, AWS Key Management Service.
X in Y. Jeff started this section a while ago to list the expansion of new services and capabilities to additional Regions. I noticed 11 Regional expansions this week:
- Amazon AppStream 2.0 is now available in the South America (São Paulo) Region
- Amazon Neptune Serverless is now available in 5 additional AWS Regions
- Amazon Location Service now available in Asia Pacific (Mumbai), Canada (Central), Europe (London), and South America (São Paulo)
- Amazon Elastic File System (Amazon EFS) is now available in the AWS Europe (Zurich) Region
- Amazon QuickSight is now available in Stockholm and Paris Regions
- Amazon EC2 C6id, M6id, and R6id on one side, and M6a and C6a on the other side are now available in more Regions
- Amazon Kendra now available in Asia-Pacific (Mumbai) AWS Region
- Amazon MQ is now available in the Middle East (UAE) Region
- Contact Lens for Amazon Connect now provides conversational analytics in Africa (Cape Town) Region
- Amazon ECS Service Connect now available in the AWS China (Beijing) and AWS China (Ningxia) Regions
- Amazon GuardDuty now available in AWS Europe (Zurich) Region
Other AWS News
This week, I also noticed these AWS news items:
Amazon SageMaker turned 5 years old 
. You can read the initial blog post we published at the time. To celebrate the event, the Amazon Science published this article where AWS’s Vice President Bratin Saha reflects on the past and future of AWS’s machine learning tools and AI services.
The security blog published a great post about the Cedar policy language. It explains how Amazon Verified Permissions provides a pre-built, flexible permissions system that you can use to build permissions based on both ABAC and RBAC in your applications. Cedar policy language is also at the heart of Amazon Verified Access I blogged about during re:Invent.
And just like every week, my most excellent colleague Ricardo published the open source newsletter.
Upcoming AWS Events
Check your calendars and sign up for these AWS events:
AWS re:Invent recaps in your area. During the re:Invent week, we had lots of new announcements, and in the next weeks, you can find in your area a recap of all these launches. All the events will be posted on this site, so check it regularly to find an event nearby.
AWS re:Invent keynotes, leadership sessions, and breakout sessions are available on demand. I recommend that you check the playlists and find the talks about your favorite topics in one collection.
AWS Summits season will restart in Q2 2023. The dates and locations will be announced here.
Stay Informed
That is my selection for this week! Heads up – the Week in Review will be taking a short break for the end of the year, but we’ll be back with regular updates starting on January 9, 2023. To better keep up with all of this news, do not forget to check out the following resources:
- What’s New with AWS – All AWS announcements. Add the RSS feed to your news reader.
- The Official AWS Podcast – Listen each week for updates on the latest AWS news and deep dives into exciting use cases. There are also official AWS podcasts in your local languages. Check the ones in French, German, Italian, and Spanish.
- AWS News Blog – This blog.
— seb
This post is part of our Week in Review series. Check back each week for a quick roundup of interesting news and announcements from AWS!
Top analytics announcements of AWS re:Invent 2022
Post Syndicated from Gwen Chen original https://aws.amazon.com/blogs/big-data/top-analytics-announcements-of-aws-reinvent-2022/
Missed AWS re:Invent 2022? We’ve got you covered!
AWS offers the most scalable, highest performing data services to keep up with the growing volume and velocity of data to help organizations to be data-driven in real-time. We help customers unify diverse data sources by investing in a zero ETL future. We provide the industry’s most comprehensive set of capabilities for an end-to-end data strategy for all your workloads. And, our services help you enable end-to-end data governance so your teams are free to move faster with data.
This post walks you through all of the new analytics service launches. You’ll find links to blog posts, announcements, session recordings, and press releases so you can dive deeper into those launches.
For more 2022 re:Invent recaps and ongoing coverage of all the important AWS launches, be sure to stay in touch with us here:
- Analytics at re:Invent: session recordings
- AWS Databases & Analytics online events: Analytics in 15, fireside chat, deep dive, and roadmap
- Top announcements of AWS re:Invent 2022: AWS VP and Chief Evangelist Jeff Barr’s picks for some of the most impactful launches
Press releases
Press release – AWS Announces Five New Database and Analytics Capabilities
This press release covers five new database and analytics capabilities that make it faster and easier for you to manage and analyze data at petabyte scale—Amazon DocumentDB Elastic Clusters, Amazon OpenSearch Serverless, Amazon Athena for Apache Spark, AWS Glue Data Quality, and Amazon Redshift Multi-AZ.
Press release – AWS Announced Five New Capabilities for Amazon QuickSight
This press release covers five new capabilities for Amazon QuickSight, the most popular serverless BI service built for the cloud. These new capabilities will help customers streamline business intelligence operations.
Press release – AWS Announced Two New Capabilities to Move Toward a Zero-ETL Future on AWS
This press release covers two new integrations that make it easier for customers to connect and analyze data across data stores without having to move data between services.
Press release – AWS Announced Amazon DataZone
Amazon DataZone makes it faster and easier for customers to catalog, discover, share, and govern data stored across AWS, on premises, and on third-party sources. To learn more about Amazon DataZone, please visit the product page or watch the re:Invent session recording.
Keynotes and leadership sessions
Adam Selipsky, Chief Executive Officer of Amazon Web Services, highlighted innovations in data, infrastructure, and more that are helping customers achieve their goals faster, take advantage of untapped potential, and create a better future with AWS. The analytics new launches Adam mentioned include Amazon OpenSearch Serverless, Amazon DataZone, and Amazon Aurora zero-ETL integration with Amazon Redshift.
Swami Sivasubramanian, Vice President of AWS Data and Machine Learning, revealed the latest AWS innovations that can help you transform your company’s data into meaningful insights and actions for your business. In this keynote, Swami launched Amazon Athena for Apache Spark, Amazon Redshift integration for Apache Spark, Amazon Redshift Multi-AZ, AWS Glue Data Quality, and other new AWS capabilities.
G2 Krishnamoorthy, VP of AWS Analytics, covered the latest service innovations around data and also highlighted customer successes with AWS analytics. New analytics capabilities he covered include AWS Glue for Ray, Amazon Redshift Streaming Ingestion, Amazon Aurora zero-ETL to Amazon Redshift, Amazon Redshift integration for Apache Spark, Amazon DataZone, Amazon Athena for Apache Spark, Amazon OpenSearch Serverless, Amazon QuickSight API, and more.
Mai-Lan Tomsen Bukovec, Vice President of AWS Foundational Data Services, and Andy Warfield, AWS Distinguished Engineer, shared the latest AWS storage innovations and an inside look at how customers drive modern business on data lakes and with high-performance data. They also dived deep into technical and organizational strategies that protect with resilience, respond with agility, and fuel innovations with data-driven insights on AWS storage.
Amazon DataZone
To gain value from your data, it needs to be accessible by people and systems that need it for analytics. This session introduces you to Amazon DataZone, a new AWS business data catalog that allows you to unlock data across organizational boundaries with built-in governance.
Amazon Security Lake
- Blog – Preview: Amazon Security Lake – A Purpose-Built Customer-Owned Data Lake Service
This new service automatically centralizes your organization’s security data from cloud and on-premises sources into a purpose-built data lake stored in your account.
Amazon Redshift
- Blog – New for Amazon Redshift – Zero-ETL integration, simplified data ingestion techniques, security and reliability features.
This year at re:Invent, Amazon Redshift has announced a number of features to help you simplify data ingestion and get to insights easily and quickly within a secure, reliable environment. - Blog – New for Amazon Redshift – General Availability of Streaming Ingestion for Kinesis Data Streams and Managed Streaming for Apache Kafka
Amazon Redshift Streaming Ingestion ingests hundreds of megabytes of data per second so you can query data in near real time. You can connect to multiple Kinesis Data Streams or Amazon Managed Streaming for Apache Kafka data streams and pull data directly to Amazon Redshift without staging data in Amazon S3. - Blog – New – Amazon Redshift Integration with Apache Spark
This new release makes it easy to build and run Spark applications on Amazon Redshift and Redshift Serverless, enabling you to open up the data warehouse for a broader set of AWS analytics and machine learning (ML) solutions. - Blog – Simplify data ingestion from Amazon S3 to Amazon Redshift using auto-copy
This feature simplifies data loading from Amazon S3 into Amazon Redshift. You can now set up continuous file ingestion rules to track your Amazon S3 paths and automatically load new files without needing additional tools or custom solutions. - Blog – Centrally manage access and permissions for Amazon Redshift data sharing with AWS Lake Formation
This feature enables you to centrally manage access to your Amazon Redshift datashares using Lake Formation. It opens up new design patterns and broadens governance and security posture across data warehouses. - Blog – Simplify data loading on the Amazon Redshift console with Informatica Data Loader
You need to bring data quickly and at scale from various data stores. You also need a simple, easy, and cloud-native solution to quickly onboard new data sources or to analyze recent data for actionable insights. With this feature, you can securely connect and load data to Amazon Redshift at scale via a simple and guided interface.
Watch the recording to learn about important new features of Amazon Redshift. Learn how Amazon Redshift reinvented data warehousing to help you analyze all your data across data lakes, data warehouses, and databases with the best price performance. In this session, Goldman Sachs shared their Amazon Redshift use case.
Amazon OpenSearch Service
- Blog – Run Search and Analytics Workloads without Managing Clusters
This new release provisions and scales resources to deliver fast data ingestion and query responses for even the most demanding and unpredictable workloads, eliminating the need to configure and optimize clusters. Learn more by watching the recording of the re:Invent breakout session Provision & scale OpenSearch resources with serverless. To get started with Amazon OpenSearch Serverless, please join this workshop.
Streaming services
- Announcement – Introducing Amazon Managed Streaming for Apache Kafka (MSK) Delivery Partners
The new Amazon MSK Service Delivery specialization for AWS partners helps customers migrate and build real-time streaming analytics solutions with fully managed Apache Kafka. - Announcement – Amazon Kinesis Data Firehose adds support for data stream delivery to Amazon OpenSearch Serverless
With a few clicks, you can easily ingest, transform, and reliably deliver streaming data into an Amazon OpenSearch Serverless without building and managing your own data ingestion and delivery infrastructure.
AWS Glue
- Blog – Join the Preview – AWS Glue Data Quality
AWS Glue Data Quality can analyze your tables and recommend a set of rules automatically based on what it finds. - Announcement – Announcing AWS Glue for Ray (Preview)
Data engineers can use AWS Glue for Ray to process large datasets with Python and popular Python libraries. - Blog – New AWS Glue 4.0 – New and Updated Engines, More Data Formats, and More
This version of AWS Glue includes Python 3.10 and Apache Spark 3.3.0, plus native support for the Cloud Shuffle Storage Plugin for Apache Spark. It also includes Pandas support and more. - Announcement – Introducing AWS Glue Delivery
The new AWS Glue Delivery specialization validates AWS Partners with deep expertise and proven success in delivering AWS Glue for data integration, data pipeline, and data catalog use cases. - Announcement – AWS Glue for Apache Spark Native support for Data Lake Frameworks
AWS Glue for Apache Spark now supports three open-source data lake storage frameworks: Apache Hudi, Apache Iceberg, and Linux Foundation Delta Lake. - Announcement – AWS Glue introduces custom visual transforms
AWS Glue now offers custom visual transforms, which let customers define, reuse, and share business-specific ETL logic among their teams.
Amazon Athena
- Blog – New — Amazon Athena for Apache Spark
With this feature, we can run Apache Spark workloads, use Jupyter Notebook as the interface to perform data processing on Athena, and programmatically interact with Spark applications using Athena APIs.
Amazon QuickSight
- Blog – New analytical questions available in Amazon QuickSight Q: “Why” and “Forecast”
Amazon QuickSight announces support for two new question types that simplify and scale complex analytical tasks using natural language: “forecast” and “why.” - Blog – Announcing Automated Data Preparation for Amazon QuickSight Q
Automated data preparation uses machine learning to infer semantic information about data and adds it to datasets as metadata about the columns (fields), making it faster for you to prepare data in order to support natural language questions. - Blog – New Amazon QuickSight API Capabilities to Accelerate Your BI Transformation
New QuickSight API capabilities allow programmatic creation and management of dashboards, analysis, and templates. - Blog – Create and Share Operational Reports at Scale with Amazon QuickSight Paginated Reports
This feature allows customers to create and share highly formatted, personalized reports containing business-critical data to hundreds of thousands of end users—without any infrastructure setup or maintenance, up-front licensing, or long-term commitments.
Amazon AppFlow
- Blog – Announcing Additional Data Connectors for Amazon AppFlow
We’ve added 22 new data connectors for Amazon AppFlow, including connectors for marketing, customer service and engagement, and business operations.
Thanks for reading! re:Invent is certainly not just about new launches. The Analytics and Business Intelligence tracks dived deep into each one of the analytics services through sessions (86 in total!), covering a wide range of topics and use cases.
Check out the YouTube playlist for session recordings.
About the author
Gwen Chen is Senior Product Marketing Manager for Amazon Redshift and re:Invent Analytics Track Lead. She believes in the power of communication, and likes data, analytics, and AI/ML.
Monitor AWS workloads without a single line of code with Logz.io and Kinesis Firehose
Post Syndicated from Amos Etzion original https://aws.amazon.com/blogs/big-data/monitor-aws-workloads-without-a-single-line-of-code-with-logz-io-and-kinesis-firehose/
Observability data provides near real-time insights into the health and performance of AWS workloads, so that engineers can quickly address production issues and troubleshoot them before widespread customer impact.
As AWS workloads grow, observability data has been exploding, which requires flexible big data solutions to handle the throughput of large and unpredictable volumes of observability data.
Solution overview
One option is Amazon Kinesis Data Firehose, which is a popular service for streaming huge volumes of AWS data for storage and analytics. By pulling data from Amazon CloudWatch, Amazon Kinesis Data Firehose can deliver data to observability solutions.
Among these observability solutions is Logz.io, which can now ingest metric data from Amazon Kinesis Data Firehose and make it easier to get metrics from your AWS account to your Logz.io account for analysis, alerting, and correlation with logs and traces.
In a few clicks and a few configurations, we’ll see how you can start streaming your metric data (and soon, log data!) to Logz.io for storage and analysis.
Prerequisites
- Logz.io account – Create a free trial here
- Logz.io shipping token – Learn about metrics tokens here. You need to be a Logz.io administrator.
- Access to Amazon CloudWatch and Amazon Kinesis Data Firehose with the appropriate permissions to manage HTTP endpoints.
- Appropriate permissions to create an Amazon Simple Storage Service (Amazon S3) bucket
Sending Amazon CloudWatch metric data to Logz.io with an Amazon Kinesis Data Firehose
Amazon Kinesis Data Firehose is a service for ingesting, processing, and loading data from large, distributed sources such as logs or clickstreams into multiple consumers for storage and real-time analytics. Kinesis Data Firehose supports more than 50 sources and destinations as of today. This integration can be set up in minutes without a single line of code and enables near real-time analytics for observability data generated by AWS services by using Amazon CloudWatch, Amazon Kinesis Data Firehose, and Logz.io.
Once the integration is configured, Logz.io customers can open the Infrastructure Monitoring product to see their data coming in and populating their dashboards. To see some of the data analytics and correlation you get with Logz.io, check out this short demonstration.
Let’s begin a step-by-step tutorial for setting up the integration.
- Start by going to Amazon Kinesis Data Firehose and creating a delivery stream with Data Firehose.

- Next you select a source and destination. Select Direct Put as the source and Logz.io the destination.
- Next, configure the destination settings. Give the HTTP endpoint a name, which should include logz.io.
- Select from the dropdown the appropriate endpoint you would like to use.
If you’re sending data to a European region, then set it to Logz.io Metrics EU. Or you can use the us-east-1 destination by selecting Logz.io Metrics US.
- Next, add your Logz.io Shipping Token. You can find this by going to Settings in Logz.io and selecting Manage Tokens, which requires Logz.io administrator to access. This ensures that your account is only ingesting data from the defined sources (e.g., this Amazon Kinesis Data Firehose delivery stream).

Keep Content encoding on Disabled and set your desired Retry Duration.
You can also configure Buffer hints to your preferences.
- Next, determine your Backup settings in case something goes wrong. In most cases, it’s only necessary to back up the failed data. Simply choose an Amazon S3 bucket or create a new one to store data if it doesn’t make it to Logz.io. Then, select Create a delivery stream.
Now it’s time to connect Amazon CloudWatch to our Amazon Kinesis Data Firehose Delivery Stream.
- Navigate to Amazon CloudWatch and select Streams in the Metrics menu. Select Create metrics stream.
- Next, you can either select to send all your Amazon CloudWatch metrics to Logz.io, or only metrics from specified namespaces.
In this case, we chose Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS), AWS Lambda, and Elastic Load Balancing (ELB).
- Under Configuration, choose the Select an existing Firehose owned by your account option and choose the Amazon Kinesis Data Firehose you just configured.

If you’d like, you can choose additional statistics in the Add additional statistics box, which provides helpful metrics in terms of percentiles to monitor like latency metrics (i.e., which services have the highest average latency). This may increase your costs.
- Lastly, give your metric stream a name and hit Create metric stream.
That’s it! Without writing a single line of code, we configured an integration with AWS and Logz.io that enables fast and easy infrastructure monitoring through Amazon CloudWatch data collection.
Your metrics will be stored in Logz.io for 18 months out of the box, without requiring any overhead management.
You can also begin to build dashboards and alerts to begin monitoring – like this Amazon EC2 monitoring dashboard below.

Conclusion
This post demonstrated how to configure an integration with AWS and Logz.io for efficient infrastructure monitoring through Amazon CloudWatch.
To learn more about building metrics dashboards in Logz.io, you can watch this video.
Currently, some users might find that they are sending more data than they really need, which can raise costs. In future versions of this integration, it will be easier to narrow down the metrics to reduce costs.
Want to try it yourself? Create a Logz.io account today, navigate to our infrastructure monitoring product, and start streaming metric data to Logz.io to start monitoring.
About the authors
Amos Etzion – Product Manager at Logz.io
Charlie Klein – Product Marketing Manager at Logz.io
Mark Kriaf – Partner Solutions Architect at AWS
Introducing native Delta Lake table support with AWS Glue crawlers
Post Syndicated from Noritaka Sekiyama original https://aws.amazon.com/blogs/big-data/introducing-native-delta-lake-table-support-with-aws-glue-crawlers/
Delta Lake is an open-source project that helps implement modern data lake architectures commonly built on Amazon S3 or other cloud storages. With Delta Lake, you can achieve ACID transactions, time travel queries, CDC, and other common use cases on the cloud. Delta Lake is available with multiple AWS services, such as AWS Glue Spark jobs, Amazon EMR, Amazon Athena, and Amazon Redshift Spectrum.
AWS Glue includes Delta crawler, a capability that makes discovering datasets simpler by scanning Delta Lake transaction logs in Amazon Simple Storage Service (Amazon S3), extracting their schema, creating manifest files in Amazon S3, and automatically populating the AWS Glue Data Catalog, which keeps the metadata current. The newly created AWS Glue Data Catalog table has format SymlinkTextInputFormat. Delta crawler creates a manifest file, which is a text file containing the list of data files that query engines such as Presto, Trino, or Athena can use to query the table rather than finding the files with the directory listing. A previous blog post demonstrated how it works. Manifest files needed to be regenerated on a periodic basis to include newer transactions in the original Delta Lake tables which resulted in expensive I/O operations, longer processing times, and increased storage footprint.
With today’s launch, Glue crawler is adding support for creating AWS Glue Data Catalog tables for native Delta Lake tables and does not require generating manifest files. This improves customer experience because now you don’t have to regenerate manifest files whenever a new partition becomes available or a table’s metadata changes. With the native Delta Lake tables and automatic schema evolution with no additional manual intervention, this reduces the time to insight by making newly ingested data quickly available for analysis with your preferred analytics and machine learning (ML) tools.
Amazon Athena SQL engine version 3 started supporting Delta Lake native connector. AWS Glue for Apache Spark also started supporting Delta Lake native connector in Glue version 3.0 and later. Amazon EMR started supporting Delta Lake in EMR release version 6.9.0 and later. It means that you can query the Delta transaction log directly in Amazon Athena, AWS Glue for Apache Spark, and Amazon EMR. It makes the experience of working with native Delta Lake tables seamless across the platforms.
This post demonstrates how AWS Glue crawlers work with native Delta Lake tables and describes typical use cases to query native Delta Lake tables.
How AWS Glue crawler works with native Delta Lake tables
Now AWS Glue crawler has two different options:
- Native table: Create a native Delta Lake table definition on AWS Glue Data Catalog.
- Symlink table: Create a symlink-based manifest table definition on AWS Glue Data Catalog from a Delta Lake table, and generate its symlink files on Amazon S3.
Native table
Native Delta Lake tables are accessible from Amazon Athena (engine version 3), AWS Glue for Apache Spark (Glue version 3.0 and later), Amazon EMR (release version 6.9.0 and later), and other platforms that support Delta Lake tables. With the native Delta Lake tables, you have the capabilities such as ACID transactions, all while needing to maintain just a single source of truth.
Symlink table
Symlink tables are a consistent snapshot of a native Delta Lake table, represented using the SymlinkTextInputFormat using parquet files. The symlink tables are accessible from Amazon Athena and Amazon Redshift Spectrum.
Since the symlink tables are a snapshot of the original native Delta Lake tables, you need to maintain both the original native Delta Lake tables and the symlink tables. When the data or schema in an original Delta Lake table is updated, the symlink tables in the AWS Glue Data Catalog may become out of sync. It means that you can still query the symlink table and get a consistent result, but the result of the table is at the previous point in time.
Crawl native Delta Lake tables using AWS Glue crawler
In this section, let’s go through how to crawl native Delta Lake tables using AWS Glue crawler.
Prerequisite
Here’s the prerequisite for this tutorial:
- Install and configure AWS Command Line Interface (AWS CLI).
- Create your S3 bucket if you do not have it.
- Create your IAM role for AWS Glue crawler if you do not have it.
- Run the following command to copy the sample Delta Lake table into your S3 bucket. (Replace your_s3_bucket with your S3 bucket name.)
Create a Delta Lake crawler
A Delta Lake crawler can be created through the AWS Glue console, AWS Glue SDK, or AWS CLI. Specify a DeltaTarget with the following configurations:
DeltaTables– A list of S3DeltaPathswhere the Delta Lake tables are located. (Note that each path must be the parent of a_delta_logfolder. If the Delta transaction log is located ats3://bucket/sample_delta_table/_delta_log, then the paths3://bucket/sample_delta_table/should be provided.WriteManifest– A Boolean value indicating whether or not the crawler should write the manifest files for eachDeltaPath. This parameter is only applicable for Delta Lake tables created via manifest filesCreateNativeDeltaTable– A Boolean value indicating whether the crawler should create a native Delta Lake table. If set toFalse, the crawler would create a symlink table instead. Note that bothWriteManifestandCreateNativeDeltaTableoptions can’t be set toTrue.ConnectionName– An optional connection name stored in the Data Catalog that the crawler should use to access Delta Lake tables backed by a VPC.
In this instruction, create the crawler through the console. Complete the following steps to create a Delta Lake crawler:
- Open the AWS Glue console.
- Choose Crawlers.
- Choose Create crawler.
- For Name, enter delta-lake-native-crawler, and choose Next.
- Under Data sources, choose Add a data source.
- For Data source, select Delta Lake.
- For Include delta lake table path(s), enter
s3://your_s3_bucket/data/sample_delta_table/. - For Create tables for querying, choose Create Native tables,
- Choose Add a Delta Lake data source.

- Choose Next.
- For Existing IAM role, choose your IAM role, then choose Next.
- For Target database, choose Add database, then Add database dialog appears. For Database name, enter
delta_lake_native, then choose Create. Choose Next. - Choose Create crawler.
- The Delta Lake crawler can be triggered to run through the console or through the SDK or AWS CLI using the
StartCrawlAPI. It could also be scheduled through the console to trigger the crawlers at specific times. In this instruction, run the crawler through the console. - Select
delta-lake-native-crawler, and choose Run. - Wait for the crawler to complete.
After the crawler has run, you can see the Delta Lake table definition in the AWS Glue console:
You can also verify an AWS Glue table definition through the following AWS CLI command:
After you create the table definition on AWS Glue Data Catalog, AWS analytics services such as Athena and AWS Glue Spark jobs are able to query the Delta Lake table.
Query Delta Lake tables using Amazon Athena
Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon Simple Storage Service (Amazon S3) using standard SQL. Athena is serverless, so there is no infrastructure to manage, and you pay only for the queries that you run on datasets at petabyte scale. You can use Athena to query your S3 data lake for use cases such as data exploration for machine learning (ML) and AI, business intelligence (BI) reporting, and ad hoc querying.
There are now two ways to use Delta Lake tables in Athena:
- For native table: Use Athena’s newly launched native support for Delta Lake tables. You can learn more in Querying Delta Lake tables. This method no longer requires regenerating manifest files after every transaction. Data updates are available for queries in Athena as soon as they are performed in the original Delta Lake tables, and you get up to 40 percent improvement in query performance over querying manifest files. Since Athena optimizes data scans in native Delta Lake queries using statistics in Delta Lake files, you get the advantage of reduced cost for Athena queries. This post focuses on this approach.
- For symlink table: Use
SymlinkTextInputFormatto query symlink tables through manifest files generated from Delta Lake tables. This was previously the only manner in which Delta Lake table querying was supported via Athena and is no longer recommended when you use only Athena to query the Delta Lake tables.
To use the native Delta Lake connector in Athena, you need to use Athena engine version 3. If you are using an older engine version, change the engine version.
Complete following steps to start queries on Athena:
- Open the Amazon Athena console.
- Run the following query.
The following screenshot shows our output:
Query Delta Lake tables using AWS Glue for Apache Spark
AWS Glue for Apache Spark natively supports Delta Lake. AWS Glue version 3.0 (Apache Spark 3.1.1) supports Delta Lake 1.0.0, and AWS Glue version 4.0 (Apache Spark 3.3.0) supports Delta Lake 2.1.0. With this native support for Delta Lake, what you need for configuring Delta Lake is to provide a single job parameter --datalake-formats delta. There is no need to configure a separate connector for Delta Lake in AWS Marketplace. It reduces the configuration steps required to use these frameworks in AWS Glue for Apache Spark.
AWS Glue also provides a serverless notebook interface called AWS Glue Studio notebook to query and process data interactively. Complete the following steps to launch AWS Glue Studio notebook and query a Delta Lake table:
- On the AWS Glue console, choose Jobs in the navigation plane.
- Under Create job, select Jupyter Notebook.

- Choose Create a new notebook from scratch, and choose Create.
- For Job name, enter
delta-sql. - For IAM role, choose your IAM role. If you don’t have your own role for the AWS Glue job, create it by following the steps documented in the AWS Glue Developer Guide.
- Choose Start notebook job.
- Copy and paste the following code to the first cell and run the cell.
- Run the existing cell containing the following code.
- Copy and paste the following code to the third cell and run the cell.
The following screenshot shows our output:
Clean up
Now for the final step, cleaning up the resources:
- Delete your data under your S3 path:
s3://your_s3_bucket/data/sample_delta_table/. - Delete the AWS Glue crawler
delta-lake-native-crawler. - Delete the AWS Glue database
delta_lake_native. - Delete the AWS Glue notebook job
delta-sql.
Conclusion
This post demonstrated how to crawl native Delta Lake tables using an AWS Glue crawler and how to query the crawled tables from Athena and Glue Spark jobs. Start using AWS Glue crawlers for your own native Delta Lake tables.
If you have comments or feedback, please feel free to leave them in the comments.
About the authors
Noritaka Sekiyama is a Principal Big Data Architect on the AWS Glue team. He works based in Tokyo, Japan. He is responsible for building software artifacts to help customers. In his spare time, he enjoys cycling with his road bike.
Kyle Duong is a Software Development Engineer on the AWS Glue and Lake Formation team. He is passionate about building big data technologies and distributed systems. In his free time, he enjoys cycling or playing basketball.
Sandeep Adwankar is a Senior Technical Product Manager at AWS. Based in the California Bay Area, he works with customers around the globe to translate business and technical requirements into products that enable customers to improve how they manage, secure, and access data.
[The Lost Bots] S02E06: Play “Experts or Scuttlebutt?” With Us
Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/12/19/the-lost-bots-s02e06-play-experts-or-scuttlebutt-with-us/
![[The Lost Bots] S02E06: Play “Experts or Scuttlebutt?” With Us](https://blog.rapid7.com/content/images/2022/12/The-Lost-Bots-logo-large.png)
As the year winds down, Jeffrey Gardner, Detection and Response Practice Advisor and Stephen Davis, Lead D&R Sales Technical Advisor, collected predictions that were made for 2022, and new ones for 2023. Then, they asked their Rapid7 colleagues to decide if the prediction was made by a cybersecurity expert—or if it was scuttlebutt from, say, Reddit. It’s more interesting than a simple true and false game and appropriate in a world where you need to keep your ear to the ground but be wary of what you hear at the same time.
Play along and see if you beat our winner.
The episode ends with a quick game of “Never Have I Ever.” While some revelations are a bit embarrassing, it’s all safe for work and safe for the kiddies. (You won’t believe who got phished.)
Enjoy your holidays and see you next year.
Additional reading:
- [The Lost Bots] S02E01: SIEM Deployment in 10 Minutes
- [The Lost Bots] S02E02: The Worst and Best Hollywood Cybersecurity Depictions
- [The Lost Bots] S02E03: Browser-in-Browser Attacks — Don’t Get (Cat) Phished
- [The Lost Bots] S02E04: Cyber’s Most Dangerous Game—Threat Hunting
- [The Lost Bots] S02E05: The real magic in the Magic Quadrant
[$] Enabling non-executable memfds
Post Syndicated from original https://lwn.net/Articles/918106/
The memfd interface is a bit of a strange and Linux-specific beast; it was
initially created to support the secure
passing of data between cooperating processes on a single system. It has
since gained other roles, but it may still come as a surprise to some to
learn that memory regions created for memfds, unlike almost any other data
area, have the execute permission bit set. That can facilitate attacks; this
patch set from Jeff Xu proposes an addition to the memfd API to close
that hole.
A modern approach to implementing the serverless Customer Data Platform
Post Syndicated from Larry Bell original https://aws.amazon.com/blogs/architecture/a-modern-approach-to-implementing-the-serverless-customer-data-platform-cdp/
When building a Customer Data Platform (CDP), advertising and marketing Independent Software Vendors (ISVs) face a unique set of challenges. The ISV can help organizations with the heavy lifting required to build, secure, and maintain near real-time, high volume CDPs. However, architecting CDPs using traditional on-premises technologies can introduce multiple complexities and can limit deployment options. One strategy that may address these complexities is to use serverless technologies.
Serverless technologies feature automatic scaling, built-in high availability, and a pay-for-use billing model to increase agility, optimize costs, and reduce infrastructure management tasks such as capacity provisioning and patching. Using tools such as CloudFormation, each layer of the serverless CDP can be deployed on-demand in an independent manner to maximize portability and optimize performance.
A Software as a Service (SaaS) CDP usually has significantly more data in a multi-tenant environment than a single instance of a CDP. Clients of a SaaS solution need to continually expand across different channels, and often across many AWS Regions. In some cases, an ISV might have an existing infrastructure that was built before some of these modern capabilities and techniques were mature. Today, an ISV can build or even modernize an existing CDP and gain huge benefits from a serverless implementation.
This blog post explores how to use serverless technologies for the CDP. A modern, serverless CDP architecture can enable the ISV and the client companies to deliver in weeks instead of months, and provide a resilient infrastructure that supports agility and global deployment while maximizing operational efficiency and optimizing cost. This frees up technical resources to focus on differentiated product development instead of managing servers.
Serverless implementation of a CDP on AWS
A serverless architecture uses AWS services that don’t require the configuration of a server to provide an implementation. Serverless technology allows you to focus more time on rapidly building different components of the marketing CDP. The benefits of a CDP include the collection, aggregation, and organization of customer data sources. Implementing the CDP using serverless technology reduces the need to focus on managing infrastructure while reducing time to market, increasing agility, and resulting in cost optimization. Figure 1 is an architecture diagram that describes how various data sources can be prepared for consumption in the component based Customer Data Platform.
- Source systems of customer data include customer interactions, clickstreams and call center logs.
- Data from customer touchpoints is ingested into the marketing customer data platform (CDP) data lake using Amazon Kinesis, Amazon AppFlow, Amazon EKS and an Amazon API Gateway.
- Ingested data is sent – in its original, immutable format – to an Amazon Simple Storage Service (Amazon S3) Raw Zone bucket
- Raw data is then transformed into efficient data formats – such as Parquet or Avro – and moved to a Clean Zone Amazon S3 bucket.
- CDP processing and pipeline orchestration is conducted using purpose-built data processing components and transformation libraries through AWS Step Functions and then Amazon Personalize, AWS Lambda, and AWS Glue.
- Data in the Amazon S3 Curated Zone is now ready for post-CDP-processing consumption and is organized by subject areas, segments, and profiles.
- The analytics layer uses Amazon Redshift, Amazon QuickSight, Amazon SageMaker and Amazon Athena to natively integrate with the Curated Zone for analytics, dashboards, ad hoc reporting, and ML purposes.
- Customer data is then aggregated across platforms and published using customer APIs for consumption using Amazon DynamoDB and an Amazon API Gateway.
- Amazon Pinpoint and Amazon Connect are used to activate multiple customer channels such as mobile push, voice, and email for targeted marketing communications.
- Using AWS Lake Formation, fine-grained access controls can be enforced on catalog tables, columns, and rows on the data lake.
- The resulting catalog in AWS Glue helps you manage both business and technical metadata, with versioning, at scale.
Serverless implementation for ingestion
There are several methods of ingesting customer data, both internal to a customer and from external sources. Serverless options for ingestion could provide benefits to an ISV like cost or agility but it depends upon the use case. Examining serverless options for ingestion should be part of any modernization effort. If the CDP needs to stream data sources and ingest that data in near-real time, the ISV can use Amazon Kinesis. If you want a more traditional extract, transform, and load (ETL) tool, AWS Glue offers a serverless option to generate code that can be customized. AWS Glue DataBrew offers a visual data preparation tool. For more advanced governance and control, you can use AWS Lake Formation. To ingest sources using an API, the Amazon API Gateway provides a serverless approach. If you need more control over the ingestion, the use of customized scripts in Amazon AppFlow or Amazon Managed Streaming for Apache Kafka (Amazon MSK) can provide a solution.
Serverless storage implementation
Amazon Simple Storage Service (Amazon S3) provides a serverless, cost-effective solution for virtually unbounded amounts of storage and read-write bandwidth. As per the reference architecture, there are three purpose-specific zones:
- A raw zone containing the original, immutable version of data
- A trusted zone which can be used as a working area to combine, enhance and clean the data
- A refined zone containing data ready for consumption by users and applications
This structure allows the improvement of customer data and profiles, and provides the ability to integrate various data sources and a structure that allows customer data to be recreated in a manner consistent with changing business rules.
Serverless cataloging implementation
The cataloging services provide a grouping of the elements contained in structured and unstructured data sources that is intuitive and easy to understand, similar to a single relational database. AWS Glue Data Catalog gives logical structure to the data lake by allowing users to define tables and columns on top of Amazon S3 data sets. This serverless solution integrates with other analytics tools to enable data discovery and consistent usage. Fine-grained governance and access can also be enforced by AWS Lake Formation.
Serverless processing
There are great choices for implementing processing, using serverless technologies. A CDP platform can package code and run on demand without servers using AWS Lambda or AWS Step Functions depending up the complexity of the processing pipeline. These services can enable complex processing on customer data and profiles. Amazon SageMaker is a great serverless choice for incorporating artificial Intelligence / machine learning into your processing stream. For processing using big data techniques Amazon EMR Serverless is a good serverless option.
Serverless implementation for consumption
Analytics for the CDP provides several serverless technologies that enable different types of insights. For interactive SQL queries that integrate with our serverless AWS Glue Catalog, there is Amazon Athena. Athena provides SQL access to various data source, and can also use federated query functionality to connect to third-party sources, even if that data is sitting on another cloud or in a vendor’s environment. Athena can also work as an interface (middleware) to other reporting solutions.
If performance is a concern, Amazon Redshift is fast, petabyte-scale data warehouse solution that has a serverless option and fully integrates with these solutions. For a data visualization tool that can be embedded in your application or work as a standalone portal, examine Amazon QuickSight.
To enable collaboration, many use cases can use Amazon API Gateway to securely publish and expose API endpoints for consuming applications. This allows data to be shared from a single source of truth to consumers that use customer data for their processes. Most customers want to activate their customer data through marketing or advertising campaigns. To activate marketing communication over voice, email, text, or in-app messaging, you can use a serverless service called Amazon Pinpoint. For an omnichannel contact center support, we recommend Amazon Connect, which uses AI/ML and the CDP data to analyze customer sentiment, implement chatbots, and authenticate voice callers.
Serverless implementation for governance
AWS Lake Formation simplifies the process of configuring and securing access to the CDP. It can help orchestrate processing and ingestion, as well as enforcing fine-grained access controls on data catalogs. Other services such as AWS Glue DataBrew or Amazon Macie can identify and help mitigate exposure of Personally identifiable information (PII). AWS Config enables you to assess, audit, and evaluate the configurations of your AWS resources to automate the evaluation of recorded configurations against desired configurations.
Conclusion
This post described just some of the serverless solutions that are managed by AWS that allow you to build a modern, low-cost, data lake-centric CDP architecture in an accelerated manner. A decoupled, component-driven architecture lets you start small and quickly add new services to each independent component of the CDP. Use the Data Analytics Lens for guidance on designing, deploying, and architecting your analytics solution workloads in the AWS Cloud. Using this framework, you will learn the architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud. Follow the links in this article to learn more about the services available in AWS that can help you build a serverless CDP.
Further reading
Stable kernels 6.0.14, 5.15.84, 5.10.160, and 5.4.228
Post Syndicated from original https://lwn.net/Articles/918204/
Greg Kroah-Hartman has announced the release of the 6.0.14, 5.15.84, 5.10.160, and 5.4.228 stable kernels. They contain a
relatively small number of important fixes throughout the tree.
Security updates for Monday
Post Syndicated from original https://lwn.net/Articles/918203/
Security updates have been issued by Debian (chromium and thunderbird), Fedora (keylime, libarchive, libtasn1, pgadmin4, rubygem-nokogiri, samba, thunderbird, wireshark, and xorg-x11-server-Xwayland), Gentoo (curl, libreoffice, nss, unbound, and virtualbox), Mageia (advancecomp, couchdb, firefox, freerdp, golang, heimdal, kernel, kernel-linus, krb5, leptonica, libetpan, python-slixmpp, thunderbird, and xfce4-settings), Oracle (firefox, nodejs:16, and thunderbird), Scientific Linux (firefox and thunderbird), Slackware (samba), SUSE (chromium and kernel), and Ubuntu (linux-oem-5.17).
Progress on the Block Protocol
Post Syndicated from Joel Spolsky original https://www.joelonsoftware.com/2022/12/19/progress-on-the-block-protocol/
Since the 1990s, the web has been a publishing place for human-readable documents.
Documents published on the web are in HTML. HTML has a little bit of structure, for example, “here is a paragraph” or “emphasize this word.”
Then you stir in some CSS, which adds some pretty decorations to the structure, saying things like: make those paragraphs have tiny gray sans-serif text! And then people think you are hip. Unless they are older, and they can’t read your tiny gray words, so they give up on you.
That’s “structure,” as far as it goes, on the web.
Imagine, for example, that you mention a book on the web.
Goodnight Moon
by Margaret Wise Brown
Illustrated by Clement Hurd
Harper & Brothers, 1947
ISBN 0-06-443017-0
There’s not much structure there. A naive computer program reading this web page might not realize I was even mentioning a book. All I did was make the title bold.
So, also since the 1990s, people have realized that we can make the web a much more useful place to publish information if we applied a bit more structure. As early as 1999, Tim Berners-Lee was writing about the Semantic Web:
“I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which makes this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize.”
Tim Berners-Lee, Weaving The Web, 1999 HarperSanFrancisco (Chapter 12)
Using the Semantic Web you might publish a book title with a lot more detail that makes it computer-readable. To do this, you would probably start by going to schema.org and looking up their idea of a book. Then you could use one of a number of formats, like RDF or JSON-LD, to add additional markup to your HTML saying “hey! here’s a book!”
Ok, well, doing that is kinda hard to figure out, and, to be honest, it’s homework. Once your beautiful blog post is published and human-readable, it’s hard to gather the mental energy to figure out how to add the additional fancy markups that will make your web page computer-readable, and, unless there is already a computer reading your web pages, at this point, you usually give up. So, yeah. That was 1999, and not much progress has been made and there is very little of this semantic markup in the wild.
Well.
We would like to fix this, because human progress depends on getting more and more information in formats that are readily accessible, both by regular humans, their dumb A.I. li’l sibs, and your more traditional computer programs.

Here is something I believe: people will only add semantic markup to their web pages if doing so is easier than not.
In other words, the cost of adding semantic markup has to be zero or negative, or this whole project is not going anywhere.
Now imagine this world for a second:
- I want to insert a book into my blog post
- I type /book
- A search box appears where I start typing in the title of my book and choose from an autocomplete list.
- Once I find the book, a block gets inserted in my blog post showing details of the book in a format I like, with nice semantic markup behind the scenes.
In this world I did less work to insert a book (because I was assisted by a UI that looked up the details for me).
You can imagine the same scenario applying to literally any other kind of structured data.
- I want to insert an address into my blog post
- I type /address
- A search box appears where I start to type a location, which autocompletes in the way you have seen Instagram and Google Maps and a million other apps do it
- Once I choose the address, a block gets inserted showing the details of the address complete with semantic markup behind the scenes.
My “address block” might have any visual appearance. Visitors to my web page might see the address, or a little map, or a little map in Japanese, etc. etc. The semantic content is there behind the scenes. So, for example, my web browser might know “gosh this is an address! Maybe you want to do address-y things with it, like go there,” and then my browser might offer me options to summon a self-driving car and even call an ambulance when the self-driving car self-drives into a snowbank.
My two simplistic examples of “book” and “address” are interesting right now because (a) you can probably think of 1,000,000 more data types like this, and (b) none of these things work right now, because even though almost every web editing environment has a concept of “blocks,” none of them are extensible. WordPress has (oh gosh) hundreds of block types, but they don’t have thousands or millions, they don’t have “book” or “address” or “Burning Man Theme Camp” yet, and there’s no ecosystem by which developers and users can contribute new block types.
So I guess I gotta wait around for someone at WordPress to develop all the blocks I want to use. And then someone at Notion, and then someone at Trello, and then someone at Mailchimp, and someone at every other vendor that provides a text editor.
I have a better plan.
The web was built with open protocols. Suppose we all agree on a protocol for blocks.
Any developer that wants to create a new block can conform to this protocol.
Any kind of web-text-editing application can also conform to this protocol.
Then if anyone goes to the trouble of creating a cool “book” or “address” block, we’ll all be able to use it, anywhere.
And we shall dub this protocol, oh I don’t know, the Block Protocol.
And it should be, I think, 100% free, open, and public, so that there is no impediment to anyone on earth using it. And in fact if you want to make blocks that are open source or public, good for you, but if for some reason you would like to make private or commercial blocks, that’s fine too.
Where we’re up to
It’s been about a year since we started talking about the Block Protocol, and we’ve made a lot of progress figuring out how it has to work to do all the things it will need to do, in a clean and straightforward way.
But this is all going nowhere if it requires 93,000,000 humans to cooperate with my crazy scheme just to get it off the ground.
So what we did is build a WordPress Plugin that allows you to embed Block Protocol blocks into posts on your WordPress sites just as easily as you insert any other block.
Since WordPress powers 43% of the web, that means if you build a block for the Block Protocol, it’ll be widely usable right away.
Here’s a video demo:
The WordPress Plugin will be free, and it will be widely available in February, when we’ll also publish version 0.3 of the Block Protocol specification. You can get early access now.

In fact, if you were thinking of writing a plugin for WordPress for your own kind of custom block, you’ll find that using our plugin as your starting point is a lot easier, because you don’t have to know anything about WordPress Plugins or write any PHP code. So even if you don’t care for any of my crazy theories and just want to add a block to WordPress, this is the way to go.
Ultimately, though, we just want to make it easier to add useful semantic, structured information to the web, and this is the first step.
PS We just set up a Discord server for the Block Protocol where you can participate, ask questions, and meet the team.
PPS You can follow me on Mastodon, where I am @[email protected]. I don’t post that much, but I’m enjoying hanging out there in a human-to-human environment where there isn’t an algorithm stirring up righteous indignation about the latest fake-outrage of the day.
Last Cruise of USS Saginaw
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=niSJgfeLzi0
How to Surrender to a Drone
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/12/how-to-surrender-to-a-drone.html
The Ukrainian army has released an instructional video explaining how Russian soldiers should surrender to a drone:
“Seeing the drone in the field of view, make eye contact with it,” the video instructs. Soldiers should then raise their arms and signal they’re ready to follow.
After that the drone will move up and down a few meters, before heading off at walking pace in the direction of the nearest representatives of Ukraine’s army, it says.
The video also warns that the drone’s battery may run low, in which case it will head back to base and the soldiers should stay put and await a fresh one.
That one, too, should be met with eye contact and arms raised, it says.
Incredible.
Trash: Last Week Tonight with John Oliver (Web Exclusive)
Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=HkvQywg_uZA
Data Point
Post Syndicated from original https://xkcd.com/2713/







