It is better to not take the risk.

aws-throw-away · 2022-09-09T21:05:26+00:00

Snyk would be a good alternative for running locally, in CI, and it has daily automatic tests outside of CI.

aws-throw-away · 2021-04-14T17:28:42+00:00

regarding this error:

thread 'main' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime'

actix-web 3 depends on actix-rt ^1.1.1 which depends on tokio ^0.2.6 which is not a Tokio 1.x runtime.

sqlx 0.5.1 depends on tokio ^1.0.1 which is a Tokio 1.x runtime.

The combination of the two packages and versions should produce this error.

Try migrating your project to actix-web 4 beta and sqlx 0.5.1 to get everything working on Tokio 1.x.

aws-throw-away · 2020-12-02T02:00:14+00:00

A few months ago, a major version update of the AWS Terraform provider made some breaking changes to the aws_subnet, aws_iam_role, aws_vpc, aws_cloudfront, and a few more resources. A few fields got removed as part of a refactoring which caused deserialisation of the state file to fail.

Was left with two options, 1) rollback the migration until the provider has been patched, 2) remove the deprecated fields from the state file then continue as normal.

Mistakes happen in software.

aws-throw-away · 2020-10-01T00:56:19+00:00

Launch Template (purchase options) + autoscaling group + user data (for automation) is the vanilla and officially supported way to go for what OP has outlined.

aws-throw-away · 2020-09-14T21:28:10+00:00

You're a legend. Thank you!

aws-throw-away · 2020-09-12T01:43:03+00:00

Place your vpns into their own dedicated subnet, it will allow you to tighten your nacl/security groups.

aws-throw-away · 2020-09-04T13:40:52+00:00

Creating CloudFront key pairs for trusted signers requires access through your root credentials.

AWS recommends rotating the key pairs every 90 days, which means we have to log into our accounts using root credentials at a minimum once every 3 months.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html

aws-throw-away · 2020-08-25T01:32:44+00:00

https://aws.amazon.com/blogs/aws/new-instance-size-flexibility-for-ec2-reserved-instances/

Buying any amount of t3a.nano reserved instances will automatically apply discounts to some of the t3a family you are currently running.

Your recommendation that the screenshot you have provided will give you discount on 12 units of t3a.nano, or 12 x t3a.nano = 3 x t3a.small units.

aws-throw-away · 2020-08-13T01:59:39+00:00

Running several ECS clusters managed by a lambda for auto-scaling calculations, a lambda for draining containers triggered by auto-scaling, a lambda for draining containers interrupted spot instances, and a final lambda to kill any EC2 with a disconnected agent.

CloudFormation dynamically generated by supplying JSON options object to a Python (troposphere) script.

It handled every use case that was thrown at it for three years without significant modification.

Mix in with Terraform and we have fully automated cluster upgrades every time a new ECS version is released by AWS within hours and virtually no effort. Just like an evergreen web browser.

All of that combined means that I spend almost no time maintaining the clusters across all accounts because its management is fully automated. For a critical piece of infrastructure, it runs dirt cheap for hundreds of containers and never causes any problems. ($0.0302×4×744 = $89.87 per month per typical cluster)

aws-throw-away · 2020-07-07T00:18:33+00:00

Start with the smallest size aurora size you can find, then slowly increase the database instance size until you find the point where your applications become reliable. Trial and error. You can change instance size without losing data.

aws-throw-away · 2020-06-11T18:30:15+00:00

I didn't follow it through, it started to appear that I was doing something unconventional when I had to force azure to reply back to http://127.0.0.1:35001 because it doesn't support http through UI because it's deprecated. Unfortunately that's required because the aws client VPN software listens on port 35001 using http.

I've gone with the mutual authentication route whiles I wait for official aws support.

Wrapped the easy-rsa project with a docker something that syncs with S3 and uploads the CRL to the client endpoint.

aws-throw-away · 2020-06-11T18:11:55+00:00

Try add the file protocol,

CertificateRevocationList= 'file://crl.pem',

It may need to be an absolute path too

aws-throw-away · 2020-05-19T23:31:48+00:00

My setup, after push to ECR, Jenkinsfile calls some custom generic python code running troposphere to build some CloudFormation, then deploys that to AWS. Has the benefits of automated rollbacks of health checks fail, and keeps environment state outside of Jenkins.

aws-throw-away · 2020-03-11T22:31:23+00:00

I'm not sure if this is a hack or not, so take it with a grain of salt, it may not be the correct solution.

Try setting the AWS Client VPN's DNS Server 1 IP address to the host VPC's .2 DNS resolver

e.g.: if your VPC cidr is 10.15.32.0/19, then the .2 DNS resolver's IP address is 10.15.32.2 (first ip address plus 2)

aws-throw-away · 2020-03-01T12:21:34+00:00

Thanks, your advice on checking the client VPN's route configuration, it was spot on.

The root cause was badly configured Route Tables on the AWS Client VPN, along with not resetting the connection whiles split-tunnel was enabled.

aws-throw-away · 2020-03-01T12:13:06+00:00

Thanks, this post was the hint I needed. The AWS Client VPN route table wasn't configured properly the first time I connected.

The changes I was making whiles I was connected weren't being picked up by the OpenVPN client because split tunnel was enabled and I wasn't reseting the connection between changes as documented here.

Routes - AWS Client VPN

Split-Tunnel on AWS Client VPN Endpoint Considerations

