DEV Community: miruky

Transform an EventBridge Event Before It Reaches Amazon SQS

miruky — Sat, 05 Sep 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

An EventBridge rule normally forwards its matching event to a target. An input transformer changes that behavior: JSONPath variables select values from the original event, and an input template builds the payload that the target receives instead.

This Console run first sends a deliberately nonmatching control event, then sends one matching synthetic order event to a Standard SQS queue. The matching source event contains orderId, total, and an unwanted customerNote; the queue receives only the order ID, total, EventBridge timestamp, and a fixed source label.

The exercise uses two custom events and a small number of SQS requests. Check the linked EventBridge and SQS pricing pages for current rates and free-tier terms before running it.

1. Create an event bus and a queue

The run uses the English AWS Console and keeps EventBridge, SQS, and every validation action in us-east-1.

The header confirms United States (N. Virginia) while the EventBridge Console is in English. This fixes the Region shared by the bus, rule, and queue.

Open Amazon EventBridge, choose Event buses, and search for miruky-lddnesdcjdgblgrp. An exact-name result should not exist before creation.

The exact filter for miruky-lddnesdcjdgblgrp returns no event bus. That empty result establishes the resource boundary before creation.

Choose Create event bus and enter miruky-lddnesdcjdgblgrp. Keep Use AWS owned key, leave every optional log destination unselected, and keep the Archives toggle off. Do not add a resource policy, schema discovery, or tags for this short run.

The form shows miruky-lddnesdcjdgblgrp, the AWS owned key, no selected log destination, and the archive toggle off. Only the custom bus is created in this step.

In Amazon SQS, search for the exact name miruky-gqnaikvhwcffylgd and stop if it already exists. Otherwise, create a Standard queue with that name. For this short run of synthetic, non-sensitive data, disable the default SQS-managed server-side encryption. EventBridge does not support an SQS target encrypted with an AWS owned key. Leave the remaining delivery settings at their defaults.

The queue form pairs Standard with miruky-gqnaikvhwcffylgd and shows server-side encryption disabled. No delivery-setting override or dead-letter queue is added. This is an exercise boundary, not a production recommendation. For an encrypted production target, use a customer managed KMS key and grant EventBridge the required KMS permissions.

2. Build the rule and its input transformer

Return to EventBridge and choose Create rule on miruky-lddnesdcjdgblgrp. The current Console offers an Enhanced builder and an Advanced builder. Choose Advanced builder, enter miruky-imfnycrrfauwoztn, and confirm the custom event bus. In Build event pattern, choose Other and use this pattern:

{
  "source": ["demo.orders"],
  "detail-type": ["OrderCreated"]
}

The rule accepts only the fixed source and detail type used in this run. It does not inspect the individual fields inside detail.

The rule builder shows miruky-lddnesdcjdgblgrp, demo.orders, and OrderCreated together. The pattern is limited to the fixed source and detail type.

For the target, choose AWS service, SQS queue, and miruky-gqnaikvhwcffylgd. The current target widget creates an IAM execution role with narrowly scoped permission to send to the selected queue. It does not expose a role-name field, so the Console-generated name differs on every run. I left the queue access policy unchanged and used this execution-role path.

The Execution role block confirms that EventBridge has an identity-based path to call SQS. The cropped image excludes role and queue ARNs as well as account-specific identifiers.

Under Additional settings, choose Input transformer. For the optional sample event, I used the matching synthetic event shown later in this article. Then define these variables:

{
  "orderId": "$.detail.orderId",
  "time": "$.time",
  "total": "$.detail.total"
}

Use the variables in this input template. The angle-bracket tokens are EventBridge placeholders. Quote placeholders that must remain JSON strings; leave the numeric placeholder unquoted:

{
  "event_time": "<time>",
  "id": "<orderId>",
  "amount": <total>,
  "source": "eventbridge"
}

The preview keeps time and orderId as strings and total as a number. No JSONPath points to customerNote, the original event object, the account attribute, or the Region value.

The preview contains event_time, id, amount, and source after applying the three JSONPath variables. It contains no customerNote field or original event envelope.

Finish the wizard and open the rule. Confirm that it is enabled, belongs to the custom bus, and lists the generated SQS queue as its target.

The rule details show Enabled, miruky-lddnesdcjdgblgrp, and miruky-gqnaikvhwcffylgd. Account-scoped resource identifiers are excluded from the view.

3. Prove that a nonmatching source does not reach SQS

Give a new or updated EventBridge target a short period to propagate. From Event buses, open the actions for miruky-lddnesdcjdgblgrp and choose Send events. Enter source demo.orders.unmatched, detail type OrderCreated, and this event detail:

{
  "orderId": "order-control",
  "total": 1,
  "customerNote": "do-not-forward"
}

The source string is intentionally different from the rule's exact demo.orders value. The detail type and JSON shape remain valid, which isolates the event-pattern decision to that one field.

The form shows demo.orders.unmatched, OrderCreated, and the synthetic control detail. The source value cannot satisfy the rule's exact demo.orders array entry.

Choose Send and wait for the ingestion confirmation. EventBridge can accept an event on the custom bus even when none of that bus's rules match it.

The Console reports that the control event was sent successfully to miruky-lddnesdcjdgblgrp. That confirmation proves ingestion only; it does not claim that the SQS target ran.

Wait 60 seconds, then open the queue's Send and receive messages page. Set the polling duration to 20 seconds and complete two polls. The queue started empty, so both polls should return no message for this source value. A single immediate empty response would be weaker evidence because delivery and Console updates are asynchronous.

Both long polls return no available message after the accepted control event. Together with EventBridge's exact string matching, the result establishes the controlled failure: the event reached the bus, but the source mismatch prevented this rule from invoking SQS.

4. Send a matching event and inspect the transformed body

Return to Send events. Enter source demo.orders, detail type OrderCreated, and this event detail:

{
  "orderId": "order-001",
  "total": 42,
  "customerNote": "do-not-forward"
}

All three values are synthetic. The extra note provides a visible negative control: it belongs to the source event but should not cross the transformer boundary.

The form shows demo.orders, OrderCreated, order-001, 42, and do-not-forward. The unwanted note is present at the source boundary before transformation.

Choose Send and wait for the success confirmation. A successful PutEvents result means EventBridge accepted the event; the SQS receive is the separate delivery proof.

The Console reports that the event was sent successfully to miruky-lddnesdcjdgblgrp. This confirms ingestion, not delivery to SQS.

Open the SQS queue, choose Send and receive messages, and poll for messages. The delivered body should have exactly four top-level keys:

{
  "event_time": "EVENTBRIDGE_GENERATED_TIME",
  "id": "order-001",
  "amount": 42,
  "source": "eventbridge"
}

The observed event_time is an ISO 8601 value carried by the EventBridge event. Verify that the body does not contain customerNote, account, region, resources, detail-type, or the original EventBridge event ID.

The cropped body contains event_time, id, amount, and source, with order-001, 42, and eventbridge as the fixed values. It does not contain customerNote, do-not-forward, account, region, resources, or detail-type.

That body is the useful distinction: the rule matched the original event, but SQS received the template output instead of the complete envelope.

Wrap-up

The nonmatching control event reached the custom bus but produced no SQS message. The matching event carried three detail values plus the EventBridge envelope; the rule extracted orderId, total, and time, added a fixed source label, and delivered a four-key JSON body to SQS. The unwanted note and account-scoped envelope attributes never appeared in the target payload.

Input transformers are helpful when a target needs a small, stable contract rather than every field produced upstream. They do not validate missing JSONPath values when the rule is created, so the source shape and transformed output still need an end-to-end test like this one.

Thanks for reading this far.

See you in the next one.

References

Prove FIFO Deduplication in Amazon SQS from the AWS Console

miruky — Fri, 04 Sep 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

An Amazon SQS FIFO queue tracks MessageDeduplicationId values for a five-minute interval. When a producer repeats an ID during that window, SQS acknowledges the later send but does not make another copy available to consumers.

This Console run disables content-based deduplication so the IDs are explicit. It sends two different bodies with dedup-001, adds a control body with dedup-002, and then proves that consumers receive the original body and the control body—but not the duplicate body.

The validation uses one encrypted FIFO queue and a few SQS requests. Current SQS request pricing and free-tier terms are documented on the linked pricing page.

1. Create a FIFO queue with explicit deduplication IDs

