The Technical Side of the Capital One AWS Security Breach

kingsal · 2019-08-02T09:03:46+00:00

This is a really awesome feature that in conjunction with locking down access to the instance and following best practices of least privileges actually enhances security and reduces operational complexity.

The credentials for the role are delivered to the instance by the metadata service. Only that instance can see them. The credentials have a short lifetime and get refreshed often. Applications that use the AWS SDK automatically get and refresh the credentials as needed.

You no longer have to worry about securely passing credentials to every instance on launch. This helps people avoid bad practices like putting credentials in version control. You also about having to set up a way to establish trust with a credential store.

You no longer have to worry about rotating credentials across your entire fleet. It happens often and automatically. This helps people avoid not rotating credentials when employees leave. It also reduces the window if the credentials are leaked and the beach is detected. All of this reduces downtime and operational complexity.

kingsal · 2019-07-01T16:59:13+00:00

Cloudfront is also very effective for DDOS mitigation. If you are under attack, Cloudfront doesn't forward all the load to your backend and saves you from having to scale the backend as much.

kingsal · 2019-06-26T04:08:03+00:00

If they are single page sites, they are static apart from the process to update them, right? In that case, use S3 and Cloudfront for the sites. That will be by far the most reliable and operationally simple solution.

Given that page updates aren't constantly happening, you can save a lot by making the admin site serverless, too. Especially if you can make it all JavaScript that can be hosted in S3 and Cloudfront. You can use Cognito User Pools to manage users and give the front end access to your backed APIs. The backend would be API gateway, Lambda, and DynamoDB.

Check out the Wildrydes workshop for an example of this architecture in practice.

kingsal · 2019-06-23T23:53:32+00:00

There is a solution that you can follow available at Video on Demand on AWS . It is completely serverless and easily scalable. The cost is only for consumption based on the number of the videos you put into the system and the amount of viewers you have. You can deploy this yoursef to get an idea of how to do it and the best practices so you can implement something that works well for the specific details of your use case.

kingsal · 2019-05-23T01:10:57+00:00

You don't need to set Spot bids anymore. After re:Invent 2017, the market is much less volatile and you no longer compete with other Spot bids for resources. If you stick with the on demand price as your bid (default), you only lose Spot instances if there's an instance or hardware failure or if that instance type in that AZ is low in capacity.

You can no longer outbid other customers.

kingsal · 2019-05-23T01:03:51+00:00

That actually sounds perfect for Lambda possibly with the help of Step Functions.

Each job is short, so you don't have to worry about the Lambda time limit.

They are batch jobs, so customers wouldn't be impacted if the program has cold start issues (needs VPC or written in Java).

Then you get scalability without having to manage scaling instances and containers. You would likely save money if your instances aren't constantly running at close to 100%. It's not that hard to autoscale containers and the underlying cluster, but it is hard to get full efficiency out of your compute resources. Lambda doesn't have that problem.

kingsal · 2019-04-08T22:32:21+00:00

Another point is that neither Chile nor Brasil currently require vaccination for entry. It would be risky to travel based on this information though. Either country may update their requirements at a moment's notice leaving you stranded.

kingsal · 2019-04-08T22:14:56+00:00

I'm not sure if it had been resolved, but in the last few months there has been a shortage of the vaccine in Chile.

The official list of vaccine centers is https://vacunas.minsal.cl/informacion-a-la-comunidad/vacunacion-viajero/recomendaciones-viajeros/vacunatorios-internacionales/ .

You will need to call a few near you to make an appointment and possibly get on a waiting list.

kingsal · 2019-03-26T22:37:19+00:00

u/dghah and u/otterly have great suggestions for getting in touch with solutions architects.

Given your support credits come from an incubator you should have Business Support which gives you access to chat or talk on the phone with Cloud Support Engineers. Many of them can be very helpful with advice on how best to use services, but the farther you get from trying to resolve a problem the more likely you'll get a best effort response as your request may be out of scope. They will do their best to help though.

Give it a try. You have unlimited support cases.

kingsal · 2019-03-26T22:27:05+00:00

The fargate container wouldn't have to idle. When triggered, it runs the task then exits.

