Fix typo's, thansk to @equalizer999

content/posts/2023-01-06-micro-hack-eventbridge/index.md

@@ -1,7 +1,7 @@
 ---
 slug: '2023/01/06/github-event-aws-eventbridge'
 title: 'Micro Hack'
-subtitle: 'Hands-on guide to deliver GitHHub events to AWS EventBridge'
+subtitle: 'Hands-on guide to deliver GitHub events to AWS EventBridge'
 date: 2023-01-06
 cover: ./cover.jpeg
 coverDescription: 'Street art - Kruisstraat'
@@ -43,10 +43,10 @@ The webhook provided by the runner solution is tailored to only accept `workflow
 
 Since GitHub and AWS Cloud are a given, we looking for a better solution to handle the events. And avoiding creating a new webhook, or app for every event we are interested in. We are looking for an event-driven solution to process [GitHub events](https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads). We distinguish two main use cases. A hot stream of events to act on directly, and a cold stream for analytics. AWS typically provides you the building blocks, allowing you to compose the solution in several ways. Let's quickly explore our options:
 
-- [**Simple Notification Service (SNS)](https://aws.amazon.com/sns/):** A lightweight serverless option. A producer (webhook) publishes messages on a topic and subscribers can receive notification via an HTTP/HTTPS endpoint, email, Kinesis, SQS, Lambda, and SMS. With a filter, a subset of messages can be received.
-- [EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-quota.html): A lightweight serverless option. A producer can (webhook) can publishes messages on the bus. With rules messages can be delivered to targets. Example targets are Lambda, API endpoints, SQS, SNS, Redshift, and many more. The EventBridge also provides an option to redeliver events based on a message Archive.
-- [Kinesis](https://aws.amazon.com/kinesis/): A serverless option for handling continuous streams of data in real-time. Kinesis is based or inspired by Kafka, AWS native, and opinionated.
-- [Managed Kafka (MSK)](https://aws.amazon.com/msk/): A server-based option to handle continuous data streams. Kafka is highly configurable and will support most of the use-cases but also is more expensive and requires more knowledge to manage.
+- [**Simple Notification Service (SNS)**](https://aws.amazon.com/sns/): A lightweight serverless option. A producer (webhook) publishes messages on a topic and subscribers can receive notification via an HTTP/HTTPS endpoint, email, Kinesis, SQS, Lambda, and SMS. With a filter, a subset of messages can be received.
+- [**EventBridge**](https://aws.amazon.com/eventbridge/): A lightweight serverless option. A producer can (webhook) can publishes messages on the bus. With rules messages can be delivered to targets. Example targets are Lambda, API endpoints, SQS, SNS, Redshift, and many more. The EventBridge also provides an option to redeliver events based on a message Archive.
+- [**Kinesis**](https://aws.amazon.com/kinesis/): A serverless option for handling continuous streams of data in real-time. Kinesis is based or inspired by Kafka, AWS native, and opinionated.
+- [**Managed Kafka (MSK)**](https://aws.amazon.com/msk/): A server-based option to handle continuous data streams. Kafka is highly configurable and will support most of the use-cases but also is more expensive and requires more knowledge to manage.
 
 We are looking for a Serverless approach since we have in general not a constant or equally distributed load. And we have a strong preference for a SaaS-managed service instead to have to manage our own services. With these requirements, the [AWS EventBridge](https://aws.amazon.com/eventbridge/) seems a logical candidate to investigate.
 
@@ -192,7 +192,7 @@ EOF
 
 ```
 
-To an event rule, a target can be connected. Check the AWS developer documentation for the options. We limit ourselves to a few targets. First, we create the target log group.
+To an event rule, a target can be connected. Check the [AWS developer documentation](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) for the options. We limit ourselves to a few targets. First, we create the target log group.
 
 ```hcl
 resource "aws_cloudwatch_log_group" "all" {
@@ -259,9 +259,9 @@ resource "aws_cloudwatch_log_resource_policy" "main" {
 }
 ```
 
-Time to trigger another event, as result a log message in cloudwatch should appear.
+Time to trigger another event. As a result a log message in CloudWatch should appear.
 
-![cloudwatch loggroup](clouwatch.png)
+![CloudWatch loggroup](clouwatch.png)
 
 ### Trigger a Lambda