AWS Week in Review – October 31, 2022

Post Syndicated from Antje Barth original https://aws.amazon.com/blogs/aws/aws-week-in-review-october-31-2022/

No tricks, just treats in this weekly roundup of news and announcements. Let’s switch our AWS Management Console into dark mode and dive right into it.

Last Week’s Launches
Here are some launches that got my attention during the previous week:

AWS Local Zones in Hamburg and Warsaw now generally available – AWS Local Zones help you run latency-sensitive applications closer to end users. The AWS Local Zones in Hamburg, Germany, and Warsaw, Poland, are the first Local Zones in Europe. AWS Local Zones are now generally available in 20 metro areas globally, with announced plans to launch 33 additional Local Zones in metro areas around the world. See the full list of available and announced AWS Local Zones, and learn how to get started.

Amazon SageMaker multi-model endpoint (MME) now supports GPU instances – MME is a managed capability of SageMaker Inference that lets you deploy thousands of models on a single endpoint. MMEs can now run multiple models on a GPU core, share GPU instances behind an endpoint across multiple models, and dynamically load and unload models based on the incoming traffic. This can help you reduce costs and achieve better price performance. Learn how to run multiple deep learning models on GPU with Amazon SageMaker multi-model endpoints.

Amazon EC2 now lets you replace the root Amazon EBS volume for a running instance – You can now use the Replace Root Volume for patching features in Amazon EC2 to replace your instance root volume using an updated AMI without needing to stop the instance. This makes patching of the guest operating system and applications easier, while retraining the instance store data, networking, and IAM configuration. Check out the documentation to learn more.

AWS Fault Injection Simulator now supports network connectivity disruption – AWS Fault Injection Simulator (FIS) is a managed service for running controlled fault injection experiments on AWS. AWS FIS now has a new action type to disrupt network connectivity and validate that your applications are resilient to a total or partial loss of connectivity. To learn more, visit Network Actions in the AWS FIS user guide.

Amazon SageMaker Automatic Model Tuning now supports Grid Search – SageMaker Automatic Model Tuning helps you find the hyperparameter values that result in the best-performing model for a chosen metric. Until now, you could choose between random, Bayesian, and hyperband search strategies. Grid search now lets you cover every combination of the specified hyperparameter values for use cases in which you need reproducible tuning results. Learn how Amazon SageMaker Automatic Model Tuning now supports grid search.

For a full list of AWS announcements, be sure to keep an eye on the What’s New at AWS page.

Other AWS News
Here are some additional news items that you may find interesting:

Celebrating over 20 years of AI/ML innovation – On October 25, we hosted the AWS AI/ML Innovation Day. Bratin Saha and other leaders in the field shared the great strides we have made in the past and discussed what’s next in the world of ML. You can watch the recording here.

AWS open-source news and updates – My colleague Ricardo Sueiras writes this weekly open-source newsletter in which he highlights new open-source projects, tools, and demos from the AWS Community. Read edition #133 here.

Upcoming AWS Events
Check your calendars and sign up for these AWS events:

AWS re:Invent is only 4 weeks away! Join us live in Las Vegas from November 28–December 2 for keynote announcements, training and certification opportunities, access to 1,500+ technical sessions, and much more. Seats are still available to reserve, and walk-ups are available onsite. You can also join us online to watch live keynotes and leadership sessions.

If you are into machine learning like me, check out the ML attendee guide. AWS Machine Learning Hero Vinicius Caridá put together recommended sessions and tips and tricks for building your agenda. We also have attendee guides on additional topics and industries.

On November 2, there is a virtual event for building modern .NET applications on AWS. You can register for free.

On November 11–12, AWS User Groups in India are hosting the AWS Community Day India 2022, with success stories, use cases, and much more from industry leaders. Sign up for free to join this virtual event.

That’s all for this week. Check back next Monday for another Week in Review!

— Antje

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!

7 Rapid Questions with Toshio Honda, Sr. Security Solutions Engineer

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/10/31/7-rapid-questions-with-toshio-honda-sr-security-solutions-engineer/

You have been with Rapid7 for 4 years now, what originally attracted you to work here?

7 Rapid Questions with Toshio Honda, Sr. Security Solutions Engineer

I worked for a cybersecurity company who is a leader for the “Prevention” area prior to joining Rapid7, and I was looking for the next opportunity based on 3 criteria:, “Interesting Products”, “a flexible work environment” and “a supportive and talented team of people”. Rapid7 checked the box for all three of these areas, with a platform of products to help customer’s security operations across areas/categories beyond my experience/expertise, allowing me to stretch and grow my skills. The company is well known for having unique intelligence like Metasploit, as well as being placed #17 in the list of The Cybersecurity 500 by Cybersecurity Ventures. These things attracted me to work here.

