TL;DR

$LASTEXITCODE is not the success status of the last PowerShell cmdlet. Use it for a native executable such as aws.exe, and capture it immediately:

aws --version
$Code = $LASTEXITCODE
if ($Code -ne 0) { throw "AWS CLI exited with code $Code" }

For a cmdlet, use PowerShell error handling:

Get-Item -LiteralPath 'C:\Data\settings.json' -ErrorAction Stop

-ErrorAction Stop turns a cmdlet’s non-terminating error into a terminating one, which stops the script or reaches an enclosing catch.

While working on a backup script for my 7 Days to Die game server, I thought it would be good to share this.

You replace an AWS CLI command with a PowerShell cmdlet and keep the success check. The cmdlet prints an error. The script announces success anyway.

The check still runs. It’s reading the result of a different operation.

Reproduce a failed command with exit code zero

Run this in PowerShell on Windows:

cmd.exe /d /c exit 0
Write-Error 'Demonstration: the upload failed' -ErrorAction Continue
"Native exit code: $LASTEXITCODE"

The error appears, followed by:

Native exit code: 0

The zero came from cmd.exe. Write-Error did not update it. The explicit Continue makes this demonstration non-terminating even if your session normally uses a stricter error preference.

The reverse is just as misleading:

cmd.exe /d /c exit 7
Get-Date | Out-Null
"Native exit code: $LASTEXITCODE"

This prints 7 even though Get-Date succeeded. These examples illustrate why a value left in the variable is not evidence about a later cmdlet.

Microsoft defines the variable for native programs and PowerShell scripts; script behavior also depends on invocation and the exit keyword. Ordinary cmdlet success or failure does not make it a universal status register. See about_Automatic_Variables (opens in a new tab).

For native commands, check each result at the boundary

This example assumes AWS CLI is installed, the source exists, and the active AWS identity can access your chosen bucket:

$Source = 'C:\Data\exports'
$Destination = 's3://YOUR-BUCKET/exports/'

$null = Get-Command aws -CommandType Application -ErrorAction Stop
aws s3 sync $Source $Destination
$Code = $LASTEXITCODE

if ($Code -ne 0) {
    throw "S3 sync did not complete cleanly; AWS CLI exit code $Code"
}

'Export transfer completed'

Replace YOUR-BUCKET before running it. AWS documents nonzero outcomes including failed S3 transfers and skipped files. A skipped file is enough to reject a backup run as incomplete; inspect the command output for the cause. See the AWS CLI return-code reference (opens in a new tab).

Capture and handle each result before moving on.

Also distinguish a process failure from a launch failure. If aws is not found, no AWS CLI process returned an exit code, and the check reads whatever an earlier native command left. The Get-Command line stops the script before that can happen.

Why try/catch sometimes misses a cmdlet error

PowerShell can report an error while continuing execution. For example:

try {
    Write-Error 'Demonstration failure' -ErrorAction Continue
    'Still inside try'
}
catch {
    'Caught the error'
}

The error is displayed and Still inside try prints. The catch block isn’t entered. Change that one invocation to -ErrorAction Stop and the catch block runs instead.

Some errors already terminate execution; they don’t need this promotion. -ErrorAction Stop makes the intended behavior explicit for cmdlet errors that would otherwise continue. Microsoft’s try/catch documentation (opens in a new tab) explains which errors those blocks handle.

Catch a Write-S3Object failure with -ErrorAction Stop

With AWS.Tools.S3 installed and AWS access configured, use this for an intentional upload of one existing file:

Import-Module AWS.Tools.S3 -ErrorAction Stop