The header confirms United States (N. Virginia) while the SQS Console is in English. us-east-1 is the fixed Region for this run.

Open Amazon SQS and search for miruky-fibqomwvgyqpoceu.fifo. The exact-name result should be empty before the queue is created.

The exact filter for miruky-fibqomwvgyqpoceu.fifo returns no queue. That empty result establishes the resource boundary before creation.

Choose Create queue, select FIFO, and enter miruky-fibqomwvgyqpoceu.fifo. Keep content-based deduplication disabled, use the default FIFO throughput settings, set the receive-message wait time to 20 seconds, and retain SQS-managed server-side encryption.

The form shows FIFO, miruky-fibqomwvgyqpoceu.fifo, disabled content-based deduplication, and a receive wait of 20 seconds. Each send must therefore provide a deduplication ID, while each final empty receive uses long polling rather than the default short-poll sample.

Open the new queue and verify that its type is FIFO, content-based deduplication is off, and the receive wait time is 20 seconds. The .fifo suffix is required by SQS and is recorded separately from the generated random name core in the resource ledger.

The queue details retain FIFO, disabled content-based deduplication, a receive wait of 20 seconds, and the SQS-managed encryption setting. The send comparison can now depend on explicit IDs rather than body hashes.

2. Send an original message and its duplicate

Open Send and receive messages. Enter the body accepted-original, group ID group-001, and deduplication ID dedup-001, then send it.

The original send form contains accepted-original, group-001, and dedup-001. These values establish the message and its deduplication identity.

SQS should report the send as successful. Keep the message in the queue and send another message before the five-minute deduplication interval expires.

For the next send, use the different body accepted-duplicate but keep both group-001 and dedup-001. Because content-based deduplication is disabled and the bodies differ, the repeated explicit ID is the matching input in this comparison.

The duplicate-ID form changes the body to accepted-duplicate while retaining group-001 and dedup-001. The repeated explicit ID is the only deduplication match between the two sends.

Choose Send message and observe another success confirmation. The successful acknowledgement means SQS accepted the API request; it does not mean that another deliverable message was added.

The Console reports that the duplicate-ID request was sent and is ready to be received. Its service-generated message ID is excluded because the acknowledgement alone is the evidence needed here.

3. Add a control message with a new ID

Send one more message with body accepted-control, group ID group-001, and deduplication ID dedup-002. This ID has not appeared in the five-minute window, so the control message should be available after the original.

The control form contains accepted-control, group-001, and dedup-002. Its fresh ID provides the message that should remain deliverable after the original.

All three send operations should have returned success. The expected deliverable set still contains only two bodies because the two dedup-001 requests represent one deduplication identity.

4. Receive the deliverable messages

Use 10 as the batch ceiling and start polling. In this validation, both deliverable messages arrived as two rows during one polling session; the session lasted 30 seconds. If only the original appears, delete it and poll again so the next message in the same group becomes available.

The cropped receive view shows accepted-original, group-001, and dedup-001. No service-generated identifier or receipt value is retained.

Inspect only the body, message group ID, and deduplication ID. Do not publish the service-generated message ID, sequence number, receipt handle, timestamps, queue URL, or queue ARN.

Open the other row and confirm that its body is accepted-control. The expected detail values are group-001 and dedup-002.

The next cropped receive view shows accepted-control, group-001, and dedup-002. This is the unique-ID control message expected after the original.

Delete both rows while their current receipt handles are valid. A receipt handle belongs to one receive action, and a later receive returns a new one. If the 30-second visibility timeout expires while you inspect the details, poll again and delete the two rows immediately.

After deletion, run two complete polling sessions. The displayed polling duration is 30 seconds and the maximum message count is 10, while the queue's receive-message wait remains 20 seconds. Two completed sessions are required, both with zero available messages and zero rows. The suppressed body must remain absent.

The final completed polling session shows no available message and no message row. The preceding completed session produced the same zero-message result, and accepted-duplicate never appeared. The queue's 20-second receive wait enables long polling, which queries all SQS servers and reduces the false-empty behavior of short polling.

The received bodies are the proof set: accepted-original and accepted-control. The repeated dedup-001 request was acknowledged during sending but suppressed from delivery.

Wrap-up

The run produced two deliverable bodies from three acknowledged sends. The repeated identifier suppressed the later body, while the fresh identifier admitted the control.

SQS keeps tracking a deduplication ID even after its message is received and deleted. Outside the five-minute window, or when producer acknowledgement handling is uncertain for longer than that window, consumers should still use an application-level idempotency strategy.

Thanks for reading this far.

See you in the next one.

References

Trace a Lambda Invocation with AWS X-Ray

miruky — Thu, 03 Sep 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

AWS Lambda can emit service-level AWS X-Ray segments without application instrumentation. Active tracing records the Lambda service's work and the function execution as separate segments, which gives a small but useful trace map for a synchronous invocation.

This Console run creates a Python function with a fixed response, enables Lambda service traces, invokes the same empty private event three times, and inspects one sampled trace in CloudWatch. The article does not open raw trace data or publish trace IDs, request IDs, ARNs, account details, environment variables, annotations, or metadata.

X-Ray sampling and trace storage have current pricing terms, as do Lambda invocations and CloudWatch Logs. Review the linked pricing pages before enabling tracing on production traffic.

1. Create a tracing-capable execution role

The validation stays in us-east-1.

The header confirms United States (N. Virginia) while the Lambda Console is in English. This fixes the Region shared by the function and its trace data.

Open IAM, choose Roles, and create a role for the Lambda service. Enter miruky-eftzwycpzwhjwahl and attach AWSLambdaBasicExecutionRole plus AWSXRayDaemonWriteAccess.

The review shows miruky-eftzwycpzwhjwahl, AWSLambdaBasicExecutionRole, and AWSXRayDaemonWriteAccess together. The policies cover Lambda log delivery, trace upload, and the sampling-rule reads needed by X-Ray; they do not grant X-Ray configuration writes.

Open the role and verify its Lambda trust relationship and the two attached policies. The X-Ray policy grants xray:PutTraceSegments and xray:PutTelemetryRecords; the basic policy covers CloudWatch Logs writes.

The stacked crops show the final permissions review and the saved trust relationship. The role has exactly the two intended managed policies, and lambda.amazonaws.com can assume it. AWSXRayDaemonWriteAccess permits segment and telemetry uploads plus the three sampling read operations documented by its current policy version.

2. Create a function with deterministic output

Open Lambda and search for the exact name miruky-cokynoojzfivdjpl. The result should be empty before this validation creates the function.

The exact filter for miruky-cokynoojzfivdjpl returns no function. That empty result establishes the resource boundary before creation.

Choose Create function and Author from scratch. Enter miruky-cokynoojzfivdjpl, select Python 3.14 and x86_64, then choose the existing role miruky-eftzwycpzwhjwahl.

The form shows miruky-cokynoojzfivdjpl, Python 3.14, x86_64, and miruky-eftzwycpzwhjwahl together. These visible values fix the runtime and execution role before creation.

Replace the sample code with the fixed handler below and choose Deploy. It reads no event field and returns no runtime, request, environment, or identity value.

def lambda_handler(event, context):
    # Return a fixed value so tracing adds no application-data variability.
    return {"status": "traced"}

The deployed editor contains only the deterministic handler and its fixed traced value. The trace experiment therefore adds no application instrumentation or dynamic response data.

3. Enable Lambda service traces

Before changing the function, open Configuration, choose Monitoring and operations tools, and edit Additional monitoring tools. Inspect the Lambda service traces control before selecting it.

The Lambda service traces control is unchecked. The handler can still run in this state, but Lambda will not emit the two service-level X-Ray segments that this exercise needs to inspect.

Under CloudWatch Application Signals and AWS X-Ray, enable Lambda service traces and save.

The editor shows Lambda service traces enabled under the X-Ray controls. Saving that choice changes the function from pass-through behavior to active tracing.

Return to the monitoring configuration and confirm that tracing is active. Lambda now creates service-level segments automatically; this step does not add custom application subsegments, annotations, or metadata.

The saved configuration continues to show Lambda service traces enabled. The setting is persisted before any validation invocation is run.

AWS places the legacy X-Ray SDKs in maintenance mode and recommends OpenTelemetry for new custom instrumentation. This article uses only Lambda's built-in service tracing, so no X-Ray SDK dependency is bundled with the function.