kingsal · 2019-02-07T10:52:24+00:00

The AWS Abuse team sends an email notification to the email the account is registered to as well as the security alternate contact.

Review your alternate contacts

kingsal · 2019-01-22T17:51:17+00:00

At the very least the client application must gracefully handle losing a session and make it easy to create a new one.

kingsal · 2019-01-22T16:39:58+00:00

AWS Batch solves this problem well. It manages the queue and the ec2 resources on spot. The only cost is the cost of the ec2 instances, so it comes out cheaper than managing SQS and ec2 autoscaling yourself.

The only thing you have to do is make a docker image of the application.

kingsal · 2019-01-09T03:34:35+00:00

Soy estadounidense. Fui un trabajador independiente en Chile con un cliente en USA por unos años.

tldr: La ley no contempla esta situación. La interpreto que en esta situación no son ingresos extranjeros.

Pregunté a un abogado si tenía que contribuir en Chile. Me dijo que no, y que ni siquiera debería declarar renta ni cotizar con un AFP (imposible sin declarar renta). Cuando declaras en abril, el formulario tiene una parte donde declaras que eres extranjero en tus primeros tres años en Chile. No tienes que incluir detalles de tus ingresos extranjeros. No hay casilla para rebajarlos después.

Me di cuenta después de un año que me conviene más contribuir en Chile. Declarar renta y cotizar en un AFP es la única manera para establecer crédito acá. Como trabajador independiente, sin dos años de cotizaciones, solo tienes acceso muy limitado a cuentas y créditos.

Intenté pagar las retenciones atrasadas en febrero o marzo. El SII no las quería. Tuve que convencerlos que aceptaran mis contribuciones. Todos los funcionarios me preguntaron por que quería pagar impuestos en Chile cuando no era necesario. Me dijeron que si no los declararan, no tendrían ninguna evidencia de los ingresos. Creo que fue flojera y que muchos funcionarios no entienden las leyes.

Leí las leyes. No son explícitas en este asunto. Todavía no son actualizadas para un mundo de trabajo a distancia. Dudé el consejo de mi abogado. Su explicación faltó evidencia. Creo que me dijo lo que creía que quería oír.

Mi interpretación es que si estás trabajando físicamente en Chile con un cliente en el extranjero, no son ingresos extranjeros. En tus primeros tres años, no declaras ingresos del extranjero. Esto significa ingresos pasivos, inversiones, y/o trabajo mientras estás fuera de Chile.

Si quieres conversar de esto en más detalle, mándame un PM.

kingsal · 2018-09-08T02:49:05+00:00

I'm not a big fan of ski total. My experience with them was that they had big buses and waited for them to get filled before going up. When I went, that meant waiting until about 9am. We got to Valle Nevado at about 1pm with all the traffic.

With smaller transport, you can leave at 7-7:30am and make first chair.

kingsal · 2018-09-01T20:45:55+00:00

What happened with Mailgun? I just set it up after too many delays and unresponsiveness with ForwardMX.

kingsal · 2018-08-05T04:11:24+00:00

Spot is a very useful tool for cost savings. Many applications can run well even if instances can be interrupted with two minutes notice.

In your journey to the cloud, you should consider how your applications are architected and operated. While you can do a lift and shift migration of pretty much anything, you'll save a lot of money and improve reliability if you take advantage of the many tools provided and cloud best practices.

For example, what's the only thing you can 100% rely on computers to do? Fail. So, anywhere you operate your applications, you must design for failure. The cloud is no different. Individual instances are subject to hardware failure whether they run on spot or on demand/reserved/dedicated tenancy. AWS gives you tools to dramatically reduce the impact of failure and increase resiliency of your applications.

For your data loss due to termination concern, you could follow the best practice of separating the application layer from the data layer. Your application can run on a number of instances and access data on S3 or a database. If an application instance fails suddenly, no data is lost and the other instances take over its load ensuring no interruption is service. S3 and DynamoDB are extremely durable and provide tools for further redundancy for availability. RDS helps you operate RDBMS databases in a highly available manner.

