Password strength and security is an all important aspect of keeping your data secure. Learn how dev teams can use this AWS service to encrypt/decrypt passwords.
MySQL manages primary keys as clustered indexes. That means you're looking a performance hit with some synthetic primary keys. Here's when to avoid them.
Keeping your cloud machine instances secure is of paramount importance, but it's often hard to troubleshoot and expensive. An Elastic Load Balancer can help with that.
I guess the documentation is not clear: this property is the name of a static method. You can't pass it parameters.
The idea is that inside that static method you can access whatever configuration mechanism your program uses. For example, you might need to use a proxy to access AWS.
You could also retrieve properties from the Log4J logging context.
I wish you the best, but this is all the help I can give you. This library might not be the best choice for your application.
Regarding the exception: this is almost certainly because you're not including aws-java-sdk-logs in your deployment bundle. As I note in the README, all of the dependencies are marked as "provided" in Maven, to avoid introducing issues with incompatible versions. You need to explicitly specify all dependencies.
Regarding help with configuring access keys. As I said, the easiest way to do that would be for you to provide a static factory method. Example configuration for Log4J2 is here, and a sample implementation is here.
Storing access keys in a configuration file (which is likely to be checked-in to source control) is a security risk. Amazon has many other suggestions here. For production deployments, instance/Lambda roles are the way to go.
I am currently in the process of splitting the back end writer code from the front-end appender code, with the intention of supporting other logging front-ends. I will probably do Logback first, as it's the logger of choice for Spring. But I have no timetable for this: it's one of several side-projects that I have.
However, there is one thing that I'd like to point out: true, Log4J 1.x is at end-of-life. It's not going to be updated. *But that doesn't mean that you should go through your codebase and replace it!* It's stable, and (relatively) bug-free. Even for new projects, I'd recommend sticking with Log4J 1.x if your current codebase uses it, albeit with SLF4J as the actual API that you use.
There are, of course, good reasons to change, one of the best being that you're using a framework like Spring that is based on a different logging framework. Or you have a business need to the features that another logging framework provides.
While commenting, I should also point out that the last two paragraphs were footnotes in the original post. As shown here, they don't make a lot of sense.
This is a hack: a useful shortcut that may be non-obvious. I found it particularly useful when developing a deployment script: I could quickly check the status of my instances without having to establish an explicit tunnel.
As for using this hack -- or a real bastion host -- versus a VPN: I believe that the VPN provides less security: because it essentially joins the networks together, it limits your ability to control who can connect to instances in the VPC. A bastion host, by comparison, provides an extra level of security: you must explicitly authorize access.
Comments
May 08, 2020 · Mike Gates
I guess the documentation is not clear: this property is the name of a static method. You can't pass it parameters.
The idea is that inside that static method you can access whatever configuration mechanism your program uses. For example, you might need to use a proxy to access AWS.
You could also retrieve properties from the Log4J logging context.
I wish you the best, but this is all the help I can give you. This library might not be the best choice for your application.
May 07, 2020 · Mike Gates
Regarding the exception: this is almost certainly because you're not including aws-java-sdk-logs in your deployment bundle. As I note in the README, all of the dependencies are marked as "provided" in Maven, to avoid introducing issues with incompatible versions. You need to explicitly specify all dependencies.
Regarding help with configuring access keys. As I said, the easiest way to do that would be for you to provide a static factory method. Example configuration for Log4J2 is here, and a sample implementation is here.
May 07, 2020 · Mike Gates
You can implement a static factory method that does whatever you want. Otherwise, no.
May 07, 2020 · Mike Gates
Storing access keys in a configuration file (which is likely to be checked-in to source control) is a security risk. Amazon has many other suggestions here. For production deployments, instance/Lambda roles are the way to go.
Sep 15, 2018 · Mike Gates
I am currently in the process of splitting the back end writer code from the front-end appender code, with the intention of supporting other logging front-ends. I will probably do Logback first, as it's the logger of choice for Spring. But I have no timetable for this: it's one of several side-projects that I have.
However, there is one thing that I'd like to point out: true, Log4J 1.x is at end-of-life. It's not going to be updated. *But that doesn't mean that you should go through your codebase and replace it!* It's stable, and (relatively) bug-free. Even for new projects, I'd recommend sticking with Log4J 1.x if your current codebase uses it, albeit with SLF4J as the actual API that you use.
There are, of course, good reasons to change, one of the best being that you're using a framework like Spring that is based on a different logging framework. Or you have a business need to the features that another logging framework provides.
Jan 11, 2017 · Duncan Brown
While commenting, I should also point out that the last two paragraphs were footnotes in the original post. As shown here, they don't make a lot of sense.
Jan 11, 2017 · Duncan Brown
This is a hack: a useful shortcut that may be non-obvious. I found it particularly useful when developing a deployment script: I could quickly check the status of my instances without having to establish an explicit tunnel.
As for using this hack -- or a real bastion host -- versus a VPN: I believe that the VPN provides less security: because it essentially joins the networks together, it limits your ability to control who can connect to instances in the VPC. A bastion host, by comparison, provides an extra level of security: you must explicitly authorize access.