4. Invoke a private event and find the sampled trace

Open the Test tab and create a private event named miruky-rnsdepoalbavxzhr with the JSON body {}. Save it and run the same event three times, leaving at least one second between invocations.

The event editor shows miruky-rnsdepoalbavxzhr, Private, and the empty object {}. Repeating this fixed event avoids adding attributes that could appear in trace details.

Each Console test should return {"status": "traced"}. X-Ray samples requests rather than recording every invocation; Lambda's documented sampling uses one request per second plus 5 percent of additional requests, and that sampling rate cannot be configured for Lambda functions.

The cropped result shows a successful invocation and {"status": "traced"}. Execution logs and request identifiers remain outside the image.

Open CloudWatch, choose X-Ray traces, and then choose Traces. Under Query refiners, keep Node selected. The generated function appears twice: once as Lambda Context and once as Lambda Function. Select Lambda Function, add it to the query, and run the query.

The refiners show miruky-cokynoojzfivdjpl as both node types, and the query returns three traces from the validation window. The generated query includes an account.id condition, so that query text and every trace identifier stay outside the retained image.

Open one row from the trace table without copying its trace ID.

The trace map should contain two Lambda nodes. The current map labels them Lambda Context and Lambda Function. In the segment timeline, those nodes correspond to AWS::Lambda for service work such as preparing the execution environment and AWS::Lambda::Function for work performed by the function.

The map visibly separates Lambda Context from Lambda Function. Both nodes belong to the selected invocation, but they represent different portions of its execution.

Open the segment timeline and inspect the status and duration columns. I kept the raw segment JSON closed because it contains unique IDs, timestamps, resource references, and other details that this article does not need.

The timeline shows AWS::Lambda and AWS::Lambda::Function with OK status and visible durations. The Logs section remains outside the image, and trace, segment, resource, and request identifiers are not retained.

Wrap-up

One synchronous test produced a trace with two different operational views: Lambda's service-side preparation and the function's own execution. The separation helps distinguish platform work from handler work before custom instrumentation is added.

For a new distributed application, use ADOT and OpenTelemetry when you need custom spans or multiple observability backends. Keep indexed attributes low-cardinality, avoid putting personal or secret data into trace attributes, and tune sampling against diagnostic value and cost.

X-Ray retains trace data for 30 days. Removing the function stops new traces, but an already recorded validation trace follows that service-controlled retention period.

Thanks for reading this far.

See you in the next one.

References

Alarm on an Amazon SQS Backlog with CloudWatch

miruky — Wed, 02 Sep 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

ApproximateNumberOfMessagesVisible reports how many Amazon SQS messages are available for consumers to retrieve. A rising value is a practical backlog signal when producers are outpacing consumers or no consumer is running.

This Console run creates a Standard queue and a CloudWatch metric alarm with a one-minute period. One queued payload moves the alarm from OK to In alarm; receiving and deleting it returns the metric below the threshold and the alarm to OK.

SQS publishes its standard queue metrics to CloudWatch without a separate metric charge. CloudWatch alarms and SQS requests have their own current pricing terms, so check both pricing pages before applying the settings outside this small validation.

1. Create and activate a Standard queue

This validation uses us-east-1, whose Region display name is United States (N. Virginia). The SQS queue, metric, and alarm all remain there.

The header confirms United States (N. Virginia) while the SQS Console is in English. This fixes the Region shared by the queue, metric, and alarm.

Open Amazon SQS and search for the exact generated name miruky-aaptabgtgqjvqmsx. The result should be empty before this validation creates the queue.

The exact filter for miruky-aaptabgtgqjvqmsx returns no queue. That empty result establishes the resource boundary before creation.

Choose Create queue, select Standard, enter miruky-aaptabgtgqjvqmsx, and keep the default delivery settings and SQS-managed server-side encryption.

The next image vertically stacks the type-and-name area with the encryption area from the same create-queue form. Nothing between those two areas changes the settings shown here.

The form visibly pairs Standard with miruky-aaptabgtgqjvqmsx and the default SQS-managed encryption. No delivery setting or dead-letter queue is added.

Open Send and receive messages, send the fixed body metric-seed, then receive and delete it. These operations activate the queue and provide CloudWatch with an empty baseline before the alarm experiment begins.

The next image stacks the identifier-excluded body crop with the deletion result from that same controlled receive. Message identifiers and receipt details are excluded.

The received message body is exactly metric-seed. Deleting it leaves the active queue with no visible backlog before the alarm is created.

SQS publishes metrics for active queues at one-minute intervals. A newly activated queue can take up to 15 minutes to appear in CloudWatch, so wait for the queue dimension rather than recreating the resource.

2. Select the visible-message metric

Open CloudWatch, choose All metrics, select SQS, and then choose Queue Metrics. Search for miruky-aaptabgtgqjvqmsx and select ApproximateNumberOfMessagesVisible.

The selected row combines ApproximateNumberOfMessagesVisible with miruky-aaptabgtgqjvqmsx. This binds the alarm to the generated queue's visible backlog.

Choose Select metric. Set the statistic to Maximum and the period to 1 minute; a maximum of at least one means a message was available for retrieval during that period.

The metric settings show Maximum and 1 minute. That combination records each period's observed maximum queue depth and therefore detects any period that reached at least one.

Use a static threshold and choose Greater/Equal with threshold 1. Under Additional configuration, set Datapoints to alarm to 1 out of 2 and choose Treat missing data as good (not breaching threshold).

The next image stacks the condition area with Additional configuration from the same alarm wizard page. No setting between those two areas changes the values shown here.

The condition shows Greater/Equal, threshold 1, 1 out of 2, and missing data treated as good. These four values determine both the trigger and recovery windows.

The M-out-of-N setting can react to one breaching minute without depending on a single one-minute evaluation window. Treating missing data as not breaching also prevents an inactive queue from becoming an alarm solely because SQS stopped publishing metrics.

3. Create the alarm without an external action

On the notification step, remove the alarm action for this validation. The article observes state changes in CloudWatch and does not create an SNS topic or send a notification to an email address.

The next image stacks the empty notification card with the final review's No actions result from the same alarm configuration.

The notification step shows no configured action. This keeps the validation limited to the alarm state and avoids creating a topic or contacting an address.

Enter the generated alarm name miruky-trzxgmdimxfnpnvk, leave the description empty, review the metric and threshold, and create the alarm.

The next image stacks the metric, condition, and alarm-name sections from that single final review page.

The review shows miruky-trzxgmdimxfnpnvk with the visible-message metric and fixed threshold. No action is listed in the final configuration.

Open the alarm and wait until its state is OK. A newly created alarm may initially be unevaluated while CloudWatch gathers its first result.

The alarm state reaches OK while the queue has no visible message. This is the baseline before the backlog message is sent.

4. Trigger the backlog alarm

Return to the queue and send one message with the body backlog-demo. Leave it unreceived for this step; receiving changes its state from available to in flight, so it no longer contributes to this backlog metric.

The send form and confirmation identify the fixed body backlog-demo. Leaving it unreceived keeps it in the visible-message metric.

Wait for the next one-minute metric publication and CloudWatch evaluation. The alarm should move to In alarm after at least one of its two evaluated periods has a maximum visible count of 1 or more.

The alarm state shows In alarm while the graph contains a breaching visible-message point. This is the first observed transition driven by queue backlog.

The SQS metric is approximate because the service is distributed, so it is appropriate for operational decisions rather than an exact transactional count. A production threshold should reflect normal arrival rate, consumer capacity, and the time a backlog can remain without violating a service objective.

5. Process the message and watch recovery

Open Send and receive messages, poll for backlog-demo, select it, and choose Delete. Receiving moves the queued item into its visibility-timeout window; deletion prevents it from returning afterward.

The next image stacks the identifier-excluded body crop with the deletion result from that same controlled receive. Message and receipt identifiers are excluded.

The selected message body is backlog-demo, and the deletion confirmation removes it from the queue. Only this fixed test payload is selected for deletion.

Return to the CloudWatch alarm and wait for two non-breaching one-minute periods to replace the breaching point in the evaluation window. The alarm should return to OK while the queue-depth line is below the threshold.

The alarm returns to OK after the breaching point leaves the two-period window. The graph now reflects the empty visible backlog.

Wrap-up

The queue state drove both alarm transitions. One queued payload breached Maximum at or above 1, and deleting it produced enough non-breaching data for CloudWatch to recover the alarm.