What does the team in Japan look like, and what growth have you seen during your time here?

When I joined Rapid7 in January 2018, there were approximately 10+ employees in Japan. These people were primarily made up of Sales and Sales Engineering for products like Nexpose/InsightVM, AppSpider/InsightAppSec, and Metasploit Pro. As the team continues to change and grow, we are now at 20+ employees and hiring in Customer Success and Support so really broadening the skill sets in the region to better support our customers. As we continue to evolve and move towards a solution/platform provider to solve complex customer challenges, and support their security operations with broader products and managed services. Each individual has capabilities and talent as part of the team, which is a huge difference in terms of ‘types’.

What makes the culture at Rapid7 different from other tech and/or cybersecurity companies?

I believe transparency is a major differentiator. The leadership team in Rapid7 listens to each individual, and you have an opportunity to share your ideas and give feedback whether you are brand new or have been in your field for years.

What are the 3 biggest things you have learned during your time at Rapid7?

Here’re the 3 things that came up to my mind:
1. Be Proactive
2. Change is a Constant
3. Ask questions to turn the unknown into known

Being proactive means looking outside your immediate team to identify the right people, and gather the right information. Our team in Japan is relatively small, so it’s essential that we partner with other team members from different departments and locations in order to ensure we are anticipating potential challenges and getting the right people involved upfront.

For #2, almost everything can/will change, from our product roadmaps to the needs of our customer. As we anticipate change and embrace the opportunity to grow, it’s important to maintain customer’s expectations and see how Rapid7 can continue to be a strategic partner in maintaining their security solutions.

For #3, as a Solution Architect, I often have conversations with customers, and sometimes see they don’t even know what they need to improve their security posture. It’s important to unravel what they would need by asking questions to clarify their requirements. The same principle can be applied in case of security incidents. If you don’t have visibility (detections) for an incident, you wouldn’t be able to stop a breach. As a practitioner in Rapid7, I keep those

How would you describe your role at Rapid7?

My main role is Solution Architect (Security Solutions Engineer / Sales Engineer), but I’ve also been given the opportunity to learn new skills that are outside of my typical job description. In addition to my main role, I’ve been able to learn more about customer advisory, technical support and account management, and our professional services. Learning in these different areas has grown my confidence as a technical contributor, and provided me with some new insights into real world customer environments and security operations.

Describe your proudest moment working for Rapid7.

This is a really good question. I can’t pick one as there are so many moments in my memory. However, I am always proudest when I am able to solve especially complex or challenging problems customers are struggling with.

What advice would you give someone thinking about coming to work here?

If you enjoy challenging the status quo and solving interesting challenges, Rapid7 would be a great place to work. The company has a track record and history of supporting employees who have new ideas, so you’ll be supported to think creatively and craft your own vision as to how to support our customers and align to business goals.

If you’re interested in learning about open roles at Rapid7, visit our careers page.

What to consider when modernizing APIs with GraphQL on AWS

Post Syndicated from Lewis Tang original https://aws.amazon.com/blogs/architecture/what-to-consider-when-modernizing-apis-with-graphql-on-aws/

In the next few years, companies will build over 500 million new applications, more than has been developed in the previous 40 years combined (see IDC article). API operations enable innovation. They are the “front door” to applications and microservices, and an integral layer in the application stack. In recent years, GraphQL has emerged as a modern API approach. With GraphQL, companies can improve the performance of their applications and the speed in which development teams can build applications. In this post, we will discuss how GraphQL works and how integrating it with AWS services can help you build modern applications. We will explore the options for running GraphQL on AWS.

How GraphQL works

Imagine you have an API frontend implemented with GraphQL for your ecommerce application. As shown in Figure 1, there are different services in your ecommerce system backend that are accessible via different technologies. For example, user profile data is stored in a highly scalable NoSQL table. Orders are accessed through a REST API. The current inventory stock is checked through an AWS Lambda function. And the pricing information is in an SQL database.

How GraphQL works

Figure 1. How GraphQL works

Without using GraphQL, client applications must make multiple separate calls to each one of these services. Because each service is exposed through different API endpoints, the complexity of accessing data from the client side increases significantly. In order to get the data, you have to make multiple calls. In some cases, you might over fetch data as the data source would send you an entire payload including data you might not need. In some other circumstances, you might under fetch data as a single data source would not have all your required data.

A GraphQL API combines the data from all these different services into a single payload that the client defines based on its needs. For example, a smartphone has a smaller screen than a desktop application. A smartphone application might require less data. The data is retrieved from multiple data sources automatically. The client just sees a single constructed payload. This payload might be receiving user profile data from Amazon DynamoDB, or order details from Amazon API Gateway. Or it could involve the injection of specific fields with inventory availability and price data from AWS Lambda and Amazon Aurora.

