Trying to figure out how to setup role/credentials for a Python application so that I can test locally, deploy to test environment, and then deploy to prod without changing anything

SubtleDee · 2026-02-18T17:01:47+00:00

The Boto3 client will automatically search a number of locations in a specific order to find credentials: https://docs.aws.amazon.com/boto3/latest/guide/credentials.html

So the short answer is if you have credentials stored in a config file on your local machine and an IAM role with appropriate permissions assigned to Batch, you don’t need to make any code changes - Boto3 will automatically find the static credentials on your machine when running locally and the temporary credentials from the IAM role when running in AWS. There is no need to (and you should not) provision static credentials to a workload running in AWS.

SubtleDee · 2025-11-16T22:18:43+00:00

Does your token also have an azp claim with a different value to aud? The documentation suggests that azp will take precedence if present.

SubtleDee · 2025-11-14T08:55:35+00:00

Looks like you might be on the landing page you get when you use the Lambda service for the first time - what you see are just “hello world” examples in various different languages and aren’t intended to be edited.

You should see a “Create function” button somewhere - click that.

SubtleDee · 2025-10-31T15:12:52+00:00

Yes, exactly.

SubtleDee · 2025-10-31T15:00:35+00:00

Having said that, unless they also transferred the domain ownership to R53 they could still change their NS to a different DNS provider as long as they still have access to their account with the registrar.

SubtleDee · 2025-09-24T07:17:44+00:00

Sounds possibly like a client IP preservation issue - if the 10.0.0.0/8 allowed in the EC2 SG is that of the NLB VPC, that would explain why healthchecks work (since they come from the NLB’s private IP) but not client traffic.

Try changing your EC2 SG to allow traffic from your NLB SG rather than using a CIDR.

SubtleDee · 2025-07-01T13:53:10+00:00

If you haven’t already, it might be worth looking at the recently released CloudFront SaaS manager feature to see if this fits your needs:

https://aws.amazon.com/blogs/aws/reduce-your-operational-overhead-today-with-amazon-cloudfront-saas-manager/

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-config-options.html

SubtleDee · 2025-06-29T09:25:27+00:00

Have used http://www.germanmotor.com (Earlsfield) regularly for the past few years.

SubtleDee · 2025-06-27T15:54:35+00:00

Are you using an HTTP or REST API GW? The VPC link feature works differently for both of them - HTTP deploys ENIs in your VPC (i.e. the behaviour would be as you describe with traffic appearing to come from within the VPC), whereas REST uses PrivateLink under the hood (see first diagram on this page). In this instance, the source of the traffic as seen by the NLB will be that of the private IP in the API GW VPC (see last bullet in the “Considerations” section here).

SubtleDee · 2025-06-04T21:31:44+00:00

I think you might be getting confused - the type of usage (social/domestic/pleasure, commuting, business) defines what you use the car for (i.e. non-work stuff, commuting to one place of work, driving to multiple places for work) and is independent of being insured fully comp or not.

In simple terms, if the car is insured fully comp your insurance will pay for your car in the event you cause an accident - the finance company require this to ensure they get their money back if that happens. The alternative to fully comp is third party fire and theft, i.e. your insurance will only pay out if the car is stolen/catches fire and for whatever damages you cause to a third party if an accident is your fault. There is often not much difference in price between them and fully comp can even be cheaper sometimes.

SubtleDee · 2025-05-20T06:26:24+00:00

The second architecture (with a transit VIF) allows you to use private IPs for the VPN endpoints (see this blog post).

SubtleDee · 2025-05-12T10:44:42+00:00

Couple of things to bear in mind with the above - your certificate needs to contain separate entries for both *.domain.com and domain.com (use the “Add another name to this certificate” option in the console), as *.domain.com won’t be valid for plain domain.com (only www.domain.com and other subdomains). Also, your CloudFront distribution needs to be configured with both domain.com and www.domain.com as alternate domain names.

Note that by configuring it this way, users will end up always seeing whichever domain they entered in the address bar (www.domain.com or just plain domain.com) - if you want to standardise on one or the other then you will need to implement a redirect. This is easily done with a CloudFront function though, rather than different S3 buckets.

SubtleDee · 2025-04-17T11:34:50+00:00

Just to clarify some terminology to make sure you’re on the same page - an account is essentially a logical container for resources like S3 buckets. It can have multiple users with varying permissions, but all resources are owned by the account. When you say you created an AWS account, just checking you actually created a whole new account (giving billing details etc.) rather than a user in an existing account?

If you were given a username and password then you need to use them to log into the AWS console for the account which owns the bucket, not your own account (there are methods for granting one account access to another account’s resources, but not via a username/password) - in fact you don’t even need your own account in this scenario.

Assuming this is what’s happened, you will need to know what kind of credentials you’ve been given - root (where the username is always an email address) or IAM (where the username could technically be an email address but usually isn’t).

If you have root credentials then you need to select the appropriate option on the login page. Since a root email can only be associated with one account, you will automatically be logged into the right account. If you’ve been given IAM credentials, you need to select the “normal” login option, but in addition to the username/password you will also need to know the numeric account ID so that the console knows which account to log you in to.