For production monitoring, a threshold of one is usually too sensitive. Tune the M-out-of-N window and threshold from observed traffic, and consider pairing backlog depth with the SQS oldest-message-age metric when delay matters more than raw count.

Thanks for reading this far.

See you in the next one.

References

Send Amazon S3 Object-Creation Events to Amazon SQS

miruky — Tue, 01 Sep 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

Amazon S3 can publish object-created event notifications directly to an Amazon SQS Standard queue. The destination queue needs a resource policy that permits the S3 service to call sqs:SendMessage, and the bucket and queue must be in the same AWS Region.

This Console run creates one private bucket and one encrypted Standard queue in N. Virginia. After the S3 configuration test message is identified, uploading event-proof.txt produces an ObjectCreated:Put record that names only the generated bucket and synthetic object key in the article evidence.

S3 storage, S3 requests, and SQS requests have separate pricing terms. The validation uses one tiny text object and a few queue operations, but the current pricing pages remain the source of truth for a real workload.

1. Create a private S3 bucket

Both resources in this run use us-east-1 because a direct S3 event-notification queue must be in the same Region as its bucket.

The header confirms United States (N. Virginia) while the Console is in English. This fixes the shared Region before the bucket and queue are connected.

Open S3, choose General purpose buckets, and search for miruky-oavzmwjgberlzvhx. The account-local list should have no exact match; the create request also provides the authoritative shared-global-namespace collision check.

The account-local filter for miruky-oavzmwjgberlzvhx returns no bucket. A successful create request will provide the separate global-name check.

Create the bucket in the shared global namespace with miruky-oavzmwjgberlzvhx in N. Virginia. The account regional namespace is outside this article because its name format can expose an account ID.

The next image vertically stacks two crops from the same create-bucket form. The divider marks the omitted middle controls; it does not join two different runs.

The form shows the shared global namespace, miruky-oavzmwjgberlzvhx, US East (N. Virginia), and all Block Public Access settings enabled. ACLs remain disabled and the default encryption remains selected.

Create the bucket and open its Properties tab. Confirm that the bucket is private and that no event notification exists yet.

The bucket's Event notifications area contains no configuration. This is the baseline before a queue destination is added.

2. Create a Standard queue and authorize S3

Open Amazon SQS and search for miruky-pmannkikxatnzsyf. The exact-name result should be empty before the queue is created.

The exact filter for miruky-pmannkikxatnzsyf returns no queue. That empty result establishes the queue ownership boundary for this run.

Choose Create queue, select Standard, and enter miruky-pmannkikxatnzsyf. Keep the default delivery settings and the default SQS-managed server-side encryption.

The next image vertically stacks the queue type and encryption portions of the same create-queue form.

The form visibly pairs Standard with miruky-pmannkikxatnzsyf and the default SQS-managed encryption. No dead-letter queue or delivery-setting override is added.

After creation, open the queue's Access policy and choose Edit. Keep the outer policy version at 2012-10-17, then add this statement to the existing owner policy. It does not require you to retrieve or paste an account ID: the queue ARN keeps a wildcard account segment, while aws:SourceAccount must equal the account that owns the queue at evaluation time.

{
  "Sid": "AllowS3ObjectNotifications",
  "Effect": "Allow",
  "Principal": {
    "Service": "s3.amazonaws.com"
  },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:us-east-1:*:miruky-pmannkikxatnzsyf",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:s3:::miruky-oavzmwjgberlzvhx"
    },
    "StringEquals": {
      "aws:SourceAccount": "${aws:ResourceAccount}"
    }
  }
}

The statement is attached to this generated queue and accepts sends only from the exact generated bucket ARN when the bucket's source account equals the queue owner's account. Save the policy, then review the queue overview without exposing its ARN or owner account number. The next image stacks the identity-excluding success and queue-summary portions of that same overview.

The cropped overview shows Standard and Amazon SQS key (SSE-SQS) after the source-restricted policy is saved. ARN and owner fields are excluded from the image.

3. Create the S3 event notification

Use the following bucket event-notification configuration.

The form shows miruky-vrgqsvmehfuyuoxt with All object create events selected. Prefix and suffix filters remain empty.

For the destination, choose SQS queue, select miruky-pmannkikxatnzsyf, and save. A successful save means S3 could validate the destination policy and publish its configuration test message.

The saved row connects All object create events to miruky-pmannkikxatnzsyf. The next queue poll distinguishes S3's configuration test from an object notification.

Open the queue, choose Send and receive messages, and poll. The configuration message uses s3:TestEvent, not the normal Records array used by object-created notifications, so identify and delete that test message before uploading the proof object.

The message body identifies s3:TestEvent; unlike the later object notification, this configuration message has no normal object-record array. Deleting it leaves the later upload as the only object-event proof.

S3 documentation notes that notification configuration changes can take about five minutes to become effective. If the test message has arrived but a subsequent object event has not, wait for propagation before changing the configuration.

4. Upload one object and inspect its event

Return to the S3 bucket, choose Upload, and add the local file event-proof.txt. The file contains one fixed non-secret line and its object key carries no user or application data.

The upload review contains only event-proof.txt in the generated bucket. Its contents are the fixed non-secret validation line prepared for this run.

Complete the upload and confirm that the object appears in the bucket. The Console upload uses a PutObject request for this small file, so the expected event name is ObjectCreated:Put.

The object list shows event-proof.txt with a successful upload status. This completed upload is the action the next queue message must correlate.

Poll the SQS queue again and open the new message. The complete body stays private because S3 notifications can contain an IAM principal ID, source IP address, request IDs, host ID, ETag, and sequencer.

The isolated receive table now shows Messages (1). The separate approximate Messages available counter reads zero because the retrieved message is temporarily in flight; the table count is the relevant proof that one message was returned by this poll. Its full body remains private until sensitive fields are excluded from the evidence crop.

For comparison, I retained six fields that do not identify the account or operator. The following is a deliberately reduced excerpt transcribed from the verified values, not a copy of the complete message body.

{
  "eventVersion": "2.5",
  "eventSource": "aws:s3",
  "awsRegion": "us-east-1",
  "eventName": "ObjectCreated:Put",
  "s3": {
    "bucket": {
      "name": "miruky-oavzmwjgberlzvhx"
    },
    "object": {
      "key": "event-proof.txt"
    }
  }
}

The screenshot below vertically stacks narrow crops from that same SQS message body. The dividers mark omitted sensitive fields, and the line-wrapped bucket name and object key are joined only at their original wrap points.

The retained fields show 2.5, aws:s3, us-east-1, ObjectCreated:Put, miruky-oavzmwjgberlzvhx, and event-proof.txt. Principal, network, request, host, checksum, and sequencer fields are outside the crop.

Wrap-up

The queue received two different S3 messages: the configuration-time s3:TestEvent and the later ObjectCreated:Put record for the uploaded text file. Separating them prevents the setup test from being mistaken for object-delivery proof.

S3 Event Notifications are designed for at-least-once delivery and do not guarantee event order. A consumer should tolerate duplicates, use the object key's URL-encoded form correctly, and apply an idempotency strategy appropriate to its workload.

For a production path, add observability outside this minimal run: send S3 server access logs to a separate logging bucket, enable CloudTrail data events for the source bucket, and monitor relevant S3 and SQS CloudWatch metrics. These controls introduce additional storage, request, or monitoring costs, so include them in the workload estimate.

Thanks for reading this far.

See you in the next one.

References

Catch and Recover from a Failed AWS Step Functions Task

miruky — Mon, 31 Aug 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

An AWS Step Functions Task failure ends a workflow unless a retry succeeds or a catcher handles the reported error. A useful catcher should recognize one expected failure without converting unrelated faults into success.

The design has three fixed parts: an AWS SDK GetParameter Task, an ErrorEquals entry for Ssm.ParameterNotFoundException, and a Recovered Pass state with a small result object.

I use an Express workflow with execution logging set to OFF. The design excludes both Standard workflow history and a CloudWatch Logs copy; Section 4 inspects only the immediate synchronous response.

No Lambda function, Parameter Store parameter, or CloudWatch Logs log group is created. A clean run of the finished path performs one short Express execution and one GetParameter request. Check the current Step Functions and Parameter Store pricing pages before adapting the pattern to a recurring workload.

1. Establish the missing-parameter condition