When modernizing frontend APIs with GraphQL, you can build applications faster because your frontend developers don’t need to wait for backend service teams to create new APIs for integration. GraphQL simplifies data access by interacting with data from multiple data sources using a single API. This reduces the number of API requests and network traffic, which results in improved application performance. Furthermore, GraphQL subscriptions enable two-way communication between the backend and client. It supports publishing updates to data in real time to subscribed clients. You can create engaging applications in real time with use cases such as updating sports scores, bidding statuses, and more.

Options for running GraphQL on AWS

There are two main options for running GraphQL implementation on AWS, fully managed on AWS using AWS AppSync, and self-managed GraphQL.

I. Fully managed using AWS AppSync

The most straightforward way to run GraphQL is by using AWS AppSync, a fully managed service. AWS AppSync handles the heavy lifting of securely connecting to data sources, such as Amazon DynamoDB, and to develop GraphQL APIs. You can write business logic against these data sources by choosing code templates that implement common GraphQL API patterns. Your APIs can also interact with other AWS AppSync functionality such as caching, to improve performance. Use subscriptions to support real-time updates, and client-side data stores to keep offline devices in sync. AWS AppSync will scale automatically to support varied API request loads. You can find more details from the AWS AppSync features page.

AWS AppSync in an ecommerce system implementation

Figure 2. AWS AppSync in an ecommerce system implementation

Let’s take a closer look at this GraphQL implementation with AWS AppSync in an ecommerce system. In Figure 2, a schema is created to define types and capabilities of the desired GraphQL API. You can tie the schema to a Resolver function. The schema can either be created to mirror existing data sources, or AWS AppSync can create tables automatically based the schema definition. You can also use GraphQL features for data discovery without viewing the backend data sources.

After a schema definition is established, an AWS AppSync client can be configured with an operation request, such as a query operation. The client submits the operation request to GraphQL Proxy along with an identity context and credentials. The GraphQL Proxy passes this request to the Resolver, which maps and initiates the request payload against pre-configured AWS data services. These can be an Amazon DynamoDB table for user profile, an AWS Lambda function for inventory service, and more. The Resolver initiates calls to one or all of these services within a single API call. This minimizes CPU cycles and network bandwidth needs. The Resolver then returns the response to the client. Additionally, the client application can change data requirements in code on demand. The AWS AppSync GraphQL API will dynamically map requests for data accordingly, enabling faster prototyping and development.

II. Self-Managed GraphQL

If you want the flexibility of selecting a particular open-source project, you may choose to run your own GraphQL API layer. Apollo, graphql-ruby, Juniper, gqlgen, and Lacinia are some popular GraphQL implementations. You can leverage AWS Lambda or container services such as Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Services (EKS) to run GraphQL open-source implementations. This gives you the ability to fine-tune the operational characteristics of your API.

When running a GraphQL API layer on AWS Lambda, you can take advantage of the serverless benefits of automatic scaling, paying only for what you use, and not having to manage your servers. You can create a private GraphQL API using Amazon ECS, EKS, or AWS Lambda, which can only be accessed from your Amazon Virtual Private Cloud (VPC). With Apollo GraphQL open-source implementation, you can create a Federated GraphQL that allows you to combine GraphQL APIs from multiple microservices into a single API, illustrated in Figure 3. The Apollo GraphQL Federation with AWS AppSync post shows a concrete example of how to integrate an AWS AppSync API with an Apollo Federation gateway. It uses specification-compliant queries and directives.

Apollo GraphQL implementation on AWS Lambda

Figure 3. Apollo GraphQL implementation on AWS Lambda

When choosing self-managed GraphQL implementation, you have to spend time writing non-business logic code to connect data sources. You must implement authorization, authentication, and integrate other common functionalities. This can be caches to improve performance, subscriptions to support real-time updates, and client-side data stores to keep offline devices in sync. Because of these responsibilities, you have less time to focus on the business logic of application.

Similarly, backend development teams and API operators of an open-source GraphQL implementation must provision and maintain their own GraphQL servers. Remember that even with a serverless model, API developers and operators are still responsible for monitoring, performance tuning, and troubleshooting the API platform service.

Conclusion

Modernizing APIs with GraphQL gives your frontend application the ability to fetch just the data that’s needed from multiple data sources with an API call. You can build modern mobile and web applications faster, because GraphQL simplifies API management. You have flexibility to run an open-source GraphQL implementation most closely aligned with your needs on AWS Lambda, Amazon ECS, and Amazon EKS. With AWS AppSync, you can set up GraphQL quickly and increase your development velocity by reducing the amount of non-business API logic code.

Further reading:

Apple Only Commits to Patching Latest OS Version

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/10/apple-only-commits-to-patching-latest-os-version.html

