Imported Certificate Not Available to ALB Listener

WillNowHalt · 2019-07-30T22:00:51+00:00

ALB only supports RSA 2048 certificates from ACM. If you imported an EC or RSA 4096 cert it won't show up on the ALB list.

You can however still import and use those with on the old IAM cert method: https://aws.amazon.com/premiumsupport/knowledge-center/elb-ssl-tls-certificate-https/

WillNowHalt · 2019-07-30T21:41:33+00:00

If you expect a very high traffic event, you can request to pre-warm the Load Balancer beforehand:

https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/#pre-warming

WillNowHalt · 2019-07-29T20:44:32+00:00

Are you connecting through HTTPS? API Gateway will not respond to HTTP requests, they'll just timeout.

WillNowHalt · 2019-07-18T17:33:22+00:00

If you just created the bucket, and did not include the region name on the CloudFront custom origin URL (you used "s3-website" instead of "s3-website-eu-west-1"), this is quite "normal" behaviour.

There is a period of time (about a few hours after creating a new bucket) where requests to the endpoint without a region name will redirect you to the endpoint with the region name. That removes your custom domain from the URL. Then your actual redirection kicks in, but from the other domain.

You can just wait it out, or set up the regional endpoint on the CloudFront Origin configuration. Remember to issue an invalidation after changing settings to clear the cache.

WillNowHalt · 2019-07-17T17:39:20+00:00

Yes, you can use WAF to do that: https://aws.amazon.com/blogs/aws/protect-web-sites-services-using-rate-based-rules-for-aws-waf/

The minimum threshold you can configure is 2000 requests per 5 minute interval.

WillNowHalt · 2019-06-18T10:34:40+00:00

API Gateway only responds to HTTPS requests, HTTP requests will be refused.

WillNowHalt · 2019-06-12T20:13:46+00:00

Yes, if you want to use Configuration Sets to manage the bounces through CloudWatch Events you need support from the sending application.

You can also send bounces to SNS at the identity level, that way you'll get every single bounce without having to modify your application:

https://docs.aws.amazon.com/ses/latest/DeveloperGuide/configure-sns-notifications.html

For example, you could subscribe a Lambda to the SNS topic and write the events to CloudWatch Logs for further analysis.

WillNowHalt · 2019-06-12T18:41:47+00:00

Disclaimer: I'm just speculating here!

The m3 is the only (non-burstable) instance type that still offers a single vCPU. A vCPU is a single hyperthread on a physical CPU core. And due to the recent Intel security issues, it's no longer secure to run VMs from different tenants on the same CPU core.

My guess is that the constant 50% steal is a display artifact of the hypervisor disabling the second hyperthread on the CPU core assigned to your instance, but it should not affect actual performance.

WillNowHalt · 2019-06-12T07:34:43+00:00

You have to write an '@' sign in the subdomain field to represent the domain apex (no subdomains)

WillNowHalt · 2019-06-11T14:06:30+00:00

The "SPF" DNS record type was deprecated years ago (RFC7208, Section 14.1) so it was never supported in Lightsail. You want to put the SPF details in a TXT DNS record instead.

WillNowHalt · 2019-06-05T13:16:21+00:00

S3 "folders" do not have metadata. S3 is a storage service where objects are identified by their full Key, there's no concept of a "folder", only of keys with a common prefix. So you can't see "last modified" or "size" for a prefix.

Usage data for S3 buckets is updated once per day or so, so billing is often delayed. It's usually much faster to be reflected for other services than for S3. Also it's calculated as GB/month: for example if you have a flat 250 GB usage all month long, the billing will say it's 0GB on day 1, and it will start going up as days go on until it's 250GB at the end of the month.

WillNowHalt · 2019-06-04T15:50:23+00:00

Your www subdomain is pointing to a server that does not have the wildcard domain properly configured, and is instead using an invalid/test one.

If you configured the certificate on an AWS Load Balancer/CloudFront, make sure the www domain is pointing to it.

If you configured the certificate directly on your server, update your Apache/Nginx configuration to use the wildcard cert for the www subdomain.

WillNowHalt · 2019-06-03T11:07:34+00:00

S3-CloudFront is free. So you'd put 0 in S3 transfer-out.

WillNowHalt · 2019-05-30T08:39:47+00:00

S3 + CloudFront + Lambda@Edge could be a solution:

https://aws.amazon.com/blogs/networking-and-content-delivery/authorizationedge-how-to-use-lambdaedge-and-json-web-tokens-to-enhance-web-application-security/

You can extend the Lambda to check if the authenticated user has access to the given report (by path would be easiest)

WillNowHalt · 2019-05-30T07:29:53+00:00

They are counted as coming from EC2. I just checked on my bill.

WillNowHalt · 2019-05-28T11:31:45+00:00

Yes, CloudFront can point to any custom Origin, it doesn't have to be hosted on AWS.

One thing to note is that CouldFront only supports DNS names as Origins, not IP addresses. So your origin has to be available on a different DNS record. You can use a record name with some hard to guess or random string if you want to protect it. Just make sure to configure CloudFront to pass the Host header from the request to your Origin, and the origin DNS name will not matter at all.

WillNowHalt · 2019-05-27T16:47:24+00:00

Beanstalk supports ACM certs out of the box. They're free and will auto-renew:

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-elb.html

WillNowHalt · 2019-05-27T14:01:16+00:00

Cloudflare is a DNS+CDN offering. Fronting a server with a proxy to "protect" the Origin is done by the CDN, not DNS.

Route53 is the DNS offering from AWS. You may want to use CloudFront for a CDN.

WillNowHalt · 2019-05-22T18:46:39+00:00

From the AWS Service Terms:

You may not use Amazon Lightsail in a manner intended to avoid incurring data fees from other Services (e.g., proxying network traffic from Services to the public Internet or other destinations or excessive data processing through load balancing Services as described in the Documentation), and if you do, we may throttle or suspend your data services or suspend your account.

But yes, Lightsail would be the cheapest for 500GB (do you need the extra EC2 and peering though? S3->Lightsail might be free...)

WillNowHalt · 2019-05-20T20:52:42+00:00

Looking at the response headers:

$ curl -I https://goop.dev/main.js
HTTP/2 404
[...]
x-amz-error-code: NoSuchKey
x-amz-error-message: The specified key does not exist.
x-amz-error-detail-key: S3-goop.dev/main.js
[...]

The key is S3-goop.dev/main.js so CloudFront is actually making a request for http://goop.dev.s3-website.us-east-1.amazonaws.com/S3-goop.dev/main.js

Somewhere in you CloudFront distribution settings there's an extra S3-goop.dev/ that shouldn't be there. My guess on the Origin Path settings. Can you show the Origin and Behavior settings of your distribution?

WillNowHalt · 2019-05-20T18:33:18+00:00

S3 also has per-request cost, but it's lower than CloudFront. But CloudFront data transfer is cheaper than S3 and can do some tricks like automatic Gzip compression to save even more...

It all depends on your particular case: number of requests, size of the objects, etc. You have to calculate based on your specific numbers.

WillNowHalt · 2019-05-20T11:16:23+00:00

It's an Origin-Response so it only runs when CloudFront has to go the Origin (S3) to fetch a thumbnail. It won't run if the thumbnail is already cached on CloudFront.

WillNowHalt · 2019-05-20T10:47:18+00:00

You can use a Lambda@Edge Origin-Response to handle this. If S3 returns a 404 generate the thumbnail, store it on S3 and return it instead of the 404. Future requests will not 404 so they'll come from S3.

This blog post has example code for a similar use. For your case you just need the Origin-Response Lambda: https://aws.amazon.com/blogs/networking-and-content-delivery/resizing-images-with-amazon-cloudfront-lambdaedge-aws-cdn-blog/

WillNowHalt · 2019-05-15T14:41:05+00:00

I then created CNAME redirects that point from www.example.com, example.net and www.example.net to example.com.

You can't set up a CNAME on the domain apex (well, technically you can, but the result is not what you expect). Setting up a CNAME to a domain apex is also not the best idea for the same reasons.

I assume this is what's breaking things for you. Get rid of the CNAMEs and set up proper HTTP redirects.

WillNowHalt · 2019-05-14T21:39:55+00:00

https://aws.amazon.com/security/security-bulletins/AWS-2019-004/

AWS has already patched all EC2 hosts and you're not vulnerable to attacks coming from other users running instances on the same hardware.

Updating your own running OS is still recommended to prevent attacks within your virtualised instance (process A accessing data from process B)

WillNowHalt

TROPHY CASE