The validation starts from an English AWS Console in N. Virginia.

The header shows United States (N. Virginia) while the Step Functions Console is in English. This fixes us-east-1 as the Regional context for the state machine and its Parameter Store call.

Next, open Parameter Store without creating a parameter.

The page shows Start to use Parameter Store and Create parameter, with no parameter list in this Region. The generated name miruky-awyoqxtnwnrjhexm is therefore absent, and the exercise never creates it.

If your account already has parameters, search for the full generated name and confirm that no exact row exists. If it does exist, stop and generate a new name; do not inspect, modify, or delete a resource that belongs to another workload.

2. Create the execution role

The workflow needs permission to read only the intended parameter path. It does not need permission to create, change, list, or delete parameters.

The trust policy needs your AWS account ID in two places. Replace both YOUR_ACCOUNT_ID placeholders in the Console, and keep the real value out of screenshots, notes, and published Markdown.

Use this trust policy for the role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "states.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:states:us-east-1:YOUR_ACCOUNT_ID:stateMachine:*"
        },
        "StringEquals": {
          "aws:SourceAccount": "YOUR_ACCOUNT_ID"
        }
      }
    }
  ]
}

The service principal allows Step Functions to assume the role. The two conditions limit that trust to state machines from the current account in N. Virginia, following the confused-deputy guidance in the Step Functions documentation.

Add an inline policy named miruky-fswatmkcbokhffcr:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:GetParameter",
      "Resource": "arn:aws:ssm:us-east-1:*:parameter/miruky-awyoqxtnwnrjhexm",
      "Condition": {
        "StringEquals": {
          "aws:ResourceAccount": "${aws:PrincipalAccount}"
        }
      }
    }
  ]
}

The policy summary makes the permission boundary visible without publishing the account segment of the ARN.

GetParameter is selected as the only action; the adjacent read operations remain unchecked. No write or list permission broadens the exercise.

The resource and condition fields provide a separate scope check before the policy is saved.

The Resources field contains one N. Virginia parameter ARN ending in miruky-awyoqxtnwnrjhexm. The request condition shows aws:ResourceAccount (StringEquals) ${aws:PrincipalAccount}, so the wildcard account segment cannot authorize a parameter from another account.

The completed role provides a second checkpoint before Step Functions can assume it.

The role has one permissions policy, the inline policy miruky-fswatmkcbokhffcr. No unrelated managed policy is attached, while the trust relationship remains the Step Functions policy defined above.

3. Define the specific catcher

The generated state-machine name must also be unused before creation.

The exact search for miruky-pxnzifxuhsojmzmb returns No state machines. This avoids modifying or replacing an existing workflow.

Use the following Amazon States Language definition:

{
  "Comment": "Catch an expected missing-parameter error.",
  "StartAt": "ReadMissingParameter",
  "States": {
    "ReadMissingParameter": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:ssm:getParameter",
      "Parameters": {
        "Name": "miruky-awyoqxtnwnrjhexm"
      },
      "Catch": [
        {
          "ErrorEquals": [
            "Ssm.ParameterNotFoundException"
          ],
          "Next": "Recovered"
        }
      ],
      "Next": "UnexpectedSuccess"
    },
    "Recovered": {
      "Type": "Pass",
      "Result": {
        "status": "recovered",
        "reason": "parameter-not-found"
      },
      "End": true
    },
    "UnexpectedSuccess": {
      "Type": "Fail",
      "Error": "UnexpectedParameterPresent",
      "Cause": "The validation parameter existed."
    }
  }
}

The editor exposes both the intended recovery route and the guard against an unexpected success.

ReadMissingParameter catches only Ssm.ParameterNotFoundException and routes that value to Recovered. A successful read goes to UnexpectedSuccess, which fails the workflow because the precondition would no longer hold.

The visual workflow exposes the two terminal paths before creation.

The Catch #1 branch ends at Recovered, while the normal service-call edge ends at UnexpectedSuccess. That separation prevents the exercise from reporting success if the supposedly absent parameter is present.

AWS SDK integrations construct catchable errors differently from the source API name. The Step Functions service prefix is PascalCase, and the exception name needs the Exception suffix. That is why the SSM API error ParameterNotFound becomes Ssm.ParameterNotFoundException in ErrorEquals.

The state-machine configuration controls both execution behavior and retained data. Select the existing role miruky-ijbldxcdcaabrrxe rather than asking Workflow Studio to create another role.

The Express card is selected, which enables a synchronous Console invocation and does not retain Step Functions execution history. The execution role still supplies the narrowly scoped GetParameter permission at runtime.

Set the execution log level to OFF for this one-time validation.

OFF prevents Step Functions from delivering execution events to CloudWatch Logs. Because no log destination is configured, this run does not create an execution-history log group.

Open Additional configuration and leave X-Ray tracing disabled.

The Enable X-Ray tracing checkbox is unchecked, as are the unrelated versioning and customer-managed-key options. The validation therefore adds neither X-Ray traces nor a new KMS dependency.

4. Run synchronously and verify recovery

A synchronous invocation returns the final output directly to the Console.

The dialog uses Synchronous, a generated execution name, and {} as the input. The input contains no user, account, or application data, and the Open in a new browser tab checkbox remains unchecked.

After the short request finishes, the returned result proves which terminal branch ran.

The dialog reports Express execution completed successfully. and returns an output containing only recovered and parameter-not-found. Recovered is the only state that can produce that object, while an existing parameter would have reached UnexpectedSuccess and returned a failed result.

The final Console view confirms that logging-off Express runs do not become stored execution history.

The Executions tab contains no execution rows and displays Logging is disabled. This matches the documented Express behavior: Step Functions does not capture Express execution history, and the Console can reconstruct it only from CloudWatch Logs when logging is enabled.

Wrap-up

The service call failed for the intended reason, the catcher matched the exact Step Functions error name, and the workflow returned a small success object through Recovered. A permissions error, malformed request, timeout, or another unexpected task failure would remain unhandled and visible instead of being hidden behind States.ALL.

Synchronous Express also kept this one-time validation from leaving a Standard execution record. That choice is useful for this controlled demonstration; production systems may need CloudWatch Logs or a Standard workflow when durable execution history is part of the operational requirement.

Thanks for reading this far.

See you in the next one.

References

Reject a Schema-Invalid JSON Body Before API Gateway Calls a Backend

miruky — Sun, 30 Aug 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

A backend should still enforce its own business rules, but it does not need to receive every structurally invalid request. Amazon API Gateway REST APIs can validate a request body against a JSON Schema model before proceeding with the integration request.

This Console run creates a POST /orders method with a mock integration. A body missing the required quantity property returns 400 from API Gateway, while a valid body continues through the mock integration and returns 200. No Lambda function, HTTP endpoint, deployment stage, or public invoke URL is required.

The exercise creates one REST API and uses only Console test invocations. API Gateway request pricing can change and differs by API type and Region, so check the current pricing page before using the pattern for production traffic.

1. Create a Regional REST API

API Gateway resources are Regional, so this run keeps the API and its Console tests in us-east-1. The opening screenshot establishes the English Console and Regional context before any API resources are added.

The header confirms United States (N. Virginia) while the API Gateway Console is in English. This fixes the Regional context before any API resources are added.

Open API Gateway, choose APIs, and search for the exact generated name miruky-zazteywtwjosovgu. An empty exact-name result prevents this validation from colliding with an existing API.

The exact filter for miruky-zazteywtwjosovgu returns no API. That empty result establishes the resource boundary for the validation run.

Choose Create API, find REST API, and choose Build. Select New API, enter miruky-zazteywtwjosovgu, choose Regional as the endpoint type, and leave the description empty.

The form visibly pairs miruky-zazteywtwjosovgu with the Regional endpoint type. No description or deployment-stage value is added.

After creation, open Resources and select the root resource. Do not deploy the API; the built-in method test can exercise the configuration without creating a stage or exposing an invoke URL.

The resource tree contains only / at this point. The next step adds the request path without deploying the API.

2. Define the accepted JSON body

Open Models and choose Create model. Enter the alphanumeric generated name mirukytpnntggdocvcenbn, use application/json, and save this JSON Schema draft 4 model.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "required": ["product_id", "quantity"],
  "properties": {
    "product_id": {
      "type": "string"
    },
    "quantity": {
      "type": "integer",
      "minimum": 1
    }
  }
}