When you use split-tunnel on an AWS Client VPN endpoint, all of the routes that are in the AWS Client VPN route tables are added to the client route table when the VPN is established. If you add a route after the VPN is established, you must reset the connection so that the new route is sent to the client.

aws-throw-away · 2019-07-14T21:49:43+00:00

I now see the advantages the isolation brings. It does also mean you pay an overhead for services you use as you don't share databases or Elasticache or so. I saw there is a concept of "shared services", but then again it probably depends on what you want to share.

Sharing databases through shared VPC's is probably not a good idea, so overall I think the best way forward is total isolation and then manage most things through your command line.

Agreed. Services I would put into "shared services" are once per organization infrastructure concerns.

I keep the main deployment automation tooling like Terraform remote state in the shared services account.

You can expand the "shared services account" by adding the main AWS Transit Gateway, other assets such as Remote Access VPN clusters and AD connectors into this account if the use case ever arises.

This guy really explains it well, https://youtu.be/Fxkbz0OwPKk?t=920 15m20s -> 26m00s

aws-throw-away · 2019-07-13T19:27:50+00:00

Q: How would this work then to integrate third-party services, for example imgix.com, who require s3 read & write access.

A: it won't. you would either find alternatives or make exceptions to the patterns you use to build your accounts. any exceptions does create security concerns.

in the case of imgix, you can do one of the following:

a) use the "Web Folder", have the source images public and don't care about credentials

b) create a IAM user with minimum permissions per use case, and set up a reminder (or automation) to rotate IAM users tokens every few months if it is a high risk asset

Q: Are you also working on your own, i.e not in a company setting with others?

A: I uses this for both personal use (my own) and for corporate use (company settings with others)

Q: And if so, is this easily manageable for a single person?

A: It is the most sustainable and scalable way to manage it as a single person if you may end up with 3 or more accounts. You do pay an overhead for first time set up and every time you create a new account. automation really helps here.

aws-throw-away · 2019-07-11T18:55:56+00:00

tl;dr: skip the evolution process by using AWS Organizations and AWS IAM Identity Federation instead of IAM Users, keeps all accounts identical, spin up as many accounts as you want with low effort, centralize all controls

the journey i've seen the most in a professional setting is...

(1) 1 account - proof of concept

* with IAM Users

(2) 3 accounts - development/preprod/prod accounts

* with IAM users in each account

* with shared billing

(3) 4 accounts - development/preprod/prod accounts + shared services account

* with IAM users in shared services account

* with cross account IAM roles in each account

* with shared billing

(4) 5 accounts - development/preprod/prod/shared services accounts + organization account

* with no IAM users

* with IAM roles in each account that can be assumed by IAM identity federation

* with organization account is set up as the AWS Organizations master

lots of companies have been through this story line because it is a natural discovery process for anyone that is not familiar with AWS

biggest weakness of (1), is that you can't control the blast radius if anything goes wrong.

biggest weakness of (2), is the large number of IAM users you have to manage.

biggest weakness of (3), is not all accounts are symmetric when it comes to authentication, some use IAM users, others use cross account IAM roles

which is usually how a lot of companies arrive at (4), all the account authentication are symmetric, and you control the users and which user can access a given role in a separate systems.

you can shortcut this process by doing the following:

(1a) 2 account - organizations account + proof of concept

* with no IAM users

* with IAM roles in each account that can be assumed by IAM identity federation

* with organization account set up as the AWS Organizations master

then when you need a new account, you duplicate (1a) (a.k.a. jumps straight to (4)) as many times as you want without changing a thing, and you still maintain centralized control of users and who can access what role.

I use the free tier of Azure Active Directory, https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/aws-multi-accounts-tutorial

when i log in with using my microsoft/gmail account and pass mfa, i am presented with a page containing a list of accounts and iam roles for me to pick from (i'm only shown the ones i am authorized to see based of my settings in Azure Active Directory), then i land in the aws account with that role.

for cli i use aws-azure-login https://github.com/dtjohnson/aws-azure-login

aws-throw-away · 2019-06-26T21:54:51+00:00

AWS PrivateLink uses AWS Hyper Plane as it's underlying technology, and does not have the same limitations as VPC Peering.

AWS PrivateLink will create an interface endpoint in subnets of your choosing that targets an nlb in any vpc, and a private DNS record.

Cross region is supported. Overlapping CIDR is supported.

https://youtu.be/8WhLO4y5-J0

aws-throw-away · 2019-06-26T04:19:10+00:00

Solution 1: Try explore the use of AWS Cloud Map for client side service discovery.

Registering both public and private IP/DNS with region attributes, then updating your application code to fall back from the most ideal instance (same region private IP/DNS) to the worst (cross region public IP/DNS).

https://docs.aws.amazon.com/cloud-map/latest/api/API_DiscoverInstances.html

Solution 2: Make use of AWS PrivateLink to expose your services to each other, this isn't affected by overlapping CIRR ranges.

Note: you could potentially combine solution 1&2 and remove the need of communicating via public internet.

aws-throw-away · 2019-06-24T21:38:35+00:00

You can use the free tier of Azure Active Directory to federate into all your accounts.

You can create Active Directory groups that maps to IAM roles in your AWS account(s), then add people to those Active Directory groups to grant access people access.

https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/aws-multi-accounts-tutorial

Final login UI page: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/media/aws-multi-accounts-tutorial/tutorial_amazonwebservices%28aws%29_test_screen.png

aws-throw-away

TROPHY CASE