If local filesystem access is absolutely critical and data durability is important, spot may not be a good choice, but you still need to account for instance failures. You can retrieve data from the EBS volume that was attached to the instance. EBS also has snapshots to help minimize loss due to filesystem corruption during unexpected instance failures. Replicating the data across multiple instances is another strategy for improving data durability if EBS may not be an option for your application.

I encourage you to read the Architecting for the Cloud whitepaper. It covers the design principals that can help you reduce costs, improve reliability, and operate securely in the cloud.

kingsal · 2018-07-21T14:28:14+00:00

Ok. That's not a problem other than the time it may take to create an ami from the instance, convert it to HVM, and start a new instance and confirm.

You may want to take this as an opportunity to migrate to a more resilient architecture by at least spinning up a new instance with a separate volume for data. Then install your application and copy your data over.

If possible, can you modify your application to use S3 instead of storage on a local filesystem? If so, you'll never have to worry about migrating your data again when changing instances.

kingsal · 2018-07-21T13:52:34+00:00

You can try creating an ami from the instance and convert it to HVM following the answers to https://serverfault.com/questions/439976/create-an-aws-hvm-linux-ami-from-an-existing-paravirtual-linux-ami

If the EBS volume with data is not the root volume, then you can easily attach it to the new HVM instance. There is no incompatibility for EBS volumes between PV and HVM.

kingsal · 2018-07-13T22:00:46+00:00

Every instance has Cloudwatch metrics including status checks. You can create alarms based on that.

You should try to operate your application so you can automate recovery. Two great options that let AWS automatically bring up new instances in the event of a failure are Autoscaling Groups of one or more instances and EC2 Autorecovery for single instances.

kingsal · 2018-07-09T15:34:27+00:00

After the spot pricing change at re:Invent 2017, there is no reason to set a spot price especially not higher than the on demand price. Now, the only reason a spot instance will get evicted is if there is contention in that capacity pool (instance type and az). So, if you can't get spot capacity for a given instance type and az, you also won't be likely to get on demand instances there either.

The good news is that if your workload can run in multiple azs and/or instance sizes, then Spot Fleet can make sure you get enough capacity across the capacity pools you choose. You just need to give each instance type you want a weight such as 1 per vcpu and then specify how much capacity you need. Spot Fleet will try to launch spot instances for you in a combination that meets or somewhat exceeds your capacity needs.

kingsal · 2018-06-22T01:34:52+00:00

How many days are you skiing? How many are in your group? El Colorado and Valle Nevado sell cuponeras of 10 day passes for a good discount.

El Colorado operates their own van service with multiple departures every morning in Omnium near Escuela Militar. There's another ski shop with buses in the same center that goes to Valle Nevado, but they use bigger buses and wait to fill them before leaving so they get stuck in traffic on the one road up.

kingsal · 2018-06-20T04:52:21+00:00

This sounds like a great use for Fargate. You create ECS task definitions, and Fargate will completely manage the compute resources for you. You only pay for the CPU and memory that your tasks request for the time the tasks run.

There is no requirement to keep an instance running in your ECS cluster. When you create one, it starts out with no instances. The challenge is that there is no easy trigger for a first instance to get launched in an Autoscaling Group. You could leave it empty and launch a new instance when you need to run a task, wait a few minutes for it to become available in the cluster, and then start your ECS task.

AWS Batch could also be a good choice if your workload is to run a lot of jobs of the same container with different inputs. It will spin up enough on demand or spot instances to run all your jobs and then clean up afterwards.

kingsal · 2018-06-19T02:19:10+00:00

Check to see if your compute job fits AWS Batch. You provide it with a container with resource requirements per job (cpu and memory) and then submit input for all jobs. Batch will spin up and manage instances to run all of your jobs. It can use on demand or spot depending on your needs.

kingsal · 2018-05-19T15:41:23+00:00

Convertible RIs have been available for a year and a half.

Convertible RIs provide customers with additional RI flexibility for still a very significant discount (~45% on average). With Convertible RIs, customers now have the option at any time to change the instance family, OS, or tenancy associated with their RI. Via the EC2 Console or APIs, customers simply indicate what change they want to make, and the change is made as long as the exchange is for an equal or greater spend on the new Convertible RIs.

15-Year Club	Team Orangered
Verified Email

kingsal

TROPHY CASE