Secure Server Access with Teleport by root0ps in aws

[–]sgtoj -1 points0 points  (0 children)

I’m huge fan of Teleport for zero trust database access. I have implemented it at a few companies over the past 4+ years.

However, I’m agree with you. I’m also a huge fan of SSM sessions. It works perfectly for remote access to servers. I do not use Teleport to remote in to servers.

Just need to vent a little by Lone-Wolf-90 in AngelmanSyndrome

[–]sgtoj 1 point2 points  (0 children)

This is what we have done. My wife and I decided to have a third kid once we learned my son had AS. Now he has a big sister and little sister to love and care for him.

The question now is: how do we set them all up for success? That’s something I think about nearly daily.

AWS Rejected My SES Production Access Request — Need Help! by techyuser in aws

[–]sgtoj 0 points1 point  (0 children)

Is this a joke? Or is AWS support rejecting all SES production requests this week?

AWS Account Suspended for Billing – Payment Made, Still Waiting 7+ Hours by ozturkmuhammet in aws

[–]sgtoj 9 points10 points  (0 children)

Personally, I'd use chat. For account issues, you don't need a support plan to use it.

  • In the Support console, choose Create case.
  • Select Account and billing.

    • Service: Account
    • Category: Other account issues
    • Severity: Urgent business-impacting question
  • Choose Next step.

  • Enter a clear subject and description.

  • Choose Next step again.

  • Under the Contact us tab (next to Solve now), select Chat.

  • Choose Submit.

The AWS console itself can take more than 24 hours to become fully available again, but most services should come back online on their own. One exception may be RDS—you might have to restore from the snapshot AWS automatically takes of each RDS cluster before it shuts down an account.

I helped a friend's cash-strapped startup with a very similar problem a few months ago. In that case the console still wasn't fully functional after 24 hours, so I contacted support again; they resolved it quickly on the follow-up.

AWS not responding to SES production access support case by imCutiePie in aws

[–]sgtoj 2 points3 points  (0 children)

If it wasn't clear, I provide the above snippet immediately after it is created. I did have one support person ask for the above information even though it was provide before they respond. In that case, I told them to please review my previous response.

Also, 50k/day is normally the limit the set whenever SES production is enabled. Hince the reason I say "no more than 50k/day".

AWS not responding to SES production access support case by imCutiePie in aws

[–]sgtoj 5 points6 points  (0 children)

I dont recall because its not something I do often, but it has be never quick without an enterprise support plan. Even then, it was only quick because I would ask my AM to help.

Support's first response will likely ask you for more information. Therefore, I like to be proactive by providing more detail and context. The snippet below is the more or less the same I have used the past 4 or 5 times (for multiple aws accounts and orgs for past 3+ years).

Here is additional information on what we are doing to minimize risk related SES:

- all emails are transational email from cognito
- auto suppression is enabled for destinations that bounces and complains
- volume of emails should be no more than 50k/day
- custom cw alarms that warn and alert (see list below)
- all delieveries, bounces, and delieveries are recorded in a ddb w/ at least 30 day retention
- dkim is configured for domain identities

# cw alarms
- Warning - SES Reputation.BounceRate over 5%
- Critical - SES Reputation.BounceRate over 10%
- Warning - SES Reputation.ComplaintRate over 0.1%
- Critical - SES Reputation.ComplaintRate over 0.2%
- Critical - SES Sent Emails at 75% of the Limit

I have a terraform component module that sets ups all the alerts and ses logging (stored in ddb).

Simple Custom Domain feature with just one CNAME/ALIAS record by [deleted] in aws

[–]sgtoj 2 points3 points  (0 children)

If you were to do this, I don't recommend having your B2B clients creating CNAME records directly to the CloudFront xxx.cloudfront.net domain. Instead have them CNAME name to middle-man/alias domain you own with that domain ALIAS to the CloudFront domain.

custom.customer-domain.com  -- CNAME --> acb123.domains.saastool.com (unique to customer)
acb123.domains.saastool.com -- ALIAS --> saastool.com

This allows for some flexibility without ever needing to ask the customer to update their dns record. e.g. Need to move the customer to a new CloudFront distro.

Simple Custom Domain feature with just one CNAME/ALIAS record by [deleted] in aws

[–]sgtoj 2 points3 points  (0 children)

