Be notified when a RDS instance was created

0
votes

I'm using AWS SDK for Java.

Imagine I create a RDS instance as described in the AWS documentation.

AmazonRDS client = AmazonRDSClientBuilder.standard().build();
CreateDBInstanceRequest request = new CreateDBInstanceRequest().withDBInstanceIdentifier("mymysqlinstance").withAllocatedStorage(5)
        .withDBInstanceClass("db.t2.micro").withEngine("MySQL").withMasterUsername("MyUser").withMasterUserPassword("MyPassword");
DBInstance response = client.createDBInstance(request);

If I call instance.getEndpoint() right after making the request it will return null to me, because AWS is still creating the database. I need to know this endpoint when it becomes available, but I'm not figuring out how to do it.

Is there a way, using the AWS SDK, to be notified when the instance was finally created?

2
javaamazon-web-servicesaws-sdkamazon-rds
You need to use waiters to achieve this. Java SDK supports it: aws.amazon.com/blogs/developer/waiters-in-the-aws-sdk-for-java. I have no experience using Java SDK. In Python, I refer: boto3.readthedocs.io/en/latest/reference/services/… – krishna_mee2004

2 Answers

0
votes

You can use the RDS SNS notifications:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages

Subscribing to Amazon RDS Event Notification You can create an Amazon RDS event notification subscription so you can be notified when an event occurs for a given DB instance, DB snapshot, DB security group, or DB parameter group. The simplest way to create a subscription is with the RDS console. If you choose to create event notification subscriptions using the CLI or API, you must create an Amazon Simple Notification Service topic and subscribe to that topic with the Amazon SNS console or Amazon SNS API. You will also need to retain the Amazon Resource Name (ARN) of the topic because it is used when submitting CLI commands or API actions. For information on creating an SNS topic and subscribing to it, see Getting Started with Amazon SNS.

0
votes

Disclaimer: Opinionated Answer

IMO creating infrastructure at runtime in code like this is devil's work. Stacks are the way to go here, much more modular and you will get some of the following benefits:

  • If you start creating more than one table per customer you will be able to logically group them into a stack and clean then up easier as needed
  • If for some reason the creation of a resource fails you can see this very easily in the stack console
  • Management is much easier to search through stacks as you have a console already built for you
  • Updating a stack in AWS is much easier as well than updating tables individually
  • MOST IMPORTANT: If an error occurs the stack functionality already has rollback and redundancy functionality built in, which you control the behaviour of. If something happens in your code during your on boarding process it will be a mess to clean up, what if one table succeeded and the other not? You will have to troll through logs (if they exist) to find out what happened.

You can also combine this approach with using something like AWS Pipelines or even AWS Simple Workflow Service to add custom steps in your custom on-boarding process, eg run a lambda function, send a notification when completed, wait for some payment. This builds on my last point that if this pipeline does fail, you will be able to see which step failed, and why it failed. You will also be able to see if things timeout.

Lastly I want to advise caution in creating infrastructure per customer. It's much more work and adds allot more ways in which things can break. Make sure you put limits in AWS as well that you don't have a situation in which your bill sky-rockets because of some bug creating infrastructure.