The form shows mirukytpnntggdocvcenbn, application/json, and the complete schema together. Those values bind the model to the content type used by both test requests.

Open the saved model and inspect its schema. The model requires both properties and accepts only an integer of at least 1 for quantity.

The saved schema retains product_id, quantity, integer, and minimum as configured. That persisted model is the one attached to the method request later.

API Gateway models for REST APIs use JSON Schema draft 4, with documented feature limitations. Keep application-specific semantic validation in the backend even when the gateway checks the basic payload shape.

3. Add a POST method backed by a mock integration

Return to Resources, create the child resource /orders, and add a POST method. Choose Mock as the integration type so API Gateway itself can provide the successful response.

The method view visibly combines POST, /orders, and Mock. This keeps the accepted path self-contained inside API Gateway for the comparison.

On Integration request, add an application/json mapping template with this body. It selects the 200 integration response when a request passes method validation.

{"statusCode": 200}

The request template contains {"statusCode": 200} for application/json. A request that reaches this integration is therefore routed to the success response.

On the default Integration response, add an application/json mapping template that returns a small synthetic response. The response contains no request data and does not echo any header or identifier.

{"accepted": true}

The response template contains {"accepted": true} for application/json. Its fixed body distinguishes the successful path from a gateway validation error.

Open Method request, choose Edit, and select Validate body as the request validator. Under Request body, add application/json and choose mirukytpnntggdocvcenbn as the model, then save.

The saved method request shows Validate body, application/json, and mirukytpnntggdocvcenbn together. The validator and model are now attached to the same content type used in the tests.

The content type matters. API Gateway performs body validation only when the request content type matches a configured model; a production API must define the intended behavior for other content types as well.

4. Compare a rejected body with an accepted body

Open the method's Test tab and submit this syntactically valid JSON object. It is structurally invalid for the method because the required quantity property is absent.

{
  "product_id": "sku-001"
}

The request body visibly contains product_id but omits the required quantity property. It is valid JSON, which isolates the model's required-property check from JSON parsing.

Choose Test after entering the body, and keep the result pane open for the comparison.

The result shows 400 and {"message": "Invalid request body"}. This gateway-generated response confirms that the request stopped at body validation.

The log says Request body does not match model schema for content type application/json, then identifies quantity inside the missing-required-properties message. It ends with Method completed with status: 400, tying the validation failure to the result above.

Now submit a body that satisfies the same model. The quantity value is an integer and meets the schema's minimum.

{
  "product_id": "sku-001",
  "quantity": 2
}

The valid body visibly contains both product_id and quantity, with the latter set to 2. It differs from the rejected body only in the required field under test.

Choose Test again without changing the method validator, model, or mock templates.

The accepted result shows 200 and {"accepted": true}. This fixed body is the response configured on the mock integration path.

The log says Request validation succeeded for content type application/json and then shows Method response body after transformations. It ends with Method completed with status: 200, matching the successful result above.

Wrap-up

The comparison separates two outcomes at the API boundary. The missing-property body stopped with a gateway-generated HTTP 400, while the model-compliant body proceeded to the integration and received its fixed HTTP 200 response.

Basic request validation is useful for required fields, types, and supported JSON Schema constraints. Authorization, cross-field business rules, database state, and other application semantics still belong in the appropriate backend controls.

Thanks for reading this far.

See you in the next one.

References

Prevent a Stale DynamoDB Update with a Conditional PartiQL Statement

miruky — Sat, 29 Aug 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

Two writers can read the same Amazon DynamoDB item and then try to save different changes. If both writes are unconditional, the later write can overwrite a newer state without realizing that its copy was stale.

This Console run adds a numeric item_version attribute and includes the expected version in a PartiQL UPDATE statement. One update moves the item from version 1 to version 2, a deliberately stale version-1 update fails with ConditionalCheckFailedException, and a fresh version-2 update succeeds.

The table uses on-demand capacity and holds one synthetic item. Request and storage charges still follow the current DynamoDB pricing page, so review that page before leaving a table running or adapting the pattern to production traffic.

1. Create an on-demand table and seed version 1

DynamoDB tables and their data are Regional, so every table operation in this run stays in us-east-1. The first screenshot establishes the English Console and Regional context before any table exists.

The header confirms United States (N. Virginia) while the DynamoDB Console is in English. This fixes the Regional context before the table is created.

Open DynamoDB, choose Tables, and search for the exact generated name miruky-abwmppcmmfrhlnmh. The result should be empty before the validation creates a table.

The exact filter for miruky-abwmppcmmfrhlnmh reports 0 matched results and No tables found. That empty result establishes that the validation does not reuse an existing resource.

Choose Create table. Enter miruky-abwmppcmmfrhlnmh, set the partition key to item_id with type String, omit the sort key, and keep the default settings with on-demand capacity.

The form combines miruky-abwmppcmmfrhlnmh, item_id, String, and the default table settings. No sort key is defined for this singleton-update exercise.

Wait until the table status is Active. The table needs no secondary index, stream, global-table replica, or sample data beyond the single item used for this comparison.

The overview shows Active and lists only item_id in the primary key. The next operation can now seed the single synthetic item.

Open PartiQL editor and run this singleton INSERT. The values are deliberately generic and contain no user, account, or application data.

INSERT INTO "miruky-abwmppcmmfrhlnmh" VALUE {
  'item_id': 'item-001',
  'item_state': 'draft',
  'item_version': 1
}

The editor reports a successful INSERT for the controlled item. A read is still needed to prove the stored attribute values.

Run a key-based SELECT. The result should contain one item with item_state set to draft and item_version set to 1.

SELECT * FROM "miruky-abwmppcmmfrhlnmh"
WHERE item_id = 'item-001'

The result shows item_state as draft and item_version as 1. This is the baseline that the first conditional update expects.

2. Apply a version-checked update

A writer expects version 1, so its condition matches the stored item. It changes the state and increments the version in the same single-item operation.

UPDATE "miruky-abwmppcmmfrhlnmh"
SET item_state = 'published'
SET item_version = 2
WHERE item_id = 'item-001' AND item_version = 1
RETURNING ALL NEW *

The successful response returns published and version 2. Those post-update values establish why another writer still expecting version 1 is stale.

RETURNING ALL NEW * makes the successful post-update attributes visible in the response. The condition still resolves to exactly one primary-key value because the WHERE clause includes item_id = 'item-001'.

3. Reject a writer holding stale version 1

Now simulate another writer that read the original item but did not see the successful update. It still expects item_version = 1 and attempts to write a different state.

UPDATE "miruky-abwmppcmmfrhlnmh"
SET item_state = 'archived'
SET item_version = 3
WHERE item_id = 'item-001' AND item_version = 1
RETURNING ALL NEW *

The editor visibly keeps item_version = 1 in the condition while requesting version 3. That mismatch is deliberate; the stored item is already at version 2.

Run the statement. DynamoDB should return ConditionalCheckFailedException because the stored item is already at version 2, so the complete WHERE condition is false.

The editor reports ConditionalCheckFailedException rather than updated attributes. The rejected response alone does not prove the item stayed unchanged, so the next read checks the stored state.

The failed condition is the protection mechanism; it is not a partial success. Run the same key-based SELECT again and confirm that item_state remains published and item_version remains 2.

The follow-up read still shows published and version 2. Neither protected attribute moved to the stale writer's requested values.

4. Retry from the current version

A client should not blindly repeat the stale statement. It should read the current item, reconcile its intended change, and submit a new condition using the version it actually observed.

For this controlled run, update the expectation to version 2 and advance the stored version to 3. The state change is otherwise the same as the rejected attempt.

UPDATE "miruky-abwmppcmmfrhlnmh"
SET item_state = 'archived'
SET item_version = 3
WHERE item_id = 'item-001' AND item_version = 2
RETURNING ALL NEW *

The fresh update returns archived and version 3 after its condition uses the current version. This contrasts with the rejected statement without changing the intended state transition.

Run one final key-based SELECT. The stored item should now contain archived and version 3, proving that the same logical change succeeds only after its expected version matches the current item.

The final read confirms archived and version 3 as the stored values. The three observed states now match the version-check sequence.

Wrap-up

The stale writer did not overwrite the newer DynamoDB item. Its version predicate failed, DynamoDB returned a condition error, and a read showed that both protected attributes remained at their version-2 values.

