Showing posts with label application server. Show all posts
Showing posts with label application server. Show all posts

Wednesday, August 7, 2013

Running web application on AWS

In most cases, you will not just be running just an Oracle database on AWS.  You will be running a web based application.  For Oracle focused developers and engineers, running web applications on AWS is not an area of expertise. Here are the best documents, documentation, and diagrams to review for developing web based applications on AWS:




Support for session state and database failover when application server goes down are a couple of details that most Oracle folks ask about.  Information can be found here:

Session state: Good blog post here: http://harish11g.blogspot.com/2012/10/web-session-synchronization-aws-ec2.html . The last option is DynamoDB which is the method used most often.
Database failover:
  1. Using RDS this is automatic: When automatic failover occurs, your application can remain unaware of what's happening behind the scenes. The CNAME record for your DB instance will be altered to point to the newly promoted standby. Your client library must be able to close and reopen the connection in the event of a failover.
  2. Using Oracle on EC2 : You would use Elastic Ips and use this pattern : http://aws.amazon.com/articles/2127188135977316 . You cloud use ENIs so private Ips could be used http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#create-a-low-budget-high-availability-solution

Friday, June 7, 2013

ELB time out


The default time out on AWS ELB is 60 seconds.  There's a 17 minute max for ELB timeouts, but the connection from ELB to the backend app servers is persistent by default. You have to manually request the change to adjust the front-facing timeout value.  Detail here: https://forums.aws.amazon.com/thread.jspa?threadID=110299.

Wednesday, May 29, 2013

DBA and developer access to Oracle hosted on AWS


Here are three common methods used to limit access to the AWS environment for DBAs and developers:
  1. Bastion host : A bastion can be used as a jump box' / proxy server. Developers and DBAs would be given access using SSH and than use other credentials to log into the web, application, and database servers. More on bastion host security can be found here: http://cloudconclave.blogspot.com/2013/05/aws-bastion-host-as-single-point-of.html.  There is the cost of the EC2 instance that is the bastion host and data transfer out costs.
  2. VPN with customer gateway and virtual private gateway.  In the case, you create a VPN tunnel.  The costs here are the VPN hardware on your side (customer gateway), cost of virtual private gateway (VPG), and costs of VPN connections and data transfer out of AWS. More on VPN costs here (this assumes this option): http://cloudconclave.blogspot.com/2013/05/vpn-costs-for-connections-and-data.html
  3. OpenVPN : You do not incur the cost of hardware on your side and the VPG on the AWS side.  You still have the cost of the data transfer out.  You would also incur the cost of the EC2 instances that is running an open source VPN software stack (in this case OpenVPN).
I am sure there are other methods as well.

Could also use these constructs to provide secure integration from your on premise or third party applications (SFTP for flat file integration, VPN for web services).