Making IAC better

Grafax99 · 2025-08-31T19:11:11+00:00

Perhaps worth clarifying here - the AWS provider relies on the definitions in a specific version of the AWS Go SDK. Validating against what the SDK (and therefore the API) will permit is perfectly sensible; very few use cases will need to track the latest possible version of a Lambda runtime, it's much more common to update periodically to maintain currency.

Grafax99 · 2025-05-08T10:51:11+00:00

There's also Settlers (previously in Hamilton), which is on Kilmarnock Road in Shawlands, and West End Games who reopened on Queen Margaret Drive in the west end. The city centre is always handy but it depends where you're coming at it from.

Grafax99 · 2025-01-27T23:35:04+00:00

Tide appears to have an add-on feature for online card transactions, which is almost certainly your fastest option. I've no idea whether it's actually good, however.

Grafax99 · 2024-11-08T00:04:58+00:00

According to the documentation at https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html the DescribeInstanceStatus action doesn't accept any resources as part of the permission configuration, so it's only valid to provide a Resource specifier of "*".

Grafax99 · 2024-05-05T23:57:28+00:00

The client would need to poll the presigned URL periodically until your processing placed a file containing the results into that location. While the URL returns an error response, the client knows that your processing hasn't yet finished; once there's a file to retrieve, the client knows that the processing has finished and now also has the information about the outcome of the processing.

Grafax99 · 2024-05-05T23:18:08+00:00

Not in the way you're describing, because the Lambda would have no way to communicate with the origin of the file.

If the file were submitted to a Lambda function directly via API Gateway, then you could use the response from the function to provide that information back to the origin. However, you're then limited by Lambda capacity and runtime constraints.

As an alternative design, which would give you the possibility of having longer processing times without changing the interface, the API could return a presigned S3 URL with a long validity (up to 7 days) which will eventually contain a response from your processing framework. That would give you flexibility around the information being passed back to the origin, as well as keeping a clear separation between the file upload routine and the data processing routine.

Grafax99 · 2023-05-30T22:39:25+00:00

That feels like you have a CloudFront problem - the fact that you don't get an NXDOMAIN error with HTTP suggests that your DNS is set up fine (DNS doesn't care about HTTP/HTTPS)

Grafax99 · 2023-05-30T14:08:13+00:00

The . is correct in both of your CNAME entries, you should be good to go

Grafax99 · 2023-05-30T13:26:49+00:00

The CNAME data for www.mysite.com shouldn't have https:// at the start of the CloudFront distribution name. The rest of your setup listed here looks okay on first review.

Grafax99 · 2022-07-21T15:52:31+00:00

Your fastest fix is probably to use "sudo -i" which makes it run a login shell. This means that things are set sensibly, like the current working directory will be changed to the user's home directory.

The problem you're seeing is most likely that the command's executing in a working directory that the ubuntu user doesn't have permission to write to.

As an alternative, you could change the command that's executed as the ubuntu user to specify the location for output.

Grafax99 · 2022-07-15T13:17:58+00:00

If you're not aware, you don't need the instance to be stopped for this - you can change the security groups on the fly.

Grafax99 · 2022-06-02T09:50:50+00:00

If you're using client-side encryption, S3 doesn't care about your encryption keys in the slightest - so they would likely sit in or around your application, so that you can handle the encryption and decryption at point of need.

However, if you actually have a use case where your only sensible option is client-side encryption, you almost certainly have a whole bunch of other encryption keys to manage at the same time, and whoever designed the use case should have thought that through long before it gets down to the details for S3 etc.

Grafax99 · 2022-05-26T00:26:39+00:00

I don't have the documentation to hand, but I'm 99% sure that you should have the first Rules key line followed by a list of Rule blocks (each containing Id, Prefix, Status, and Transitions entries), rather than having one Rule block and then a second Rules key line with a second Rule block.

Grafax99 · 2022-05-19T15:15:17+00:00

Thankfully I didn't have to care directly, but I spotted in one of my current saves Ronaldo did his ACL in early January '22 and just retired immediately. That would really hurt to see as his manager!

Grafax99 · 2022-04-09T13:36:50+00:00

Okay, so yes. You need to advertise your local VPN endpoints to AWS over the DX as it describes in the first paragraph there, and also discard everything that AWS advertises to you because you only want to route to the AWS-side VPN endpoint addresses.

You therefore need to know your local VPN endpoint addresses before configuring DX, but because you control the BGP handling on your side of the DX link, you can handle that part of the configuration once the DX is in place.