In an application, return a conflict to the caller or re-read and reconcile the latest item instead of hiding this failure in an unconditional retry. If several items must change together, use a DynamoDB transaction rather than treating multiple singleton PartiQL statements as one atomic unit.

Thanks for reading this far.

See you in the next one.

References

Test an AWS Lambda Function with a Private Console Event

miruky — Fri, 28 Aug 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

A Lambda test event is JSON input that the AWS Console sends directly to a deployed function. It is useful when I need to separate a handler check from an EventBridge rule, API Gateway route, Amazon SQS queue, or another integration.

This Console run creates a minimal Python function, stores an empty private test event, and reads the fixed response from one synchronous invocation. The handler does not read the event, environment variables, account data, or the invocation context.

Private test events are available only to their creator. AWS currently allows up to 10 private events per function, and the Console documentation says they require no additional permissions to use. A Console test still counts as a Lambda request and execution duration, and the invocation writes a small record to CloudWatch Logs, so current Lambda and CloudWatch pricing still applies.

1. Create a narrow execution role

Lambda functions are Regional, so this exercise keeps the function and its test in us-east-1.

The header confirms the English Console and United States (N. Virginia) before any Regional resource is created.

Open IAM, choose Roles, and create a role for the Lambda service. Attach the AWS managed AWSLambdaBasicExecutionRole policy, then enter the generated role name miruky-vkgewtncrkrrykpz.

The review fixes the generated role name and Lambda use case before creation. AWSLambdaBasicExecutionRole grants the log-group, log-stream, and log-event permissions needed for basic CloudWatch logging; it does not grant access to application data in another AWS service.

Open the new role and choose Trust relationships. The trusted service must be lambda.amazonaws.com, because Lambda assumes this role when it invokes the function.

The trust policy contains lambda.amazonaws.com, the Lambda service principal, while the account-scoped ARN is masked. I also checked that the role had one attached managed policy and no inline policy before using it.

2. Create and deploy the fixed handler

Open Lambda and search for the exact generated function name miruky-wcyrodwkfbmgaqxd. The validation account had no function with that name before creation.

The table reports Functions (0) while the full generated name is in the filter. That empty result establishes the ownership boundary for the function used in this run.

Choose Create function and Author from scratch. Enter miruky-wcyrodwkfbmgaqxd, choose Python 3.14, leave the ARM64 switch off for the default x86_64 architecture, and enable Custom execution role. Select miruky-vkgewtncrkrrykpz as the existing role.

The two retained form sections show the inputs that matter for the exercise. The ARM64 option is off, and its label identifies x86_64 as the default.

After the function is created, replace the sample code in lambda_function.py with this handler and choose Deploy.

def lambda_handler(event, context):
    # Keep the response fixed so the test event cannot change the result.
    return {"status": "running"}

The default handler setting for a Python function created in the Console is lambda_function.lambda_handler, so the file and function names already match that configuration.

The editor contains no credential, account identifier, environment lookup, or request metadata. The deployment confirmation establishes that the later test runs this version rather than an unsaved editor change.

3. Save an empty private test event

On the function's Test tab, create a new event. Enter the generated event name miruky-debteowwasuirptw, keep Private selected, and replace the template with an empty JSON object:

{}

The handler ignores its input, so an empty object is enough. Keeping the event private avoids creating a shareable EventBridge schema and avoids exposing the event to other IAM users in the account.

The event editor shows {} and leaves Shareable unselected. Choose Save before invoking the function so the same named event can be selected again later.

The success banner contains the generated event name. It confirms that the event was stored before the invocation result was collected.

4. Invoke the deployed function

With miruky-debteowwasuirptw selected, choose Test. The invocation is synchronous, so Lambda waits for the handler response before returning the result or an invocation error.

Expand Details under the execution result. The expected response is:

{
  "status": "running"
}

The result reports Executing function: succeeded and returns the same object that the deployed handler contains. Because the event is empty and the response is fixed, this result verifies the deployed runtime, handler name, code, and execution role without adding an external trigger.

This test does not prove that an API Gateway route, queue, stream, schedule, or resource policy is configured correctly. Those integrations need their own end-to-end test with the real event shape and permissions. The private Console event is the smaller check that I run before introducing those variables.

Wrap-up

The useful evidence is a short chain: an exact-name-empty function inventory, a named execution role with Lambda trust, deployed deterministic code, a saved private {} event, and a synchronous success response.

Private events are convenient for repeatable manual checks and account-specific payloads that should not be shared. For a build pipeline or repeated regression suite, move the same assertion into an automated test rather than depending on a person to choose Test in the Console.

Thanks for reading this far.

See you in the next one.

References

Find Who Deleted an AWS Resource with CloudTrail Event History

miruky — Thu, 27 Aug 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

CloudTrail Event history provides a searchable record of recent management activity without requiring a trail. A deletion investigation can start with the API event name, time, Region, resource name, and the AWS principal or session shown in the User name field.

This controlled Console run creates and deletes one generated SQS queue, then correlates its management event in N. Virginia.

Event history covers the most recent 90 days of management events in one account and Region, and it accepts one lookup attribute plus a time range. Viewing and searching that history has no additional CloudTrail charge under the current pricing page.

1. Create one uniquely named queue

Open the English SQS Console in N. Virginia. CloudTrail Event history is Regional, so the test API call and the later lookup both stay in us-east-1.

The header shows United States (N. Virginia) while the English SQS Console is open.

Open Amazon SQS and search for miruky-qnehvscrnwilwtac. The full-name filter should return no existing queue before the run.

The search bar reports 0 matches, and the empty results area confirms that the generated queue is not already present.

Choose Create queue, keep Standard selected, and enter the generated name. Review the queue settings and create it without adding a consumer or resource policy.

The form pairs the exact generated name with the Standard queue type before creation.

Open the newly created queue. Its generated name is the correlation key used later in Event history.

The details view confirms the same generated name that will be used for CloudTrail correlation.

2. Produce one deletion management event

Choose Delete and follow the acknowledgement prompt for the generated queue. This action exists here to generate one known control-plane event, not as a general queue-management recommendation.

The dialog identifies only the owned validation queue, shows that it contains zero messages, and requires the explicit confirm acknowledgement before deletion.

After the Console returns to the queue list, filter by the full name again. A zero result establishes that the resource deletion completed before the audit search begins.

The repeated full-name search is the deletion-completion evidence: it reports 0 matches and returns no queue.

Record the visible completion time privately. Event history is an audit lookup, not the transactional confirmation of deletion, so use the SQS absence check for completion and refresh CloudTrail separately.

3. Narrow Event history to DeleteQueue

Open CloudTrail, choose Event history, and keep the Region at N. Virginia. Set a short relative time range that includes the queue deletion.

Choose Event name as the lookup attribute and enter DeleteQueue. Event history allows one attribute filter at a time, so the time range supplies the additional narrowing dimension.

The search is now constrained by Event name = DeleteQueue and the visible time range.

Refresh until the row associated with miruky-qnehvscrnwilwtac appears. Compare the event time, sqs.amazonaws.com source, and generated resource name with the queue action rather than selecting an older deletion only because its event name matches.

The single row aligns DeleteQueue, sqs.amazonaws.com, the event time, and the visible miruky-qnehvscrnwilw... resource prefix. I hid the User name column before retaining that image. The next detail crop preserves the complete generated name while masking its account-scoped URL segment.

4. Read the actor field without publishing it

Open the matched event. The cropped summary should preserve the event name, event time, event source, AWS Region, and generated resource reference.

The summary preserves the event name, time, source, Region, and generated resource while excluding actor fields and raw JSON.

On your own screen, read the User name value for the same row or event. CloudTrail documents that this field can identify a user, role name, or service role; it is not always a person's name.

The lookup menu also exposes User name as a filter. After you have copied the exact value within your protected investigation record, you can switch the single lookup attribute from Event name to User name to find other recent events for that principal or session.

The menu confirms that User name is available as the next lookup attribute without exposing its value.

If the value represents a federated or assumed-role session, CloudTrail identifies the AWS session, not necessarily the human behind it. Map that session to identity-provider, workforce sign-in, or session-tag records before assigning individual responsibility.

Wrap-up

The useful result was not DeleteQueue alone. The generated resource name, Regional event history, event time, service source, and principal or session field together narrowed the deletion to one control-plane request.

