2 Answers
- Newest
- Most votes
- Most comments
4
Hey,
As you've identified, PutLogEvent requires timestamp in Unix epoch and there is no intrinsic function in ASL to do this so you'll have to handle it outside ASL.
You can introduce an "Invoke Lambda" step before the "PutLogEvent" to get you the timestamp in the Unix epoch format.
- I was able to do this by creating this Python Lambda function:
import json
import datetime
def lambda_handler(event, context):
epoch_timestamp = iso_to_epoch(event['currentTime'])
return {
'statusCode': 200,
'epoch':epoch_timestamp
}
def iso_to_epoch(iso_time):
# Parse the ISO 8601 time string into a datetime object
dt = datetime.datetime.fromisoformat(iso_time)
# Convert the datetime object to an epoch timestamp
epoch = int(dt.timestamp())
return epoch
- And invoking it with this State Machine:
{
"StartAt": "Lambda Invoke",
"States": {
"Lambda Invoke": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"OutputPath": "$.Payload",
"Parameters": {
"Payload.$": "$",
"FunctionName": "arn:aws:lambda:ap-southeast-1:012345678901:function:iso-to-unix-converter:$LATEST"
},
"Next": "PutLogEvents"
},
"PutLogEvents": {
"Type": "Task",
"Parameters": {
"LogEvents": [
{
"Message": "MyData",
"Timestamp.$": "$.epoch"
}
],
"LogGroupName": "MyData",
"LogStreamName": "MyData"
},
"Resource": "arn:aws:states:::aws-sdk:cloudwatchlogs:putLogEvents",
"End": true
}
}
}
- executed with this input :
{
"currentTime": "2024-01-11T14:11:03+00:00"
}
I could see the PutLogEvent call being made.
Hope this helps.
0
I was able to use this JSONata as my PutlogEvents argument:
{ "LogEvents": [ { "Message": "MyData", "Timestamp": "{% $millis() %}" } ], "LogGroupName": "MyData", "LogStreamName": "MyData" }
answered 6 months ago
Relevant content
- asked 9 months ago
- AWS OFFICIALUpdated 2 years ago

Thanks for your comment, I can see that this would work but it seems like a gap in the step function capability set. I was hoping there was something that I was missing. If I have to setup a lambda just to get a timestamp then I may as well setup that same lambda to do the logging directly - while eliminating the gap in duration between lambda creating the timestamp and next step using it. Case in point, if viewing logs for the step function in timestamp order (cloudwatch default) , the 'logged message' will actually occur before the 'PutLogEvents' step starts. its a trivial difference but can be meaningful.