[anisaoshafi]

Motivation

aws --profile localstack used directly (not through lstk's own proxies) sent S3 requests to the profile's general endpoint, breaking S3's virtual-host-style bucket addressing.

Solution

lstk setup aws now writes an S3 endpoint override in a [services localstack] block, referenced via services = localstack in the profile. It reuses the existing endpoint.S3Addressing helper already used by the Terraform/CDK proxies. This block follows the same idempotency and --force overwrite rules as the rest of the profile.

Review

Small, self-contained, covered by unit and integration tests. Self-merge candidate.

Closes DEVX-755

[joe4dev]

Good to see S3 compatibility addressed in the AWS profile. That's particularly important to cdk. I really like the non-destructive edit in ~/.aws/profile 👏 ✨

A couple of non-blocking questions/suggestions:

❓ Do we want to offer a fallback for customers being blocked by DNS rebind protection, similar to the probing we do in the LocalStack Toolkit https://github.com/localstack/localstack-toolkit-vscode/pull/51?

This block follows the same idempotency and --force overwrite rules as the rest of the profile.

❓ What is the intended behavior of --force?
Given an existing ~/.aws/profile, both non-force and --force performed a non-destructive edit. Does --force simply skip the interactive "[Y/n]" prompt?

nit: The confirmation message "✔︎ Created LocalStack profile in ~/.aws/config" does not distinguish between Create and Update.

Sidenotes

Not directly related, just FYI:

• The lstk aws proxy command does not respect the --profile localstack. Is this intentional or is there a workaround?
• The AWS VSCode Extension cannot parse the service-specific section and spams verbose logs (their bug):
  

[anisaoshafi]

Thanks for your feedback @joe4dev!

Do we want to offer a fallback for customers being blocked by DNS rebind protection, similar to the probing we do in the LocalStack Toolkit localstack/localstack-toolkit-vscode#51?

We already have this, and the PR keeps it working. lstk setup aws calls endpoint.ResolveHost, which looks up test.localhost.localstack.cloud. If that fails or doesn't return 127.0.0.1, it uses 127.0.0.1: and prints a note.

What is the intended behavior of --force?

In the interactive flow, --force just skips the [Y/n] prompt. In non-interactive mode (CI for example), lstk won't change an existing localstack profile that has different values unless you pass --force

nit: The confirmation message "✔︎ Created LocalStack profile in ~/.aws/config" does not distinguish between Create and Update.

This wording has been like this since the profile setup flow was added, and it applies to every profile write. I left it as is to keep this PR focused, I image the reason why it didn't distinguish originally was to not complicate logic. Happy to change in a follow up if you think it's important.

The lstk aws proxy command does not respect the --profile localstack. Is this intentional or is there a workaround?

lstk aws uses the localstack profile when it exists. But it doesn't use the profile's endpoints, because lstk adds its own --endpoint-url with the emulator address it found, and the aws cli gives that flag priority over the profile.

If you want the profile's endpoints, either pass your own --endpoint-url after the command, for example lstk aws s3 ls --endpoint-url http://.... or run aws --profile localstack ... directly, without lstk.❓ Did you run into a problem because of this?

[joe4dev]

lstk aws uses the localstack profile when it exists. But it doesn't use the profile's endpoints, because lstk adds its own --endpoint-url with the emulator address it found

I found that counter-intuitive if I want to test certain networking scenarios through my global AWS profile.

Did you run into a problem because of this?

I often have to use the AWS CLI directly because lstk does not let me connect to a running dev / host mode instance. I would expect lstk aws to succeed if finds the health endpoint of a LocalStack instance running at the endpoint configured in the profile rather than over-relying on the lstk -managed Docker instance.

[joe4dev]

Did you run into a problem because of this?

The main blocker is the LocalStack Toolkit for VS Code in dev mode: I cannot open App Inspector during development because it depends on lstk detecting a running instance. This works with other tools such as the LS Console (i.e., Web App).

Do we have an issue for this?

[anisaoshafi]

Did you run into a problem because of this?

The main blocker is the LocalStack Toolkit for VS Code in dev mode: I cannot open App Inspector during development because it depends on lstk detecting a running instance. This works with other tools such as the LS Console (i.e., Web App).

Do we have an issue for this?

I created this issue https://linear.app/localstack/issue/DEVX-1223 and will take a look one of these days. Thanks for raising this issue.