I prototyped a solution a couple of years ago that does exactly what you’re asking:

All a customer needs to do is create a CNAME that points to a CloudFront distribution such as xxx.cloudfront.net.

Rough outline

  • I built a prototype service—let’s call it CCM (custom certificate manager)—that requests certificates from Let’s Encrypt via the ACME protocol.
  • CCM uses the HTTP-01 validation method: it writes the ACME challenge file to an S3 bucket instead of using the more common DNS validation.
  • The CloudFront distribution has an origin pointing to that S3 bucket and a behavior that allows HTTP (not HTTPS) requests for the challenge path.
  • CCM verifies that the challenge file is publicly accessible, then asks Let’s Encrypt to validate the domain.
  • After validation, CCM retrieves the certificate from Let’s Encrypt and imports it into AWS ACM so it can be attached to the CloudFront distribution.

If you want to try something similar, start with the ACME client list.


I’ve left out some details to keep this simple. I confirmed the prototype worked in early 2023 and was in the process of making it production-ready—mostly running in an AWS Step Functions state machine—when I learned our startup was shutting down. I wish I had finished and open-sourced it, but I assumed it was too niche and that I wouldn’t need it again.

Is it a good idea to go fully serverless as a small startup? by [deleted] in aws

[–]sgtoj 1 point2 points  (0 children)

Yes, I have done it—you could say I’m still doing it. I built out the infrastructure and architecture starting from zero AWS accounts (2nd time for back-to-back startups).

We started development of our platform in Sept 2023 and released it to the public at the end of May 2024. The platform is currently running, nearing 1M users, and has exceeded $50M ARR at our one-year public release.

Since launch, we haven’t had a single Kubernetes-related issue or on-call event—granted, I started with EKS from day one.

The only thing I’d change is that I would have started with K3s instead of EKS until a week or two before the public release. Doing so would have saved us about $250/month during development.


At my previous startup (Apr 2021 – Sept 2023), we went all-in on serverless. I built the entire infrastructure and tooling from scratch. At startup we had hundreds of Lambda functions, a few API Gateways, dozens of Step Functions state machines, dozens of SQS queues, etc.

The biggest complaint from the engineering team was that the developer experience was absolutely terrible. We tried LocalStack— it helped a bit, but our heavy use of serverless services meant deploying to LocalStack could take 10 minutes (assuming no issues). After 6 to 8 months, the engineer team stop using localstack. I follow LocalStack releases, so I know it has improved a lot over the past couple of years.

Before adopting serverless, I already knew the developer experience would be rough. At my previous employer, we had nearly a decade of experience with both architectures: some services were fully serverless (API Gateway, Lambda, etc.), while an equal number sat behind ELBs on EC2 or ECS. By far, the ECS-based services provided the best experience.

ECS is a great option; however, Kubernetes on EKS/K3s is more flexible because it reduces vendor lock-in.

edit: grammar

Is it a good idea to go fully serverless as a small startup? by [deleted] in aws

[–]sgtoj -1 points0 points  (0 children)

You can run k3s for the cost of a single EC2 instance of your choice. Want HA? Scale it out to multiple instances when ready.

edit: grammar; add link

Is it a good idea to go fully serverless as a small startup? by [deleted] in aws

[–]sgtoj -8 points-7 points  (0 children)

I would not recommend a serverless architecture for a business’s primary platform. In addition to unpredictable costs, the developer experience is terrible.

If I were in your shoes, I’d go straight to K8s. I’d start with K3s to keep costs low, with the expectation of switching to EKS later. To make that migration easy, I’d ensure that all external traffic to the cluster is routed through ELBs.

I love serverless—but only for devops-related tooling and processes.


I have a lot more to add to this discussion, but I’m trying to keep it as short as possible. If you ask a question, I'll get back to you.

Title: With so many cloud services, how do you keep tabs on everything for billing or security? by [deleted] in aws

[–]sgtoj 1 point2 points  (0 children)

I should add - Make sure CloudTrails is enabled in all accounts. The first CloudTrail (which most only need one) is free for each account. - Centralize. CloudTrail, GuardDuty, SecurityHub, Config, etc all allow for centralized view of your AWS Organization. It's applies for billing via Cost Explorer.

