A closer look at locations in Eventarc

New locations in EventarcBack in August, we announced more Eventarc locations (17 new regions, as well as 6 new dual-region and multi-region locations to be precise). This takes the total number of locations in Eventarc to more than 30. You can see the full list in the Eventarc locations page or by running gcloud eventarc locations list . What does location mean in Eventarc?An Eventarc location usually refers to the single region that the Eventarc trigger gets created in. However, depending on the trigger type, the location can be more than a single region:Pub/Sub triggers only support single-region locations.Cloud Storage triggers support single-region, dual-region, and multi-region locations.Cloud Audit Logs triggers support single-region locations and the special global region.Before looking into trigger location in more detail, let’s look at other locations relevant in Eventarc.What other locations are relevant in Eventarc?Triggers connect event sources to event targets:Each event source, event target, and trigger has its own location. Sometimes, these locations have to match and sometimes they can be different.  Here’s an example of a trigger connecting Cloud Storage events from a bucket in the europe-west1 region to a Cloud Run service in the us-central1 region with a trigger located in the europe-west1 region:In many cases, you don’t have control over the location of the event source. In the example above, the Cloud Storage bucket is in theeurope-west1 region. That’s the location that you need to work with and it has implications for the trigger location (which I’ll get to later). The location of the event target is the region of the service where you want the events to go. You get to choose this from one of the supported regions when you deploy your Cloud Run service. You typically want this to be in the same region as your event source for latency and data locality reasons (but this is not strictly a requirement). In the example above, the event source (bucket) is in europe-west1 but the event target (Cloud Run service) is in  us-central1as specified by the –destination-run-region flag. The location of the trigger is dictated by the event source location, but the trigger type also comes into play. It is specified by the –location flag. Let’s take a look at the trigger location for each trigger type in more detail.Location in Pub/Sub triggersIn a Pub/Sub trigger, you connect a Pub/Sub topic to an event target. Pub/Sub topics are global and not tied to a single region. However, when you create a Pub/Sub trigger, you need to specify a region for it (because Eventarc triggers need to live in a region) with the –location flag as follows:By specifying a location, Eventarc automatically configures the geofencing feature in Pub/Sub such that events only persist in the specified location. As I noted above, you typically want to (but are not required to) choose the same region for the trigger and the Cloud Run service for lower latency and data locality. You can also use regional Pub/Sub service endpoints to publish to the topic to ensure that all of the data stays in a single region. Location in Cloud Storage triggersIn a Cloud Storage trigger, you connect a Cloud Storage bucket to an event target. A Cloud Storage bucket can be in a single-region (e.g. europe-west1), dual-region (e.g. eur4), or multi-region (e.g. eu) location. The location of the bucket dictates the location of the trigger and they have to match. The earlier trigger example was for a bucket in the  europe-west1 single-region location. Here’s another trigger connecting Cloud Storage events from a bucket in the eu multi-region location. Notice how the location flag matches the bucket region:If the bucket region and the trigger region do not match, you’ll see an error:Location in Cloud Audit Logs triggersIn a Cloud Audit Logs trigger, you connect any event source that emits Audit Logs to an event target. The location of the event source will dictate the trigger location. This is typically a single region but there is a special global region that’s necessary in some cases. For example, if you want to read Cloud Storage events from a bucket in the europe-west1 region with an Audit Logs trigger, you will create the trigger with the same location. Note that this will match all buckets in the europe-west1 region as there’s no filter by bucket in Audit Logs:On the other hand, if you want to match a dual-region or a multi-region bucket such as eu, you will create the trigger with the global location as Audit Logs triggers only support a single or global region. Note that this will match all buckets in all regions globally:As you can see from this example, if you want to read Cloud Storage events, the native Cloud Storage trigger is a much better option, but this example illustrates a typical case in which a global Audit Log trigger is necessary. That wraps up this closer look at locations in Eventarc. Feel free to reach out to me on Twitter @meteatamel for any questions or feedback.Related ArticleIntroducing the new Cloud Storage trigger in EventarcLearn how to use the new Cloud Storage trigger of EventarcRead Article
Quelle: Google Cloud Platform

AWS Security Hub fügt Unterstützung für die regionenübergreifende Aggregation von Befunden hinzu, um die Bewertung und Verbesserung Ihres AWS-Sicherheitsstatus zu vereinfachen

AWS Security Hub ermöglicht es Ihnen jetzt, eine Aggregationsregion zu bestimmen und einige oder alle Regionen mit dieser Aggregationsregion zu verknüpfen. Auf diese Weise erhalten Sie einen zentralen Überblick über alle Ihre Befunde für alle Ihre Konten und alle verknüpften Regionen. Nachdem Sie eine Region mit der Aggregationsregion verknüpft haben, werden Ihre Befunde kontinuierlich zwischen den Regionen synchronisiert. Jede Aktualisierung eines Befunds in einer verknüpften Region wird in die Aggregationsregion repliziert, und jede Aktualisierung eines Befunds in der Aggregationsregion wird in die verknüpfte Region repliziert, aus der der Befund stammt. Wenn Sie mehr über diese Funktion erfahren möchten, lesen Sie hier unsere Dokumentation dazu.
Quelle: aws.amazon.com

AWS Fault Injection Simulator unterstützt jetzt Spot-Unterbrechungen

Ab heute können Sie mit AWS Fault Injection Simulator (FIS) die Unterbrechung einer Amazon-EC2-Spot-Instance auslösen. Spot-Instances nutzen freie EC2-Kapazitäten, die mit einem Rabatt von bis zu 90 % gegenüber dem On-Demand-Preis erhältlich sind. Als Gegenleistung für den Rabatt können Spot-Instances von Amazon EC2 unterbrochen werden, wenn Amazon EC2 die Kapazität wieder benötigt. Wenn Sie Spot-Instances nutzen, müssen Sie auf Unterbrechungen vorbereitet sein. Mit FIS können Sie die Stabilität Ihrer Workload testen und überprüfen, ob Ihre Anwendung auf die von EC2 gesendeten Unterbrechungsmeldungen reagiert, bevor Ihre Instances beendet werden. Sie können einzelne Spot-Instances oder einen Teilsatz von Instances in Clustern als Ziel nutzen, die von Services wie ASG, Fleet und EMR verwaltet werden, die Ihre Instances markieren.
Quelle: aws.amazon.com

AWS Fault Injection Simulator injiziert jetzt Spot-Instance-Unterbrechungen

Sie können jetzt mit dem AWS Fault Injection Simulator (FIS) Unterbrechungen von Amazon EC2 Spot-Instances in Ihre Spot-Instance-Workloads injiziert. Mit Spot-Instances können Sie Computing-Workloads auf Amazon EC2 zu hohen Rabatten ausführen und die Spot-Instances im Gegenzug zurückgeben, wenn Amazon EC2 die Kapazität wieder benötigt. Da es immer möglich ist, dass Ihre Spot-Instance unterbrochen wird, sollten Sie sicherstellen, dass Ihre Anwendung auf eine Unterbrechung der Spot-Instance vorbereitet ist. Bislang war es jedoch schwierig, die Umstände einer Unterbrechung einer Spot-Instance nachzustellen, um die Reaktion Ihrer Anwendung zu bewerten und zu verbessern.
Quelle: aws.amazon.com