try {
    Write-S3Object -BucketName 'YOUR-BUCKET' `
        -File 'C:\Data\exports\report.json' `
        -Key 'exports/report.json' `
        -ErrorAction Stop

    'Upload completed'
}
catch {
    Write-Warning ("Upload failed: {0}" -f $_.Exception.Message)
    throw
}

The success message is reachable only after the upload returns normally. The bare throw propagates the caught error to the caller. Logging and then continuing would hide the failure from whatever invoked the script.

If you have no context to add and no recovery to attempt, remove the try/catch and keep -ErrorAction Stop. A catch block that only rethrows isn’t required.

$PSNativeCommandUseErrorActionPreference in PowerShell 7

PowerShell 7.4 added $PSNativeCommandUseErrorActionPreference. When it’s $true, nonzero native exit codes produce PowerShell errors governed by $ErrorActionPreference; with Stop, those can reach catch. The default is $false. Microsoft documents it in about_Preference_Variables (opens in a new tab).

That doesn’t make -ErrorAction Stop a parameter for aws.exe. Passed to a native program, it’s an argument for that program to interpret. Explicit exit-code checks remain useful for scripts spanning Windows PowerShell 5.1 and PowerShell 7, and for tools whose nonzero codes have special meanings.

If native error promotion is enabled with Stop, execution can leave the native invocation before the following explicit check. Either path must preserve the failure; don’t catch it and then print success.

Common failures

LASTEXITCODE is empty or stale. There may be no relevant native result in the session. Choose the error mechanism for the operation you actually ran.

Can I replace it with $? everywhere? $? describes the last command’s execution status and is overwritten by the next command. It isn’t a durable record of a multi-step job. Structured error handling is clearer for cmdlets.

The task still reports success. Check whether a wrapper catches and suppresses the error, then exits normally. At the outer script boundary, preserve a failure through an unhandled terminating error or an intentional nonzero exit code.

A script needs to remember whether the work succeeded. That starts by listening to the failure signal the command actually provides.

TL;DR

A batch label does not create a function body that cmd.exe skips. Execution runs straight through the label unless you redirect it.

Put the main work first, end it with exit /b, and place subroutines below it:

@echo off
setlocal EnableExtensions
call :timestamp
echo [%stamp%] Work starts here
exit /b 0

:timestamp
set "stamp=%DATE% %TIME%"
goto :eof

call :timestamp creates a return point. goto :eof returns from that call. Reached in the main batch context, it ends the batch instead.

You add a timestamp helper to a working batch file. The helper looks reasonable. The next run prints almost nothing, and the real work never starts.

It’s tempting to debug the timestamp expression. First check whether the script ever reaches the line that calls it.

Minimal reproduction: the call never happens

Save this as fall-through.cmd:

@echo off
echo Starting script

:timestamp
echo Inside timestamp
set "stamp=%DATE% %TIME%"
goto :eof

call :timestamp
echo [%stamp%] Doing the work

Run it from an existing Command Prompt so the output stays visible:

C:\scripts> cmd /d /e:on /c fall-through.cmd
Starting script
Inside timestamp

C:\scripts>

That output is the clue: the helper ran even though the call below it was never reached. Execution arrived there by reading downward.

A label marks a location. It doesn’t surround or hide the commands beneath it. The goto :eof then ends the current batch context, so both remaining lines are unreachable on this path. Microsoft’s goto reference (opens in a new tab) documents the special end-of-file target; you don’t need to define an :eof label.

End the main path with exit /b before the subroutines

Here is the complete repaired example:

@echo off
setlocal EnableExtensions

echo Starting script
call :timestamp
echo [%stamp%] Doing the work
exit /b 0

:timestamp
echo Inside timestamp
set "stamp=%DATE% %TIME%"
goto :eof

Expected output, with the timestamp varying by locale and clock:

Starting script
Inside timestamp
[<local date> <local time>] Doing the work

The main path calls the helper, resumes after the call, does its work, and exits before reaching the helper a second time. The helper is now reachable only through an intentional call.

Moving a subroutine to the bottom without the main-path exit is incomplete. The call returns correctly, but after the main work finishes, execution falls into the helper again.

What call, goto and exit /b each do

call :label starts a new batch context within the same file. When that context ends, execution resumes at the statement after the call. goto label only jumps; it doesn’t arrange a return. See Microsoft’s call reference (opens in a new tab).

The /b matters. exit /b ends the current batch context instead of cmd.exe, as Microsoft’s exit reference (opens in a new tab) says. A call :label runs in its own context, so inside a subroutine exit /b returns to the caller, and at the top level it ends the file. Use an explicit code when the caller needs a result.

These label-call and :eof examples assume command extensions are enabled, as they normally are. The repaired file makes that requirement explicit with setlocal EnableExtensions.

Helpers can also go above main

There’s no rule that subroutines must live at the bottom. If you prefer helpers first, jump over them on entry:

@echo off
setlocal EnableExtensions
goto main

:timestamp
set "stamp=%DATE% %TIME%"
goto :eof

:main
call :timestamp
echo [%stamp%] Doing the work
exit /b 0

Placement is a readability choice. An unambiguous execution path is the fix.

Common failures

The window disappears immediately. Run the file from an existing Command Prompt. A window opened only to run a batch file can close when that file ends; the disappearance alone doesn’t tell you which command caused it.

The helper runs twice. Look for a missing exit /b or goto :eof between the end of the main work and the first helper label.

The main work never resumes. Check for goto timestamp where you intended call :timestamp, or plain exit inside the helper.

I only needed a timestamp in a log. A separate subroutine may be unnecessary:

echo [%DATE% %TIME%] Backup started>>"backup.log"

This is a display timestamp, not a locale-independent filename format. Keep this simple example outside a parenthesized block, where percent-variable expansion introduces a separate timing issue.

When a batch file stops early, follow the lines it actually executes. A label that looks like a function declaration is still on that path.

TL;DR

aws s3 sync compares a source and destination before selecting transfers. Write-S3Object -Folder -Recurse uploads every file in the folder hierarchy on every run; recursion adds subfolders, not a destination comparison or deletion pass.

Keep sync when your script depends on skipping files that already match. Use Write-S3Object when uploading every selected file is the intended operation. Changing tools also means changing error handling: native exit codes for the CLI, PowerShell errors for the cmdlet.

The refactor looks harmless. Replace one external command with a PowerShell cmdlet, run it, and confirm that the files appear in S3.

The first run proves little. The second run is where the behaviors separate.

Two commands that can produce the same first upload

The following are alternatives, run from PowerShell. They assume an existing source folder, a bucket you control, and configured AWS access. Replace the bucket placeholder. The first needs AWS CLI; the second needs AWS.Tools.S3.

$Source = 'C:\Data\exports'
$Bucket = 'YOUR-BUCKET'

$null = Get-Command aws -CommandType Application -ErrorAction Stop
aws s3 sync $Source "s3://$Bucket/exports/"
$Code = $LASTEXITCODE
if ($Code -ne 0) { throw "S3 sync exited with code $Code" }

$Source = 'C:\Data\exports'
$Bucket = 'YOUR-BUCKET'

Import-Module AWS.Tools.S3 -ErrorAction Stop
Write-S3Object -BucketName $Bucket -Folder $Source `
    -KeyPrefix 'exports/' -Recurse -ErrorAction Stop

For a source containing report.json and daily\summary.csv, the intended keys are exports/report.json and exports/daily/summary.csv. Keep the prefix fixed when comparing repeated runs; a new prefix gives either command an empty destination namespace.

AWS describes the cmdlet as an uploader for files, content, or folder trees. -Recurse includes subfolders. It doesn’t implement the CLI’s sync algorithm. See the Write-S3Object reference (opens in a new tab).

What each command does on a repeat run

For local-to-S3 sync, the default upload criteria are a missing destination object, a different size, or a local modification time newer than the S3 object’s last-modified time. That time is when the object was uploaded. It isn’t a byte-for-byte scan of every file. A same-size file restored or copied with its original, older timestamp is skipped, and S3 keeps the stale bytes. --size-only discards the time criterion; --exact-timestamps applies to S3-to-local sync. These rules and directions are documented in the AWS CLI sync reference (opens in a new tab).

This is the migration question: did your script promise to upload a collection of files, or did it promise to transfer only what its comparison considers changed? Similar-looking final keys don’t answer that question.

Deletions are a separate decision

Deleting a local file doesn’t remove its S3 object in either example above. For the CLI, --delete explicitly adds destination cleanup. Preview that choice before applying it:

aws s3 sync 'C:\Data\exports' 's3://YOUR-BUCKET/exports/' --delete --dryrun
$Code = $LASTEXITCODE
if ($Code -ne 0) { throw "Sync preview exited with code $Code" }

The preview reports proposed operations; it isn’t proof that subsequent writes or deletions will be authorized or succeed. Review the exact bucket and prefix before removing --dryrun.

For backups, destination-only files create another issue: restoring all current objects can resurrect files that were intentionally removed locally. Decide whether you need a current mirror or recoverable snapshots before choosing how to handle that case.

Repeated uploads in a versioned bucket

In a bucket with versioning enabled, another successful overwrite creates another object version. Each stored version is a complete object, not only the changed bytes. AWS explains this in its S3 Versioning guide (opens in a new tab).

Consequently, repeatedly uploading an unchanged tree can create redundant versions as well as extra transfer work and requests. How much that matters depends on your data and schedule. A small configuration directory and a large export tree need different tradeoffs.

Conversely, a fresh timestamped prefix intentionally stores a new set of keys. There’s no previous tree there for sync to reuse. For that design, uploading every file may be exactly what you want.

Neither approach makes a live folder an atomic snapshot. If several related files change during the transfer, the destination can contain a mixture of moments. Use an application-consistent export or stable staging directory when a restore requires the files to agree with each other.

Preserve the failure contract when changing tools

The CLI example checks its result immediately. A final check after several native commands can miss an earlier failure. AWS’s return-code documentation (opens in a new tab) includes failed and skipped S3 transfers among nonzero outcomes.

For the cmdlet, add context and propagate the error if needed:

try {
    Write-S3Object -BucketName $Bucket -Folder $Source `
        -KeyPrefix 'exports/' -Recurse -ErrorAction Stop
}
catch {
    Write-Warning ("Export upload failed: {0}" -f $_.Exception.Message)
    throw
}

Don’t leave an old $LASTEXITCODE check after the cmdlet. The separate PowerShell error-handling article shows why that can report success for a failed upload.

Check a migration before trusting the replacement

Use a disposable source folder and dedicated destination prefix:

1. Upload two files and record their destination keys.
2. Repeat without editing either file; inspect actual uploads or object versions.
3. Change one file’s size and repeat; check which objects are written.
4. Remove one local file; inspect the destination-only object.
5. Use a missing source path and verify the overall script fails.
6. Use a -SearchPattern that matches nothing and confirm the script notices. Write-S3Object uploads nothing and reports no error.

Those checks exercise the behavior a syntax translation can overlook. They also make your deletion and repeat-run expectations explicit.

When each is the wrong choice

aws s3 sync is the wrong choice when:

• A file can come back with its size and an older timestamp, as a restore or a copy that keeps times does. The comparison skips it, and the destination keeps the old bytes.
• You add --delete on a prefix that other jobs also write to. The reconciliation removes their objects because they are absent from your source.
• Every run writes to a fresh prefix, such as a dated snapshot. There’s nothing there to compare against, so the comparison buys nothing and the script still depends on the AWS CLI.

Write-S3Object -Folder -Recurse is the wrong choice when:

• The script relies on skipping files that haven’t changed. Every run uploads the whole tree again, and in a versioned bucket each upload is another complete version.
• The destination has to mirror the source, deletions included. The cmdlet never removes destination-only objects, and adding that means owning comparison rules, key mapping, filters, deletions and partial failures yourself.
• You need to see what a run will do before it runs. There’s no equivalent of --dryrun.

Choose based on the repeat run and the restore you need.