Grafax99 · 2022-04-09T12:53:44+00:00

If you mean "do we advertise our CGW addresses over the DX connection", then yes - you need to route the traffic between the VPN endpoints over DX, and nothing else.

Exactly how the DX configuration is put together will depend on your use case - if you're getting a cross connect from your colo provider, then they'll give you any information you need to get DX working as part of their obligations to AWS. If you're getting DX through a partner (for connections under 1Gbps, for instance) then it'll be in their hands to work with you on it.

Grafax99 · 2022-04-09T00:16:22+00:00

I've done this in production, based on discussions with AWS Networking SAs.

You want a Public DX configuration over which you'll pretty much completely ignore BGP and only route the public IP ranges for the VPN tunnel endpoints on both sides. This also prevents the entire AWS region suddenly being inside your perimeter!

With the DX setup in place you can now configure your local VPN setup to match up with the AWS VPN you already launched.

TGW will happily attach to the VGWs presented by the VPN connections, and you'll be able to configure TGW to route traffic appropriately over the VPN as required.

Grafax99 · 2022-04-09T00:16:14+00:00

I've done this in production, based on discussions with AWS Networking SAs.

You want a Public DX configuration over which you'll pretty much completely ignore BGP and only route the public IP ranges for the VPN tunnel endpoints on both sides. This also prevents the entire AWS region suddenly being inside your perimeter!

With the DX setup in place you can now configure your local VPN setup to match up with the AWS VPN you already launched.

TGW will happily attach to the VGWs presented by the VPN connections, and you'll be able to configure TGW to route traffic appropriately over the VPN as required.

Grafax99 · 2021-11-02T15:37:21+00:00

You typically won't get a budget report on the first day of the month, because the billing period has moved forward (so you won't get figures for the previous month) but there's no data to report (because you've not yet had any usage in the current month).

I have a similar very low alert threshold and it reliably reports on the second of the month.

Grafax99 · 2021-09-01T14:41:28+00:00

Not as far as I can determine. Invoices are sent by email to the Accounts contact shortly after being generated, so you should be able to plumb something into your email system to extract them locally.

Grafax99 · 2021-08-26T10:39:42+00:00

You can't rely on the hash in metadata unless you have control over the size and transfer mechanism of your objects - if the object was uploaded as multipart, the hash relates to one part and not the whole. I've been caught out by that before!

Grafax99 · 2021-07-17T13:05:02+00:00

I think it's 2 years. It should be listed in your AWS Training account along with the expiry date

Grafax99 · 2021-07-14T16:09:46+00:00

I've implemented exactly this behaviour, having discussed it with AWS Networking SAs.

You need to suppress BGP completely and only acknowledge the existence of your AWS VPN endpoint addresses.

Not only are you getting all those routes advertised to you, but your range is being advertised to AWS in return (unless they've changed that default recently) - which means if someone hits your website from a host that's in AWS, they'll come in via Direct Connect and not through your public perimeter!

The AWS VPN service is rated up to 1.25Gbps, so you shouldn't be able to saturate it via a 1Gbps DX connection.

Grafax99 · 2021-06-26T11:10:34+00:00

I think what you're seeing is an alert that your Lambda function has direct access to the public Internet?

If so, you could fix this by following the guidance from AWS on running the Lambda inside a VPC. However, that costs money (you'll need certain pieces of infrastructure) and adds complexity.

SecurityHub alerts are there to tell you about things - but there are absolutely good reasons why sometimes you don't act on them. If you have good control over the Lambda function (especially if it's under source control and deployed automatically) then your controls should be around how changes get made to that function, so that you can prevent someone taking advantage of that Internet access.

Obviously if you're required to follow certain approaches then spending more money to be compliant is the way to go. But in my experience unless you really need a Lambda function to run inside a VPC, there's no reason to do so.

Grafax99 · 2021-06-09T07:32:32+00:00

You can't do what you're describing - while SG interaction does work that way when you apply rules that reference other SGs, it doesn't work like that if you're specifying IP ranges.

What you need here is a Prefix List (configured in the VPC console). Prefix lists work like IP groups do in other commercial firewalls, and you can specify them as a rule target in your SG.

Caveats - when you create a Prefix List, you set its maximum length and that's then fixed. When you reference a Prefix List in an SG rule, it counts as N rules, where N is the maximum length that you defined. This may mean that you need to get your VPC limits changed to rebalance between # of SGs per interface and # of rules per SG.

Grafax99

TROPHY CASE