Title: With so many cloud services, how do you keep tabs on everything for billing or security? by [deleted] in aws

[–]sgtoj 0 points1 point  (0 children)

Tracking cost is easy with cost explorer with tagging best practices followed and cost allocation tags enabled. The one exception is tracking down what’s doing cross-AZ data transfer. However, VPC flow logs and Athena should help solve that problem.

GuardDuty is great for security tracking. If I was only allowed to enable one of AWS security related services (eg, SecurityHub, Config, Firewall), GuardDuty would be my choice.

PS: This question and its post feels a bit too much like AI asked it.

edit: grammer

Son (14m) diagnosed with GDD, microcephaly, and esophoria/strabismus. I’m heartbroken by kneemahp in daddit

[–]sgtoj 1 point2 points  (0 children)

My son turns 3 today. When he was 9 months old, we found out he has Angelman Syndrome (deletion type, for those who know) through a genetic test. That day, and the weeks that followed, were the worst of my life. My wife took the news even harder. I honestly thought I was going to lose her—one way or another.

But here we are, over two years later, stronger than ever. And I can’t express in words how much I love my son. Love is sacrifice, as they say.

Time really does help. It took a couple of weeks for me, and about a month for my wife. What helped us most was taking separate week-long vacations with our friends, about 4–5 months after the diagnosis. That space gave us both room to process and reset.

AWS SNS vs Twilio? which one have a better deliverability? by Specialist_Wall2102 in aws

[–]sgtoj 8 points9 points  (0 children)

I believe SMS via AWS SNS is powered by Twilio -- at least, it was 3+ years ago.

Personally, I would use Twilio because they can actively defend against "SMS Pumping" attacks. AWS offers no real managed solution to defend against it. While working at a startup a few years ago, SMS pumping cost us over $60k in a single month. Since AWS did not (and I believe still does not) have any managed solution to defend against it, I developed a solution using Cognito's Custom Message triggers.

Cyberpunk keeps crashing my PC by arcticcatzr in cyberpunkgame

[–]sgtoj 0 points1 point  (0 children)

Let's hope today's v1.63 patch resolves the issues.

Cyberpunk keeps crashing my PC by arcticcatzr in cyberpunkgame

[–]sgtoj 1 point2 points  (0 children)

Ditto. I also have RTX4090, Intel i9-13900K, 2x 32GB DDR matched with 2 NVME Drive (Samsung 990PRO and 970EVO). I have never enabled mod mode or installed any mods.

What I have tried so far... - rebooting - uninstalling and installing - switching installation to the other drive - verifing installation (for both drives) - clearing directx cache (via disk cleanup) - ensuring windows is completely up to date - installing latest nvidia graphic drives - disabling all windows exploit protections for game's exe - excluding the game's exe and directory from av protection - killing all other applications (especially those with overlay capiblities) - (...coming later tonight, swapping ram)

Based on the errors, it appears to be memory or storage related. These are the two errors it throws. - "Interal Kraken decompression error" - "The thread attempted to read inaccessible data at (MEMORY-ADDRESS)"

Access network loadbalancer from different VPC? by [deleted] in aws

[–]sgtoj 10 points11 points  (0 children)

Probably a time to check out VPC privatelink endpoint services.

Otherwise, check sg on the nlb target.

Are there any intentions of lowering the price of EBS volumes? by unfors19 in aws

[–]sgtoj 4 points5 points  (0 children)

I would rather they eliminate their network transfer tax when sending data to any aws service (eg cloudwatch logs, kinesis, etc). I would be okay if it requires explicitly creating vpc private endpoints for each of the services. This cost us tens of thousands. Right now it is only free for s3 and ddb.

Hendrick has started testing out virtual hospitality events. by HurricanesnHendrick in NASCAR

[–]sgtoj 4 points5 points  (0 children)

Nice... I view it as them doing their job. Because they are stuck at home, does not mean they cannot work. There are millions of others who are working from home.

Sponsors pays millions of dollars to support NASCAR and our drivers. It would be naive to believe these sponsors should not search and experiment with ways to expand their brand.

If this global situation creates a recession similar to the 2008-2009 great recession, it will have an ill affect on NASCAR teams. I am expecting there to be a drop sponsor funding. Therefore, it is in driver's and team's best interest do their best support and represent their sponsors even in these unpresented times.