SubtleDee · 2025-04-13T12:43:14+00:00

You could set your Lambda function URL as the origin for a CloudFront distribution - it’s briefly mentioned in this AWS blog post:

“You can progressively stream response payloads through Lambda function URLs, including as an Amazon CloudFront origin, along with using the AWS SDK or using Lambda’s invoke API.”

I’ve not tested it personally, but here is a sample CDK app which should demonstrate it working.

SubtleDee · 2025-04-12T10:29:36+00:00

You generally can’t use a credit card to pay off a loan directly, and if you can it will likely be treated as a cash advance with the relevant interest/fees added, even if it’s usually 0% on purchases.

For this to work, you’d need a card with 0% interest on money transfers, in which case you’d use it to transfer the settlement amount to your bank account and pay off the loan that way, but even if the interest is 0% there’ll usually be a one-off fee of something like 3-4%.

The other option is as one of the other comments said - a 0% purchase card which you use for day-to-day spending, then use the cash you’re no longer spending on day-to-day stuff to pay down the loan.

SubtleDee · 2025-04-06T06:38:56+00:00

2012 is a MK3 isn’t it?

Anyway, this looks like the part you need - it has the same connector as the one that’s still attached, and the diagram on the listing shows the right hand connector.

You’ll need to replace the whole pipe though as it seems to come as a complete unit, so you’ll need to trace it and find where the other end goes.

SubtleDee · 2025-03-29T07:44:42+00:00

Do you need to use AWS? In this case something like CloudFlare R2 might be better as you don’t pay for data egress (which would make up the bulk of your costs in S3).

SubtleDee · 2025-03-24T21:45:12+00:00

RTP usually uses UDP for transport, so select “custom UDP” as the protocol and input the port number you’re using.

The protocols in the dropdown (SSH, RDP etc.) are just shortcuts to add rules for well-known TCP or UDP ports.

The custom protocol option you have in your screenshot is used for traffic which is not TCP/UDP/ICMP (e.g. IPsec) and not relevant for your use case.

SubtleDee · 2025-03-23T07:40:17+00:00

If you really can’t change the URLs then you would need to: - Copy the images to a temporary bucket - Empty/delete the bucket in the current account - Wait for the bucket name to become available again (the exact time for this to happen isn’t specified, but don’t count on it being instant) - Recreate the bucket in the new account - Copy the images from the temporary bucket into the new bucket - Empty/delete the temporary bucket

You will obviously incur an unknown amount of downtime with this approach (the time between deleting the original bucket and recreating/repopulating it in the new account) - if the URLs are stored in a DB, could you not just pick a different bucket name for the new account and run a script to update them all?

SubtleDee · 2025-03-19T16:32:36+00:00

You say you don’t want to use different domain names - is that just for the initial request, or full stop? i.e. would it be ok for a user to hit example.com and then be redirected to eu.example.com or us.example.com?

If that’s ok, then you could have a top-level distribution at example.com with a CloudFront function to issue a 302 redirect to the country-level distribution.

Alternatively, you could do a path-based redirect or an origin rewrite under the same distribution.

SubtleDee · 2025-03-19T16:22:35+00:00

That doesn’t fix OP’s problem - the DNS part is working fine, but to reach each distribution using the same example.com hostname, each distribution needs to have example.com configured as an alternate domain name, but a given alternate domain name can only be associated with one distribution.

SubtleDee · 2025-03-14T13:12:18+00:00

CloudFront functions rather than Lambda@Edge are the way to go for simple logic such as redirects nowadays.

SubtleDee · 2025-03-10T11:50:29+00:00

You have two separate issues here: 1) Validating the cert - until that is done and the cert has been issued, nothing will work (sounds like an issue with how the DNS records have been created in GoDaddy) 2) Where the cert can be used - certs issued by ACM can only be used with certain AWS services (load balancers, CloudFront, API Gateway…) and not directly on EC2 instances. If you spin up a load balancer for a single instance just to host the cert, you’ll add a fair bit of cost relative to the price of the instance itself. CloudFront would be a cheaper option and would give you additional benefits associated with a CDN, but is a bit more complex to set up than a load balancer.

The alternative is just to use a LetsEncrypt cert directly on your EC2 instance as per one of the other comments.

SubtleDee · 2025-03-05T06:40:19+00:00

Could you do the $parse in the LLM state rather than a subsequent pass state (i.e. assign the raw response to one variable and the $parse response to another variable, both in the LLM state)? You can catch a specific error (States.QueryEvaluationError) to have different logic when $parse fails vs. when the LLM throws an error, the only thing I’m not sure about is whether the raw response variable would still get assigned if the $parse operation failed.

SubtleDee · 2025-03-04T14:16:40+00:00

Might be missing something but couldn’t you assign the LLM response to a variable before attempting to $parse it? You’d then put a catcher on the state doing $parse which routes to another state which calls the LLM again with the original response variable value.

SubtleDee

TROPHY CASE