People have suspected this for a while, but Apple has made it official. It only commits to fully patching the latest version of its OS, even though it claims to support older versions.

From ArsTechnica:

In other words, while Apple will provide security-related updates for older versions of its operating systems, only the most recent upgrades will receive updates for every security problem Apple knows about. Apple currently provides security updates to macOS 11 Big Sur and macOS 12 Monterey alongside the newly released macOS Ventura, and in the past, it has released security updates for older iOS versions for devices that can’t install the latest upgrades.

This confirms something that independent security researchers have been aware of for a while but that Apple hasn’t publicly articulated before. Intego Chief Security Analyst Joshua Long has tracked the CVEs patched by different macOS and iOS updates for years and generally found that bugs patched in the newest OS versions can go months before being patched in older (but still ostensibly “supported”) versions, when they’re patched at all.

Kernel prepatch 6.1-rc3

Post Syndicated from original https://lwn.net/Articles/913122/

The 6.1-rc3 kernel prepatch is out for
testing.

So while rc2 was just _way_ bigger than usual, rc3 is only a bit
larger than an average rc3 release is. But it’s still on the
largish side. I hope that things start calming down, and we’ll
start seeing the size of these rc’s shrink. Please?

Лечението на тежко болни деца – четири години без напредък

Post Syndicated from original https://yurukov.net/blog/2022/nzok-deca-4y/

Макар да изчезна от медийното внимание, не трябва да забравяме, че почти всеки ден деца биват диагностицирани с тежка болест и отговорността на обществото ни към тях не изчезва. Исторически това се правеше през фонда за лечение за деца, но в началото на 2019 години функциите ѝ бяха пренесени в НЗОК. Следя фонда и регистъра им отдавна, а след това въпреки опитите да се скрият данните, показах колко неподготвени бяха независимо от годините предполагаема подготовка. Това го забелязахме всички най-малкото по увеличените призиви за дарения за лечение зад граница в социални мрежи, кутии в магазини, SMS-и и платформи за дарения.

В предишната ми статия от юли 2021 показах последните изводи от тези данни. Няма да се впускам в детайлите от тогава – нещата и обясненията за аналогични и почти нищо не се е променило. Реших да обновя графиките с това, което са публикували от тогав. Нищо изглежда не се е променило в работата на НЗОК. Най-малкото докладите и регистърът са същите.

По броя подадени заявления се забелязва известно увеличение в последните 7 месеца. Не се вижда особена разлика в чакащите одобрение, но се запазва увеличеният брой отказани заявления, който се видя в края на 2020. Интересен е обаче резкият скок през март.

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

Броят взети решения по месеци не се увеличават въпреки повечето заявления, особено в последно време. Необяснима е и голямата вариация, особено предвид големия иначе брой – по 100-150 на месец.

Следващата графика показва колко време са чакали хора за решение към момента на взимането му. Например, ако са получили одобрение през март 2022, то са чакали 14 дни за решение плюс 3 дни за експерти. През март 2021-ва обаче е било 24 дни за комисията плюс 3 дни за становище от експерти. През последните два месеца е над 20 дни за комисия и 13 дни за експерти. Така времето за чакане на заявленията решени след август се връща на нивата с огромните забавяния от началното фиаско със закриването на Фонда за лечение на деца през март 2019-та.

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

Тук отново виждаме броя заявления „отлежаващи“ на бюрото на НЗОК. Това са искания за често спешно лечение на тежко болни деца, които във всеки един момент чакат решение. В червено съм маркирал тези, които все пак ще получат такова до месец. С синьо са такива, които може и да не бъдат решени, но често получават отговор след 2-3 месеца.

След големия скок при прехвърлянето в НЗОК виждаме подобрение в началото на 2020-та причинено обаче изцяло от по-малкото подадени заявления покрай пандемията. Не заради друго, ами заради блокирането на здравната система. Значително подобрение има в края на 2021-ва и началото на 2022-ра, а в последните 6 месеца ситуацията се е влошила и по този показател до нивата от началото на 2019-та.

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

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

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

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

The post Лечението на тежко болни деца – четири години без напредък first appeared on Блогът на Юруков.

Friday Squid Blogging: Chinese Squid Fishing

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/10/friday-squid-blogging-chinese-squid-fishing.html

China claims that it is “engaging in responsible squid fishing”:

Chen Xinjun, dean of the College of Marine Sciences at Shanghai Ocean University, made the remarks in response to recent accusations by foreign reporters and actor Leonardo DiCaprio that China is depleting its own fish stock and that Chinese boats have sailed to other waters to continue deep-sea fishing, particularly near Ecuador, affecting local fish stocks in the South American nation.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Read my blog posting guidelines here.

The collective thoughts of the interwebz