Event history is suitable for a recent, single-account investigation. Retention beyond 90 days, organization-wide search, multiple-field queries, and governed long-term analysis require a trail, CloudTrail Lake, or another centralized audit design.

Thanks for reading this far.

See you in the next one.

References

Roll Back a Systems Manager Parameter with Version History

miruky — Wed, 26 Aug 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

AWS Systems Manager Parameter Store creates a new version each time a parameter value changes. Reapplying an earlier value therefore moves the version number forward; it does not turn the current version back to an old number.

I tested that behavior with one Standard String parameter. The value starts as INFO in version 1, changes to DEBUG in version 2, and returns to INFO in version 3. Each state is verified in the AWS Console before the next change.

The two values are ordinary configuration tokens, not secrets. I did not use SecureString, a KMS key, an endpoint, a password, or an account-specific value. The current AWS documentation lists Standard parameters at no additional charge; Advanced parameters and higher-throughput interactions have different pricing.

1. Create a non-secret Standard parameter

Parameter Store parameters exist only in the Region where they are created. I kept this run in us-east-1 and recorded the Regional context before creating anything.

The page still shows United States (N. Virginia), and Start to use Parameter Store confirms that the Region contained no parameters before this run. That empty state also proves that the generated name miruky-isdeziwttyxgqaoc was not already in use.

Choose Create parameter and enter the generated name. Keep the tier on Standard and the type on String. Standard is important here because Advanced parameters can incur charges and cannot later be downgraded in place.

The upper form visibly keeps Standard and String selected for the generated name. I then moved to the lower part of the same form to enter the value.

The lower form shows String, text, and INFO, while the Tags panel reports no tags. Plain-text parameters must not contain a credential or any other secret. I created the parameter and opened its Overview tab.

Overview confirms the current value INFO and version 1. There is only one version at this point, so no rollback behavior has occurred yet.

2. Create an unwanted version 2

Choose Edit and replace INFO with DEBUG. The form keeps the parameter tier and type fixed while allowing the current value to change.

The Value field now contains DEBUG while Standard and String remain fixed. I saved the change, reopened the parameter, and checked Overview.

Overview now shows DEBUG as version 2. This is the deliberately unwanted state, and an unversioned read now resolves to it.

3. Confirm that History retained both versions

Open the History tab. The current Console lists versions 2 and 1 as separate rows with their own modification times. The earlier version still exists; the update did not erase it.

One current-Console detail matters: this History table shows version metadata, not the historical value itself. For this console-only run, I use the INFO value already recorded on the version-1 Overview page. If the earlier value is unknown, retrieve the required version with a version-aware API, CLI, SDK, or SSM document instead of guessing it.

History also has no operation that changes the latest pointer back to version 1. Making the known earlier value current requires one more saved edit.

4. Restore the value as version 3

I opened the parameter editor and entered the previously recorded value.

The Value field is back to INFO, while the immutable type remains String. I saved this change and reopened Overview.

Overview now shows INFO with version 3; the rollback is a forward version change. I returned to History once more to check the retained rows.

The table retains 3, 2, and 1 as separate version rows. Version 2 remains part of the audit trail instead of disappearing when INFO becomes current again.

An unversioned parameter read now resolves to the latest version, which is version 3. A version-aware client that explicitly requests version 2 remains pinned to the retained version-2 value; restoring the latest value does not rewrite an older version.

Wrap-up

The rollback in this Console run is an auditable forward change. Version 1 records the original INFO, version 2 records the temporary DEBUG, and version 3 makes INFO current again.

For production configuration, decide whether consumers follow the latest value, an explicit version, or a movable parameter label. That reference choice determines whether creating a restored current version changes application behavior.

Thanks for reading this far.

See you in the next one.

References

Run a One-Time EventBridge Schedule That Deletes Itself

miruky — Tue, 25 Aug 2026 00:00:00 +0000

Introduction

Hi, I'm miruky.

An EventBridge Scheduler one-time schedule invokes its target at one date and time. Completion alone does not remove the schedule from the Regional schedule quota, so the create flow offers a separate Action after schedule completion setting.

This Console run sends one-time-schedule-fired to a standard SQS queue, then verifies that a schedule configured with DELETE is absent after the invocation. The schedule uses Asia/Tokyo as its evaluation time zone while every AWS resource stays in N. Virginia.

EventBridge Scheduler and SQS meter usage separately. This run makes one scheduled invocation plus a small number of queue requests, but current free-tier eligibility depends on the account and monthly usage; check both pricing pages before repeating it.

1. Create the SQS target in N. Virginia

This run stays in us-east-1 from resource creation through verification. The schedule and its SQS target must remain in the intended Region throughout the run.

The header still shows United States (N. Virginia), so the Regional context is explicit before the queue is created.

With N. Virginia still visible in the header, open Amazon SQS, choose Create queue, and keep Standard selected. Enter miruky-fsashpslzjzefiib, review the encryption and access settings, and create the queue. I kept the default queue settings because the validation needs only one ordinary message.

The form visibly keeps Standard selected with the generated queue name.

The queue is only the target for one SendMessage call. It does not need a public access policy, an SNS subscription, or a Lambda consumer for this validation.

2. Define a one-time schedule

Open Amazon EventBridge Scheduler, choose Create schedule, and enter miruky-upzizvveloaxuyek. Keep the existing default schedule group instead of creating another resource.

Choose One-time schedule and set a date and time at least ten minutes ahead. I selected Asia/Tokyo as the time zone and turned the delivery window Off, so the review page showed one specific planned time rather than a delivery range.

The form now binds one date and time to Asia/Tokyo, and the delivery window reads Off.

The schedule time zone does not move the AWS resources to Tokyo. It only tells Scheduler how to interpret the date and clock time entered in this form; the schedule and queue remain in us-east-1.

3. Select the templated SQS target

Choose Next, select Templated targets, and choose Amazon SQS SendMessage. Select only the generated queue miruky-fsashpslzjzefiib from the target list.

The queue selector retains the generated queue name, while the account-scoped portion is masked in the saved image.

Scheduler accepts text input for this templated SQS target, so the message does not need a JSON wrapper. A fixed payload lets the received body be compared character for character. Enter the following plain-text payload:

one-time-schedule-fired

The editor contains the exact value one-time-schedule-fired.

This target type calls sqs:SendMessage. Scheduler needs an execution role with that permission for the selected queue; selecting a target does not let the service bypass IAM.

4. Enable automatic deletion and create the role

On Settings, leave the schedule enabled. Under Action after schedule completion, select DELETE rather than NONE.

The enabled toggle and DELETE selection are now fixed for this run.

Choose Create new role for this schedule and enter miruky-kkvefpaiwudhkxri as the role name.

The permissions panel uses the generated role name while leaving the existing-role option unselected.

The generated role carries the corresponding target permission for the selected SQS queue.

I left the optional dead-letter queue unset for this short validation. A production schedule should define failure handling that matches its retry window and the operational path for messages that exhaust retries.

5. Review the exact schedule behavior

Choose Next and read the review page from the schedule pattern through the target and settings. Confirm the one-time timestamp, Asia/Tokyo, delivery window Off, the generated SQS queue, enabled state, and action after completion DELETE.

The review repeats the one-time timestamp, time zone, delivery-window setting, and generated queue from the earlier steps. I then created the schedule before the planned time passed.

The exact-name row reports Enabled, so Scheduler has accepted the schedule and is waiting for the one-time invocation.

6. Verify the invocation and automatic removal

After the planned time, open miruky-fsashpslzjzefiib, choose Send and receive messages, and poll for messages. The received body should match the configured target input exactly.

The received body exactly matches one-time-schedule-fired, which confirms the target invocation rather than only the schedule configuration.

Return to the Scheduler list and filter by the full generated schedule name. After the completed invocation is processed, the exact-name result should reach zero because DELETE applies after the schedule's last target invocation.

The queue message and the absent schedule prove different parts of the run. The message confirms the target call, while the zero-result filter confirms that the completed one-time schedule no longer consumes schedule quota.

Wrap-up

This one-time schedule used three controls together: a specific evaluation time zone, a templated SQS target, and DELETE after completion. Removing the schedule automatically did not remove the target queue or the execution role; it affected only the Scheduler resource.

For longer-lived workloads, add a deliberate retry and dead-letter-queue design, keep the execution role scoped to the target, and monitor failed invocations instead of treating schedule disappearance as the only success signal.

Thanks for reading this far.

See you in the next one.